Probing Scene Increments by 4

[theoutfield]

This is a really neat project thanks for your hard work!

I started playing around with making a wireless MPG and I stumbled across this while researching. I'm working with a grblHAL machine so I'm guessing I'm going to need to make a few changes here and there. Since FluidNC and grblHAL are both cousins for GRBL I believe it's possible to get it working. If anyone has tried it I would love to hear how it went.

I really want a wireless MPG because I've been using one with my Mach3 machine. My plan is to modify this project to use ESP-NOW. From what I've gathered in the code most of the changes need to be done in System.h and SystemArduino.cpp. I have a BTT Scylla board with an ESP32 module on it for wireless communication. My plan is to turn that into an ESP-NOW to UART bridge to communicate with the STM32H7.

I have the CYD and 100PPR encoder wheel. In order to tryout the screen without connecting this to my CNC I just added a line to fool the display into thinking it was connected.

FluidNCModel.cpp
bool fnc_is_connected() {
int now = milliseconds();
//Added for testing Tony June 02
return true;

I started messing around with the screens. Most of them work great. The probing screen was incrementing all values by 4 though. I'm not sure if this is a bug or something setup for the M5Dial encoder. After reviewing the code for the other screens I noticed most of them (all???) call the constructor with an encoder scaling of 4. I modifed the code as shown below and everything worked afterwards.

ProbingScene.cpp
public:
//Tony Modified June 2
ProbingScene() : Scene("Probe",4) {}

[MitchBradley]

The M5 Dial has detents every 4 pulses. Actually it depends on how you configure the code that reads the encoder signals. If you register a pulse on every phase transition, the detent is every 4 pulses. If you configure it to register a pulse on a complete cycle of 4 phases, there is one pulse per detent.

FluidNC and grblHAL share the base GRBL line protocol, GCode parser, and motion planner, but have different solutions for extensions like how to handle extra input sources like files and alternative serial input channels. "A few changes here and there" could turn into quite an effort.

[theoutfield]

Thanks Mitch. I didn't mean the few changes here and there as a simple task. I was impressed with how well the code was done because I didn't have to jump all over the place looking where to find the communication functions. grblHal does have a plugin "KeyPad" that enables KeyPad and or MPG I2C/UART port communication. The ESP32 on the Scylla board is already connected to an STM32H7 UART so it should be doable. The single character "realtime" commands are what I believe would require investigation. grblHAL needs to see a 0X86?? code to enable the MPG and then I believe it will just relay the UART commands to the default parser. If this is indeed true then the commands that the M5Dial is transmitting should work. I'm going to give it a crack and see if it's within my abilities. I'm sure there are more grblHal users than just myself who might find this useful. I'm not partial to either grblHal or FluidNC. The BTT Scylla board was very appealing so I'm working with what I have now.

The 100PPR encoder also has four counts per detent so the ProbingScene.cpp should be updated. If you have the M5Dial you could verify it.

Tony

[MitchBradley]

The xon/xoff flow control could be an issue. We use it to allow high speed communication without overrun, especially for stuff like sending large blocks of data like directory listings.

Another issue related to listings is the way we encapsulate such non-GRBL data in a JSON document that is further encapsulated in [... ] lines to conform to GRBL protocol rules

Helping GrblHAL users is not high on our list, especially if it results in extra support requests from people who are outside our ecosystem.

Some years ago I proposed coordinating on grbl protocol extensions and message formats, but Terje was not interested so I did not pursue it further.