Rotary encoder jog pendant?

[arcadeperfect]

Hi,

Is there any way to integrate a rotary encoder for manual jogging while at the same time keeping GRBL connected to a pc via serial?

[bdring]

Many gcode senders allow the use of some form of pendant.

..although a smart phone makes a pretty good one IMHO. Already supported via BT and Wifi.

[MitchBradley]

My guess is that you would quickly run out of pins on the ESP32. That's the one failing of ESP32 - it doesn't have enough GPIOs to do all the things you would want. By the time you allocate pins for step and direction for several axes, SD card, UART, limit switches, and whatnot, you are pretty much out of pins. There is some talk of adding I2C IO expanders, but that is not yet a done deal.

One approach would be to use CNCjs or some other sender and make a jogging pendant, but that has its own set of problems. The most difficult issue is that every operating system has its own set of capabilities and restrictions around random I/O devices. What seems easy in principle turns into a lot of work and a seemingly endless set of gotchas in practice.

[MitchBradley]

Hmmm. Since you are using a serial sender, it should be possible to make a jogging pendant from another ESP32 - or even an ESP8266 - that talks to Grbl_Esp32 over BT or WiFi. "Small matter of programming", as we say with tongue firmly in cheek.

[arcadeperfect]

For the sake of argument, if all I needed was one encoder and one push switch, hard wired directly to the esp32, how feasible would it be to modify the grbl code to jog one axis via the encoder?

[MitchBradley]

Quite feasible if one is a programmer. You need 3 I/O pins that could, for example, be stolen from mist, coolant, spindle enables, assuming that you can live without those. That is not to say that anyone is stepping up to do it.

[karoria]

@arcadeperfect your question is similar to mine just asked yesterday. #333. Let me tell you a way I am already using. If you use PC (host) with usb serial connected with grbl, you can make a customized shortcut keyboard using any board which is "hid" capable. I am using pro micro which is cheaper and gives approx 16 io. You can program that board for any keyboard shortcut or a character set to be sent just like you have typed on a physical keyboard. You can send combinations (eg, Ctrl + Alt + S) too. I have also programmed for encoder for feedrate override increase/decrease/reset (lots of tutorial/videos available on net. you can search for volume control with pro micro and encoder). All the keys defined on that board works like a charm (when spindle is off) which is connected with usb cable to my host PC RPi4 which is again connected with grbl_esp32 via usb (just like yours). But once spindle turns ON...the machine starts dancing (because I have written shortcuts for jog and other commands which creates motion)! Noise is real enemy. The theoretical program (though it is all right) doesn't work as is !! So I modified the buttons programs (eg, for Homing, keyboard shortcut in cncjs is ctrl+alt+cmd+H, so I defined one pin on pro micro to send this key combination) to look for the closed circuit (when it becomes low) two times at 5ms interval and that created magic. Now it works well. But I am lost with putting such delay in the program for encoder which is logical in nature (so many if else for finding whether it has turned clockwise or anticlockwise). This is where I am standing now. That is why I have created #333 because, if I get a shortcut solution which is directly from grbl firmware, that will be more reliable and for noise part, we can go for proper circuit design with capacitor filters and/or optocouplers. However, I like the approach mentioned by @MitchBradley as to send data with another esp32 board via BT or wifi. Because it will go directly to grbl (and not to host PC). I consider it more reliable way. @MitchBradley can you throw more light on it? As I have never used board to board communication. Further, it may involve creating specific changes (shortcut keys for functions) to grbl firmware. @arcadeperfect , I hope this explaination helps you in taking some decision until any concrete support is created by experienced developers.

[terjeio]

Usable code snippets may be extracted from my MPG implementation for Grbl. It requires handling of (only) two extra pins on the Grbl side, one for mode switching and one for an addtional serial input.

Jesse Schoch is currently experimenting with this approach/interface using some of my MPG code (AFAIK the grbl response parser) on a different processor (a STM redpill?).

[dedekcz]

maybe stupid question, but what about to use Bluetooth connection? and use Bluetooth keyboard as control device?

[arcadeperfect]

Not a bad idea! For my purposes what I really want is an encoder to tweak the z height of a pen plotter to set the tension. There is a rubber band that gets stretched the further the z axis continues to lower once the pen hits the paper. So, every time a pen is put in it needs to be manually tweaked. Very annoying with regular jogs, always changing the step size.

So naively I thought it would be easier to hard wire the encoder to the main EMC32 but perhaps bluetooth is the way to go, if it's possible to write a bluetooth client that runs on another micro controller rather than using the smartphone software.

Also, ideally, the dial would adjust the the physical height of the z axis without updating the grbl's software's position. Don't know if that would be possible, but maybe more likely if you're tapping straight into the grbl code?

On Tue, Feb 18, 2020 at 12:06 PM dedekcz notifications@github.com wrote:

maybe stupid question, but what about to use Bluetooth connection? and use Bluetooth keyboard as control device?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdring/Grbl_Esp32/issues/335?email_source=notifications&email_token=ADJXMI4VFJ7HOVD3BOTI4R3RDQIRBA5CNFSM4KWXQAZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCZJ7Y#issuecomment-587568383, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJXMIZGDQPGXCTNFFF5YT3RDQIRBANCNFSM4KWXQAZQ .

[MitchBradley]

There are many possibilities. It all boils down to either learning to program or finding a programmer willing to do it. The programmers I know, including myself, are all busy with other projects.

[arcadeperfect]

I can code in higher level languages, with some arduino experience but nothing as sophisticated as grbl. More than willing and eager to put in the time and do the legwork, just trying to work out which garden path to go down...

[MitchBradley]

Without actually doing the project, I cannot say what problems you might encounter, but here is one approach that, at first glance, seems like it might work:

• Enable bluetooth on Grbl_Esp32. I haven't looked at the BT code in great depth, but I think it uses the BT connection as an additional serial port.
• Program another ESP32 to be a bluetooth serial port. In the Arduino IDE there is bluetooth example sketch that you could use as a starting point
• That example sketch just transfers data from the regular serial port to the BT serial port. You would modify it to sense the encoder and switch via GPIOs, then send standard GCode commands out over the BT serial connection. I'm sure you can find example code for reading encoders on the internet.
• The GCode commands that you send would be jogs. If you want the jogs not to change the work position, you would also need to send GCode commands to update the position afterwards.

[arcadeperfect]

Thanks for the advice!

That plan seems to on the fringes of my arduino skills so a good one to push my boundaries. And nice to use another controller so I don't risk breaking the grbl code and could add a display or more inputs.

[jschoch]

I have had success using @terjeio grblHAL and there isn't any big blocker from using it with this port other than the coordination of the input serial (bt or hardware UART). This requires one pin to toggle the 2nd UART input on/off and one pin for the 2nd UART's RX. terjeio's sender can recognize the MPG mode turning on/off and works well over both USB and bluetooth. It would be nice to standardize this across ports. I chose a bluepill STM32 so I could actually use 3 encoders which it does quite well. My prototype can be found here: https://github.com/jschoch/grbl-MITM-pendant/tree/grblHAL_testing

I also poked at using BLE a bit which would work fine assuming that a standard uart over BLE protocol could be agreed on or someone could create a more native BLE protocol. An alternative would be to use something like a JDY-23 to connect to the 2nd UART. Bluetooth classic Serial is much cleaner but I don't think you can have 2 devices connect and it would be a shame to not be able to have the sender connected via BT.