I would like to quickly present a small project that I finally had some time to do over the last few days:

https://github.com/hurzhurz/Duet-USB-CNC-Pendant

It is a bit similar to the CNC-Pendant-Firmware, but instead of modifying a simple (but still not cheap) CNC pendant, theoretical any USB HID device can be used.
It is based on a Raspberry Pi Pico, easy and cheap to build.

Multiple months ago, when I looked for the pendant that is needed for the CNC-Pendant-Firmware, Amazon suggested me the combination of a cheap wireless numpad and matching CNC-themed key-stickers, which lead to this idea.
At that time I already managed to figure out the basic USB HID part, but had no time to go further.
Later I found the WHB04B-6 wireless USB pendant and recently bought it to motivate myself to do this project.

So at the moment, the cheap numpad (LogiLink ID0120) and the WHB04B-6 pendant are implemented.
Other numpads should work too, but I have filtered for the VID and PID of the LogiLink one. But this can be changed easily in the code.
And other USB HID devices (keyboard, mouses, gamepads, …) should probably be relatively easy to implement as well.

I would be happy if someone would like to try it out and give some feedback.

Though I want to point out that some things might not be implemented in the best way… I'm whether a full-time developer nor an experienced CNC operator

Any help is welcome!

In case it is helpful for anyone, I want to hint to another PWM to analog converter that I found a while ago.

It is sold pretty cheaply on Aliexpress as a small PCB module called “PW1VA01”:
https://aliexpress.com/item/1005004402191795.html

It is based on an IC specialized for this task: Guestgood GP8101
Chinese Datasheet (try Google Translate for documents): https://datasheet.lcsc.com/lcsc/2202131930_Guestgood-GP8101-F50-NH-SW_C2837701.pdf

From what I found from my testing, it has strong advantages over the other typical modules:

• the output is absolutely linear and also frequency and supply voltage independent
• doesn’t need fiddling with an adjustment potentiometer
• it can achieve the full 10V on the output, even if the supply is a bit below 12V (so it works fine with the 12V-ish output of my VFD)

Slight downside: The module from above doesn’t have an optocoupler on it, so one needs to add one separately.

For myself, I actually hacked together a PCB in EasyEDA with an optocoupler and also some additional I/O channels:
https://oshwlab.com/hcsts/cncopto_copy
(please excuse poor design and use at your own risk … I’m not very experienced in circuit and PCB design)

Maybe some news:

• Just for fun, I have implemented support for the PlayStation 3 controller
• The limitation for the mentioned LogiLink Numpad is removed, so any keyboard can be used. But the key mapping might be less ideal on other devices.

And I have also made an attempt to implement some kind of continuous mode (move as long as button is pressed).

This can be found in a different branch: https://github.com/hurzhurz/Duet-USB-CNC-Pendant/tree/continuous EDIT: already merged into master branch
And here is documented how it works: https://github.com/hurzhurz/Duet-USB-CNC-Pendant/blob/master/doc/ContinuousMode.md

It uses the daemon.g to generate the actual movement commands. This is a bit hacky, but at least, it seems to work...

While it is not nearly as good as a real implementation in firmware would be, you could have a look on how I did an implemented for continuous mode in my Duet-USB-CNC-Pendant project.

The rough principle is described here: https://github.com/hurzhurz/Duet-USB-CNC-Pendant/blob/master/doc/ContinuousMode.md#working-principle

Changing the speed while moving would be possible, though I have not actually implemented that for the basic PS3 controller support. EDIT: just implemented it (in a separat branch for now)

I recently had a similar problem on the Y axis of my Anet A6 that I still use sometimes.

Problem was the cheap belt included in the kit.
It had stretched... maybe because of over tightening and the heat of the heatbed above.
And I think that happened pretty suddenly within a short time span and not just over time...

Well, and I had an other problem where I dripped hot glue on the pulley of the X axis and didn't notice it... it was just a tiny amount and barely visible, but was enough to increase the effective diameter (unevenly).

Like @t3p3tony, I would also suggest to test by moving the axis and to measure the actual moved distance, maybe also in e.g. 10mm steps to see if the error is conststent or not.

@chimaeragh said in USB CNC Pendant project:

