I guess I have too much time on my hands because I'm designing and building a CNC pendant. I have three Duet3d-based systems in-house (a CNC, a 3d printer, a milling machine) and I really need a portable pendant.

Now that it's nearly finished I thought it might be time for some feedback

Here's a quick view of what I'm building.

The case is 3d printed so pretty malleable. Each grid box is 1/2" (sorry not-metric) so the case is about 3.5"x4"x2".

Here's a quick view of the board (V1.00).

The board is designed to fit onto this 3.5" touchscreen display -> https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5 but it should work with most any display, just not as well-mounted. The carrier board holes fit the display.

The WaveShare display has a socket for a Raspberry Pi Pico. The carrier board has two Pico 'sockets'. The center socket is to flush-mount or pin-mount a Raspberry Pi Pico W, the other just has pins mounted for the display board.

There is a LiPo battery charger and voltage source circuit, as well as 7 input sockets: 1 digital input, 3 analog inputs (for potentiometers or ladder switches), and 3 multi-inputs for standard arduino rotary encoders or just usable as 3 digital i/o's per input. There are three different optional battery connectors in parallel - a 1mm JST, a 2mm JST, and a molex 2-pin. In addition there's a primitive current test pin.

The sample image of the pendant shows it with three rotary encoders - which I think will be my first attempt. By default they'll do X,Y,Z positioning.

I build these at JLCPCB in China, where the cost per board is tiny (<$5) but the setup+mail costs are close to $40/order. The first run was 5 boards which may be the last run if they work.

For software I'm planning to use MicroPython and have it talk to the Duet boards via the REST api. If this fails (so far it looks good) I'll switch to C++.

Mark

The first batch has shown up and I've adequately (good word) soldered the ic socket left. The center I've stuck a real plugin socket for testing (not shown). The mounting holes need to be moved left about 2.5mm but otherwise so far so good. I deliberately don't populate BAT2 or BAT3.

Strangely I've found out that my port-switchable USB hub apparently doesn't turn off the data lines since, with battery, this communicates with my PC USB even with the port off That's a useful feature for testing but still...

Here's a pointer to a Youtube video showing a very very very early demo.

Update:: I connected the CNC (a 6XD) direct to ethernet instead of a wonky forwarder and slightly tweaked the code and it's looking way better for lag.

https://youtu.be/eynj0Mf17kE

@dc42 I've forked and updated the github repo. You can see the code changes at: https://github.com/MZachmann/RepRapFirmware/tree/v3.2-screwmap

and it forks from the 3.02-dev branch (3.2 retail).

Let me know where you'd like to go from here. Implement (pull request)? Move to M-codes? Change syntax?

The only thing I couldn't yet figure out from the code base was how to correctly have the ui update the user position when the screw map definition changes.

Mark

Well, that came out just great - smooth and all the detail showed up. Thanks. For scale the nearer lizard is about 1.5" long.

@chimaeragh Here's my mill GUI. Three decimal places on coordinates, one on speed, and an inches display. Plus a skinnier Sensors bar.

options:

@MadewithMayo I've got a pendant I've been working on; to contrast the design... the pendant uses a Raspberry Pi Pico W with WiFi, a 3.5" touchscreen LCD, and the RRF Rest interface to communicate. I've got a board being made (2 weeks) that adds Lipo battery support to the Pico so the pendant can be wireless handheld.

I'm planning to put two rotary switches (axis and speed) on the unit as well as one indicator dial for movement - much like a conventional pendant - see here -> https://www.amazon.com/RATTM-MOTOR-Handwheel-Emergency-MITSUBISHI/dp/B07CZ7F3Y3

I'm writing it in MicroPython - but their Pico W port is not quite stable yet.

I've written plenty in Arduino and in my personal opinion it's not a production OS.

Why do it this way?

a) I have three Duet3d systems that I'd like to control and having a wifi pendant lets me walk it around.

b) I hate cables. They get caught on things and have finite lengths and physical failures.

c) Writing a small amount of easily maintained Micropython seems easier than negotiating changes to a PanelDue set of code that's really not designed for my applications (such as a CNC router).

My 2c.

Mark

I'm going to keep working on this, and here's why... I'm including 4 photos.

Two of them show my current CNC X axis and the camera, to understand the context. The other two show a scan of the camera looking at a ruler as I move the CNC manually in inch increments.

Looking at the problems, what is happening is that the X rails are deformed slightly in the center. The X dimension error increases then decreases (and then increases near the right edge). And .. at maximum X error there's also a Y error that's significant.

Using my last controller (WinCNC) I automatically created a multi-axis screwmap using the camera (which takes under 15 minutes) and the positioning error dropped from a max of .03" to .003".

@timothyz It's a little hard to tell what you both are experiencing. I'd split this into a few questions/comments.

It's not a big deal if you run in CNC or printer mode. I wouldn't, for now, worry about it too much. Mainly it affects some G code interpretation.

First, does the CNC work as is? Ignoring if it can run jobs does it move the axes the way you expect and find the limit switches etc? If so, then you're pretty much in great shape and you just need to get jobs running well. If not, then your config is probably not set up right.

If everything seems to be working on the CNC the first thing is to get homing going. These are macro files that you can write and my preference is to make them work independent of CNC/non-CNC mode - which is pretty easy. Until the machine is homed the motors won't move (see G0,G1 doc about bypassing homing).

Once you have it homing then it's a matter of getting your application to work correctly with it. I don't know carbide create at all, but given that it's intended for carbide3d machines I'd worry about using it elsewhere.

On my milling machine I use Fusion360, which you can run a free license for. The free license is very useful albeit annoying because it won't rapid. It has a huge startup cost (it's hard to figure out) but once you learn a few tricks it is a great manufacturing app.

