Control Pendant Support w/ Jogging Encoder #70

People have made pendants that communicate via telnet. There is some code for displaying stuff on an oled display in the code base, enabled via #defines in Config.cpp. I have a long-term plan to make a menu system that is controlled from a rotary encoder, but it is taking back seat to a whole raft of other tasks including bug fixing. There is a Makerbase product that uses Grbl_Esp32 and includes a touchscreen, but they have not yet released the source code so we don’t know exactly what they did.

This is definitely something that some of us are interested in, but right now we do not want the distraction of thinking about it because we are up to our eyeballs in more urgent tasks.

I came here looking for this.
We need pendant support in a lower layer, not over uart (or other channels that transmit gcode).

Just an idea: it could be done with USB Host HID on the main mcu and a simple gamepad.
Analog joysticks on a gamepad could move an axis with variable feed.

I would love to jog my machines accurately

Esp32 does not have a USB interface. The modules usually have a USB to serial chip that connects to the UART serial lines on the ESP32

I think it might be useful to clarify what you see the problem as being.

It sounds like one complaint is queuing up too many jog operations?

Or is the problem the latency of response to a jog request?

But it’s a bit confusing because you’re mentioning accuracy at the end.

Maybe it can’t be solved in the short term, but expressing the problem clearly would be useful for future reference.

I think it might be useful to clarify what you see the problem as being.

It sounds like one complaint is queuing up too many jog operations?

Or is the problem the latency of response to a jog request?

But it’s a bit confusing because you’re mentioning accuracy at the end.

Maybe it can’t be solved in the short term, but expressing the problem clearly would be useful for future reference.

I think it could be a combination of both, particularly with telnet. The web interface is not responsive enough, and it’s easy to accidentally click too many times or in the wrong spot, which is why a pendant would be much better.

A UART pendant might work ok, but it is a huge undertaking for me to try and write arduino code to convert the pendant input to g code and interface to the ESP32. So I can’t really say if that will solve the problem or not until I try it.

So it takes too long to start the motion after you press the button?
I hadn’t noticed that being an issue, it seemed pretty responsive.

Or is it that it lets you queue jogs up while in motion?

Or is it about being difficult to cancel the jogs when they become excessive?

For me, the issue is probably just a combination of network latency and the inherent potential for mistakes interacting with a webpage using a pc or tablet.

I can queue up 5 jog moves and it might take 10 or 15 seconds before it starts to execute the first one. Hardware inputs directly connected to the board would be way faster, and that immediate feedback is helpful.

There is also something to be said for the tactile feedback of a handheld controller while actually looking at the machine in motion. That is how most machine operators in real shops jog the machine around, and I think it is a more intuitive and “accurate” way or doing it vs looking back and forth between the computer screen and the machine and trying to guess how many clicks you need.

Jogging – especially the realtime kind where the user presses a button to start and releases to stop – is more complicated that you would think due to the latencies in the various steps and queues from input acquisition, gcode parsing, motion planning, and motion execution.

That said, here is an idea for a quick and dirty way to hack in sort of a pendant. The idea is that you use some ordinary channel like serial or telnet or web to set up the parameters – axis. direction, and scaling – then have a single “go” button that is directly connected to a GPIO pin. When that button is depressed, insert a $J= jog start command into the queue via the same method that is used for macro buttons, and when it is released, do the same thing that the JogCancel realtime character does, namely set the rtMotionCancel flag.

Esp32 does not have a USB interface. The modules usually have a USB to serial chip that connects to the UART serial lines on the ESP32

I can see that ESP32-S2 has USB On-The-Go.

I think it might be useful to clarify what you see the problem as being.

It sounds like one complaint is queuing up too many jog operations?

Or is the problem the latency of response to a jog request?

But it’s a bit confusing because you’re mentioning accuracy at the end.

Maybe it can’t be solved in the short term, but expressing the problem clearly would be useful for future reference.

A useful jog controller should provide the following functionallity (speaking of experience):

• Press the move button: machine starts movement towards required direction
• While button pressed: machine keeps moving
• At the moment the button is released: the machine stops moving ASAP

What we experience is that if we ‘continously’ press the jog button, commands stack up, thus we are unable to determine when/where the machine will stop.

Personally, I strongly believe this can only be solved by providing an extra header on the expansion board for connecting a jogging controller or an MPG pendant. All the commands (jog controller interface) should be processed at the core level e.g. if the machine is not executing g-code then the jog controller can be activated, if the machine is executing g-code the jog controller would be deactivated. The updated position is polled via UART so no issue on the UI side.

This is the way the jog controller is implemented by PlanetCNC controller and it is working amazingly:

https://planet-cnc.com/using-jogging-keyboard-with-planetcnc-controllers/

I would like to lay my hands on this and try to implement it but I am just jumping in the ESP32 world, meaning it will take some time.

That’s giving a much clearer picture

We’re talking about human response times here, which are pretty slow.
I imagine that if the machine is idle, then it should be possible to have a good response time even via a network interface.
I think using the realtime jog cancel that Mitch mentioned above this sounds doable.

