Pendant MPG DRO wireless for grblHAL CNC

[stevempotter]

I am planning to build a wireless pendant for my CNC (MPCNC Primo, controlled by Phil Barrett's Teensy 4.x Breakout Board).
I think that to use a pair of ESP32s and their ESP-NOW functionality will work well, based on some initial tests.

If you are not familiar with ESP-NOW, it is a low-latency proprietary communications protocol intended for controlling smart lighting and whatnot. It connects instantly and stays connected (paired) as long as the devices are powered on and in range (>100m), and each message can carry 250 bytes. They can power up and reconnect in milliseconds when switched on. Com can be encrypted if desired. All that is needed to pair devices is their MAC address. It does not use Wifi, but does use the 2.4GHz frequency range. You can use any combination of bidirectional broadcasting or narrowcasting, one-to-one, one-to-many (up to 20 devices). Here is more info: https://www.espressif.com/en/products/software/esp-now/resources
Here are the ESP-32 boards I am using: https://www.tinytronics.nl/shop/en/platforms/ttgo/lilygo-ttgo-t-display-v1.1-esp32-with-1.14-inch-tft-display

My question is: if we call the ESP-32 in the pendant the Sender and the one in the grblHAL box the Receiver, how do I go about interfacing a high-spec MCU like the ESP-32 to the Breakout Board running grblHAL? There will also be info going the other way (from Receiver to Sender), such as the current coordinates for the small LCD on the ESP-32 board. Do I use its ethernet connection, I2C, USB, or something else? Does the firmware already have hooks to take commands from pendants with lots of knobs and buttons (not a touchscreen or just a keyboard/keypad). Raised on old Tektronix oscilloscopes, I am a knob and button lover. Much preferred over touchscreen or mouse-controlled interface on a computer, or complex menu hierarchy to click through with one encoder button. I will be using a 1000 pulses/rev encoder for the MPG, and also an RC joystick with Hall effect sensors.

Any advice on how to get started on the interfacing will be appreciated!

[phil-barrett]

Take a look at the I2C keypad code. It might be possible to just generate the codes that the plugin expects. I'd be happy to help out with the hardware side of things as this is a topic near and dear to me. I have several designs that use the I2C header that could easily be adapted.

Perhaps this topic should be moved to grblHAL/Plugin_I2C_keypad though there isn't a discussions section. Terje, anything against enabling that?

[stevempotter]

Have things advanced since then in terms of proportional pendant/joystick implementations?

I believe the current interface can be used, but improvements are needed on the sending side. Phil seconded that above. So no, nothing has changed since that interface was added.

The grbl jogging page says:

Flash and memory restrictions prevent the original envisioned implementation...

Since we are using much better microprocessors in grblHAL than an Arduino with grbl, doesn't that imply that such limitations no longer apply and we can dream big about how to implement pendants?

[terjeio]

Since we are using much better microprocessors in grblHAL than an Arduino with grbl, doesn't that imply that such limitations no longer apply and we can dream big about how to implement pendants?

Ok, I should have read that page again. I cannot remember seeing the provided formulas before, interesting.

Pendants can be implemented in grblHAL by adding plugins or driver extensions that submit jog commands to the core, the keypad and encoder plugins does that already. Pendands may simulate keypresses and or/use analog inputs and/or pulse signals, they might be connected via GPIO pins, USB, WiFi, Bluetooth and what not. So IMO limits are imposed by availablility of interfaces and/or pins in the MCU, not the core code. Stop dreaming and start writing code? You may even add pendant support without changing a single line of downloaded code...

[stevempotter]

OK, I am well along with the coding. Today I wrote the code that made bidirectional ESP-NOW comm very reliable on my two ESP-32s. I have transmitted over one million messages at over 400 messages/second without a single error so far. That is with the two devices 28 feet apart, with the sender on a Lipo battery, as it will be in the pendant. The trick was to make sure that the sender waits for its message to be echoed back to it from the receiver before sending its next one. When I do that, with no delay statements in the code, I am getting an average of 2.4ms per round-trip loop. That is with a small 8-byte message. It will take longer to send larger messages -- I will measure that at some point, and also the effect of encrypting the messages. But this has convinced me that ESP-NOW is ideal for wireless pendant signals where responsiveness and reliability is desired.

Getting the receiving ESP-32 to send gcode commands out its I2C lines should be straightforward, right?
Now I need to read up to understand grbl (which I have not used yet, I am using Marlin so far) and what is the difference between a plugin and a driver extension.

[terjeio]

Getting the receiving ESP-32 to send gcode commands out its I2C lines should be straightforward, right?

I guess so, but you have to make some kind protocol for that and add it to the grblHAL driver side as well. The keypad plugin can serve as an example for a simple protocol. Receiving the messages should be done in the background (via interrupts), submitting the gcode for processing should take place in the foreground process.

what is the difference between a plugin and a driver extension.

A plugin is not bound to a specific processor/driver, any hardware accesses has to go through the HAL or another well defined API. A driver extension access MCU specific peripherals directly and cannot be shared with other drivers without changes.

[stevempotter]

most people will not have an encoder with so many pulses per revolution (mine, soon to arrive, is 1000ppr with no detents, made for a servomotor shaft).

Great news! I have been playing with my 1024 ppr rotary optical encoder (OMRON E6B2-CWZ6C 05421M) and a library that makes use of the ESP32's built in pulse counters that do not require the use of interrupts. The library #include <ESP32Encoder.h> works like a charm! And if I use the full quadrature option (ROE.attachFullQuad(ROE_B, ROE_A);) I get 4096 counts per revolution from my 1024 ppr device! That means that even with very fast sampling (say, 2ms/sample) I usually get several tens of counts added or subtracted to the current count. This will allow precise jogging even at slow knob-turning rates.

[phil-barrett]

I've placed 3 kicad projects on I2C Headers.

[stevempotter]

Thanks, Phil, I will look with keen interest. BTW, what are Hlt and St pins in the I2C bus on your board? I see some mention of Halt and Strobe in your manual but have no idea what those are for in regard to I2C interfaces.

[phil-barrett]

Hlt is a pass-through to the grblHAL reset input on the Teensy. The idea is that if an MPG has an EStop button, you want that to go straight to the processor with nothing else in the way.

Stb is the strobe function and is used for signaling between the two devices (grblHAL processor and MPG/Key Pad/whatever).

[terjeio]

Stb is the strobe function and is used for signaling between the two devices

Yep, it is used as signal events (key presses as of now) and is active low. The device attached should use an open drain (OD) pin for signalling so that multiple devices can request attention (by wire OR'ing).