On my CNC I run VCarve Pro for sheet goods. VCarve pro is not expensive and is easy to use. I use Fusion360 for 3d carving.

So I'd probably start with a known entity (such as fusion with a working postprocessor), get it running, then worry about Carbide Create.

MPCNC.cps - fusion postprocessor

duet3d_rrf_arc_mm.pp.txt - vcarve postprocessor with txt suffix

The mapping seems to be working quite well.

Here's a video clip showing it in use : https://youtu.be/uTqUBrUHinU

I'll write it up in the next week or so. Note that with minor mods this could do backlash compensation.
Here's the input file:

Here's the script I run to set the screwmap

Here's the result:

Mark

Here's a pointer to a Youtube video showing a very very very early demo.

Update:: I connected the CNC (a 6XD) direct to ethernet instead of a wonky forwarder and slightly tweaked the code and it's looking way better for lag.

https://youtu.be/eynj0Mf17kE

@Sindarius @jay_s_uk If you could msg me mailing addresses I'll send them out. I have at least 3 spares. If you want the ones with the improved, maybe correct, mounting holes they rate to take about 3 weeks to get here.

@T3P3Tony At the moment I'm using the MicroPython Pico W daily build and it's working very reliably, though there's some strangeness with the dual core management. It currently is drawing that sample image and hosting web pages as a test of the wifi. The only concern I have is that it's approaching the 2MB flash limit with most of the core code done.

All of the ports are tested and working and I've ordered new boards that hopefully have the holes correctly seated although I don't really care that much since the enclosure can correct that so now I'm working on the software. This would take just a few days if I didn't have other things to do.

If you guys want a few of the boards I won't be using them all.

The first batch has shown up and I've adequately (good word) soldered the ic socket left. The center I've stuck a real plugin socket for testing (not shown). The mounting holes need to be moved left about 2.5mm but otherwise so far so good. I deliberately don't populate BAT2 or BAT3.

Strangely I've found out that my port-switchable USB hub apparently doesn't turn off the data lines since, with battery, this communicates with my PC USB even with the port off That's a useful feature for testing but still...

I guess I have too much time on my hands because I'm designing and building a CNC pendant. I have three Duet3d-based systems in-house (a CNC, a 3d printer, a milling machine) and I really need a portable pendant.

Now that it's nearly finished I thought it might be time for some feedback

Here's a quick view of what I'm building.

The case is 3d printed so pretty malleable. Each grid box is 1/2" (sorry not-metric) so the case is about 3.5"x4"x2".

Here's a quick view of the board (V1.00).

The board is designed to fit onto this 3.5" touchscreen display -> https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5 but it should work with most any display, just not as well-mounted. The carrier board holes fit the display.

The WaveShare display has a socket for a Raspberry Pi Pico. The carrier board has two Pico 'sockets'. The center socket is to flush-mount or pin-mount a Raspberry Pi Pico W, the other just has pins mounted for the display board.

There is a LiPo battery charger and voltage source circuit, as well as 7 input sockets: 1 digital input, 3 analog inputs (for potentiometers or ladder switches), and 3 multi-inputs for standard arduino rotary encoders or just usable as 3 digital i/o's per input. There are three different optional battery connectors in parallel - a 1mm JST, a 2mm JST, and a molex 2-pin. In addition there's a primitive current test pin.

The sample image of the pendant shows it with three rotary encoders - which I think will be my first attempt. By default they'll do X,Y,Z positioning.

I build these at JLCPCB in China, where the cost per board is tiny (<$5) but the setup+mail costs are close to $40/order. The first run was 5 boards which may be the last run if they work.

For software I'm planning to use MicroPython and have it talk to the Duet boards via the REST api. If this fails (so far it looks good) I'll switch to C++.

Mark

@Nightowl It's just my personal opinion but I'm not a fan of Arduino software.

Arduino hardware is fine but it's very last generation and imho it's designed for hackers who want a quick sensor or monitor. The usual kit is an Atmega 328p - an 8 bit one-core processor with 1K ram and 32K flash at 20MHz.

The Pico W, by comparison, is - a 32 bit dual core (M0+) processor with 256K ram and 2MB of flash at 133MHz with WiFi.

@MadewithMayo I've got a pendant I've been working on; to contrast the design... the pendant uses a Raspberry Pi Pico W with WiFi, a 3.5" touchscreen LCD, and the RRF Rest interface to communicate. I've got a board being made (2 weeks) that adds Lipo battery support to the Pico so the pendant can be wireless handheld.

I'm planning to put two rotary switches (axis and speed) on the unit as well as one indicator dial for movement - much like a conventional pendant - see here -> https://www.amazon.com/RATTM-MOTOR-Handwheel-Emergency-MITSUBISHI/dp/B07CZ7F3Y3

I'm writing it in MicroPython - but their Pico W port is not quite stable yet.

I've written plenty in Arduino and in my personal opinion it's not a production OS.

Why do it this way?

a) I have three Duet3d systems that I'd like to control and having a wifi pendant lets me walk it around.

b) I hate cables. They get caught on things and have finite lengths and physical failures.

c) Writing a small amount of easily maintained Micropython seems easier than negotiating changes to a PanelDue set of code that's really not designed for my applications (such as a CNC router).

My 2c.

Mark

@dc42 Thank you very much.

@dc42 Here you go. This prints a small object using PETG. Let me know if you want something different. Looking at the GCode file, line 266 calls my init macro - which you can just comment out - it does a home then wipes the nozzle.

Mark

SmallTestBody.stl
S3D_V5_Test.gcode

@Proschi78 @GeneRisi and @T3P3Tony

Yes, editing the summary line to Filament length from Material Length took care of it.

Thanks, all.

p.s. looking quickly at the code it's on line 729 of Storage\FileInfoParser.cpp in 3.4.2