@hurzhurz Will this work with the 4 axis version, WHB04B-4? I don't need to control that many axes and it seems to be half the cost of the 6-axis on AliExpress

I can't tell for sure, but I think the chances are good that the 4 axis version works as well.
For the most part, I used the protocol description from the LinuxCNC driver: https://github.com/LinuxCNC/linuxcnc/tree/master/src/hal/user_comps/xhc-whb04b-6
I think I read a comment somewhere that the WHB04B-4 was used successful with the LinuxCNC WHB04B-6 driver by someone.
And I can't imagine that there would be a difference needed in the protocol.

Though it could be that the dongle of the 4 axis version has a different USB PID. But that would be trivial to fix.

@gloomyandy Oh ok, you are right. And now I see it is actually discribed that way in the documentation, dispite the pin-name examples suggest it is like the way I thought it is.
Well, and my own VFD also has forward-run and reverse-run inputs... maybe it doesn't care if both are active and gives priority to the reverse input.

Maybe the implementation in RRF is not that optimal?

@NineMile maybe you can build a little circuit with a logic gate to convert the signal

@NineMile Actually, it works in the way you need it, with separate run-pins for forward and reverse:

M950 R0 C"pwm_pin+forward_pin+reverse_pin" Qfff Laa:bb

(see example in the GCode dictionary under "M950 / Configuration examples and notes / Spindles")

@ajmartins Great, happy to hear that!

@ajmartins It looks like the Duet Software Framework (DSF) is version 3.4.6 (you are using the Duet together with a Raspberry Pi, I guess?), but the Firmware on the Duet is just 3.1.1

@ajmartins Which version of RepRapFirmware have you installed?
I'm wondering if the macro parameters or the exists() function for them is "too new".
On my machine I'm running 3.4.6. And from the changelog I guess that at least 3.3 could be required.

@ajmartins The errors look like these two lines might be missing in your config.g, can you check that?:

M98 P"pendant-continuous-init.g"
global run_daemon=true

Or you can run them manually in the console once for testing.

And about your other question, doesn't your WHB04B-6 show the coordinates on the LCD?
It should work automatically...

@meeloo You don't need to use my whole project, you could just look how I implemented the continuous mode in a G code way: via macros and especially the usage of the daemon.g.

If you want to try that (without Arduino etc.), you can prepare the macros like described here:
https://github.com/hurzhurz/Duet-USB-CNC-Pendant/blob/master/doc/ContinuousMode.md#preparation

Then, to command a continuous movement, you have to send this command every 500ms (or more often):

M98 P"pendant-continuous-run.g" A"X" F1000 D1
# for moving the X axis in the positive direction with a feedrate of 1000

If the regularly sending of this command stops, the movement will automatically stop after a short time.

To immediately stop, you can send:

M98 P"pendant-continuous-stop.g"

Again, this not a perfect solution and you will notice a little delay, but I think it is working well enough.

While it is not nearly as good as a real implementation in firmware would be, you could have a look on how I did an implemented for continuous mode in my Duet-USB-CNC-Pendant project.

The rough principle is described here: https://github.com/hurzhurz/Duet-USB-CNC-Pendant/blob/master/doc/ContinuousMode.md#working-principle

Changing the speed while moving would be possible, though I have not actually implemented that for the basic PS3 controller support. EDIT: just implemented it (in a separat branch for now)

@IlI_Cnc You actually have two ports on your board where a PanelDue can be connected, the 10-pin "PANEL DUE" connector and the 5-pin IO_0 connector.
Both share the same serial interface (that you can enable with M575 P1 B57600 S1).
The 10-pin connector is used if you want to use the SD card slot on the PanelDue.
https://docs.duet3d.com/en/User_manual/Connecting_hardware/Display_PanelDue

I would suggest using the IO_0 connector like shown in my wiring diagramm on GitHub.

@oliof said in USB CNC Pendant project:

Great work @hurzhurz. It would be cool to see if you (or anyone else) could adopt the FluidNC M5Dial Pendant as well.

Thanks!

The FluidNC M5Dial Pendant looks like another neat solution!
And as it is already made to communicate via serial / G-code commands, it should probably be not that hard to adapt.
Most work should be needed for the part with the status display for coordinates etc.