I don’t have it, I just bought the board and am building a lowrider with it. I also do not see the added value for me. I could either use an XBbox-Controller with Estlcam or, like I do now, a little Bluetooth keyboard.
And you are right, for the wheel you need to use the LAN-cable. The guy seems to be pretty creative as well, I guess you two would get along splendidly. 
Very nice implementation!
I’m in the process of deciding how to add a pendant to a CNC mill I’m building. I’m using the same GrblHal breakout board that I (believe) you are using, so I find your design quite compelling. How are you connecting the “receiver” to the Teensy running GrblHal? And are you willing to share your software implementation? While I doubt I would use it directly (I plan on my pendant having significantly less functionality than yours) I do think have it as a starting point would be a great help.
I have a serial output (UART) of the Receiver ESP32 connected with a shielded cable to the Ser1 connector on the T41E5XBB breakout board by Phil Barrett. The Receiver uses the T41E5XBB board’s “Strobe” (A.K.A. ST, KPSTR) line (pin 41 of the Teensy) to take control using the “MPG” signal in grblHAL. I am happy to answer specific questions about the software (or anything), but it is not quite at a level for public distribution yet. I am also working on drawing up the schematics, and learning KiCAD.
I have been taking photos of the pendant build process, and putting them into a Google Photos album. This will give you some idea of my prototyping process.
It does not include the much longer time spent at the computer coding and debugging.
Be sure to click the i with a circle around it to see my captions!
Photo Album:
Thanks. Here are a few more questions for you when you get a minute:
Were you able to use one of Phil’s pre-built firmwares for the Teensy, or did you have to compile it yourself? I see he has some with the “KEYBOARD” enabled, but I didn’t see any mention of any with “MPG” enabled…
If you built the firmware (for the Teensy) yourself - which build platform did you use? I was hoping to use platformIO, but that doesn’t seem to be one of the preferred setups…
I’m assuming you are using the grbl v1.1 jogging commands ($J=…). Is this correct? It seems the obvious approach, just wanted to verify…
My plan is for a simple pendant that performs jogging only. Current approach will be an ESP8266 handling the pendant controls and generating the appropriate jog commands. ESP-NOW over to an ESP32s that will handle the strobe pin for requesting/releasing control and also performing a simple pass-through of commands and status reports back and forth between the ESP-NOW connection and the serial port. My thinking is to limit what the ESP32 is doing because it will live in my main control box (with an external antenna) and I don’t want to have to reflash it every time I want to tweak the pendant generated gcode…
I did not use Phil’s firmware, but got mine from the grblHAL Drivers section for the teensy’s processor, iMXRT1062.
I used VSCode/PlatformIO to edit a few things like the pinout of the MPG signal and my grbl defaults. It works well. But a key point for grbl (at least using the IOsender user interface) is that you can set all the relevant operating parameters in a GUI (IOsender), no recompiling and flashing needed.
Yes! I am using the $j= commands for jogging. But also a lot of other “real-time” commands such as 0x80 (brief status report), 0x84 (Door alarm, used for Pause/halt), etc. See the gnea/grbl wiki for a list of those.
The ESP32 can be re-flashed over the air (OTA). I did that routinely with a different project (using the arduino IDE) and it worked great, except that my project spent most of its time asleep, so I had to put a flashing light in a ping-pong ball that I could see from my window, to let me know when it was awake and I could reprogram it. It was monitoring my heating oil tank.
Your motivation for wanting to put most of the code on the pendant’s ESP8266 MCU rather than the Receiver ESP32 seems a good one. Why not use an ESP32 in the pendant rather than the more limited ESP8266?
Mostly it’s simply because I have a couple of the 8266 based boards on hand. Also though, I believe the NodeMCU boards have more available IO than the ESP32 based boards. My reason for going with the ESP32 board in my main control box is the availability of an external antenna. My control box is steel and I’m concerned the built-in antennas on the ESP boards wouldn’t handle that very well.
The final hardware selection is subject to change though as I get deeper into the design. For example I discovered today that the ESP8266 only has one and a half Serial ports. Not a show-stopper for me, but it did through a monkey-wrench into my original plan for working step-wise up to a complete prototype…
Hey folks, I have (finally) put all my ESP-NOW wireless pendant code up on Github! I was waiting to polish it up and add some features, but that may never happen because it works so well. I am not motivated to improve it. So I figured, let others improve it if they want, or maybe they will just get some ideas for a related effort.
Have a look, and if you find it useful, I have a Support button there you can help me with funding future projects.
Open Source C code for my Pendant and Receiver ESP32s
Cool!
I smile every time I read this thread. L
Great work.
I know I’m necroing an old thread but I do want the OPs input and its kinda related.
The recent chat about the CYD pendant interface cables got me wondering something.
Maybe as a esp-now user you (or anyone else) have a view on how viable this is:
Could you use a pair of esp32c3 or c6 running esp-now in peer to peer mode as a wireless UART bridge, transparently as far as FluidNC is concerned?
(A) plugs into the jackpot expansion port
(B) plugs into the CYD (or FluidDial)
Could this be a simple drop in replacement option?
The CYD already has a battery connector and charging, you’d add a hardware switch to power it off and on or use USB power.
Yes, totally. This sounds like a worthwhile project for someone like Bart Dring. Jackpot runs on an ESP32, so you don’t even need 3 ESP32s.
There’s an esp32 in the CYD as well but I don’t know annything about esp-now to say if you could include it with the existing firmware.
The c6 boards are so cheap I would be happy to sacrifice a couple to make a standalone bridge.
Solves the esp protection question if nothing else 
I’ve wanted a FluidNC ESP32 plugin module for something like this. I didn’t ponder using ESP-NOW but that sounds reasonable. I prefer wireless pendants. This would offload some work.
I made a wireless pendant using a websocket direct to the Jackpot ESP32 but I like the idea of offloading that connection.