I’ve been playing around with network io — I’ll see if I can put together a proof of concept in a couple of days that lets it be controlled from a web browser.

Jogging – especially the realtime kind where the user presses a button to start and releases to stop – is more complicated that you would think due to the latencies in the various steps and queues from input acquisition, gcode parsing, motion planning, and motion execution.

That said, here is an idea for a quick and dirty way to hack in sort of a pendant. The idea is that you use some ordinary channel like serial or telnet or web to set up the parameters – axis. direction, and scaling – then have a single “go” button that is directly connected to a GPIO pin. When that button is depressed, insert a $J= jog start command into the queue via the same method that is used for macro buttons, and when it is released, do the same thing that the JogCancel realtime character does, namely set the rtMotionCancel flag.

Seems to me towards the right direction.

I think what someone alluded to earlier in the conversation, and I share this thought, is that the latency could potentially be minimized by controlling the jogging on the hardware level? If we had GPIO inputs for an encoder or even just a jog button with direction and step count controls, wouldn’t that lower level signaling be more responsive than converting to gcode, sending across the UART, then decoding again?

1. The key to preventing too many jog commands from queuing up is to make each command move only a short distance.
2. USB is a huge can of worms
3. Support for the S2 in and of itself is a substantial task. Maybe somebody could get a demo working quickly, but there is a world of difference between a demo and a supportable product.
4. Human response time to seeing an event and pressing a button is on the order of 300 milliseconds – an eternity of computer time. But see (1) above. If the motions that are initiated by individual jogging step events are longer than the auto-repetition rate of the events, overrun will occur. The key is to either make the individual motion times correspond to the repetition rate, or else use jog cancel.

Solving this problem will require analysis of the system at various points. So far what I have seen in the commentary above is guesswork and wishful thinking that some shiny new thing will magically solve the problem.

I tried different solutions making a pendant for fluidnc and ended up building one around an esp32 (actualy a Lilygo T4 1.3, which has a little integrated tft-screen). It sends grbl-commands and receives status-updates over (serial) bluetooth. It has buttons, a joy-stick for XY-movement as wel as a rotary encoder for moving Z (or per choice X or Y) and for navigating a simple menu. It’s battery-driven in a 3d-printed enclosure. Happy to share details if anyone is interested.

Hi, I would love to repeat your design, please share details.

You will find a first description and files here: https://github.com/gjkrediet/Fluid-controller.

You will find a first description and files here: https://github.com/gjkrediet/Fluid-controller.

Thank you! I am not an openscad user, I was able only export to the stl the lid. The case is grayed out, I could not make it active to render. Can you publish the case stl file?

I added the STL-files. About the scad-file: The %-sign makes a part transparent and it won’t be rendered and exported. Remove it from line 10 and put it at the beginning of line 77 to make the lid transparent. I put a comment about this in the scad-file. Good luck!

@gjkrediet Many thanks! Based on your design I did a version that works over Wi-Fi using web sockets. A lot of code shuffling but the main code is mainly yours. Had to write though a separate library for FluidNC comm and parsing using Websockets. This is the link: https://github.com/AC8L/FluidNC-Pendant.

Hi guys; I try to build this pendant for a mini Lathe build that, I want to run in 2 modes, 1 as automatic with G-codes, 2. fully manual that is run by the pendant, X and Z I will run from joystick but rotation of the chuck I want to set by a fixed value like M3 S1000 (spindle ON speed 1000 rpm ) and M5 spindle off, how can this be implemented in the code in best way you think ?

// Thanks

Supposing you are referring to the pendant on my github… I ‘m not sure I understand your question. I suppose the best and safest way is to create a dedicated button and catch it in loop() and let it send the suitable commands. Instead you could use a combination of existing buttons (like green and yellow perhaps). You could set de initial value of setSpindleSpeed to 1000 and you should change the lower limit and higher limit (now 3000 and 24000) to a suitable value or even disable the section for setting the spindle speed.

You should perhaps first look into the possibilities of fluidnc. The pendant does not concern itself with the way the spindle-speed is reached. In my case the spindle is a VFD-type via RS485, but as far as the pendant concerns it can be anything that fluidnc is capable of driving. It just sends the appropriate grbl commands. To my knowledge fluidnc only outputs to (variations) of analog, PWM or RS485 type of drivers. So fluidnc will only work if your stepper-spindle (or what drives that) accepts those types of signal for controlling speed.
As for the bluetooth-link, mine is working flawless. What is the exact nature of the disturbance you experience?

+1 on wanting this implemented directly. The Wifi controller is handy but i’d love to have something directly feeding to the system.

grblHAL has implemented such a system where you can use Serial or i2c to interface a pendant. If something like this was implemented it would be great.

https://github.com/grblHAL/Plugin_keypad

You will find a first description and files here: https://github.com/gjkrediet/Fluid-controller.

Hi @gjkrediet , cool controller project you’ve made! I want to try to recreate it myself but I just have a few questions. Anyway I can get in touch with you? Like discord or something?