Teensy4 with MPG_ENABLE

[kizmit99]

Hi all. I'm having an issue getting grblHAL running on the Teensy4.1 when I enable MPG_ENABLE (and KEYPAD_ENABLE). If I build and install the firmware on the teensy (using PlatformIO) with those options enabled, when I try to connect to the teensy using ioSender it doesn't connect and after a few seconds of "Waiting for controller..." I get an error dialog with the message "No response received from controller, exiting." - then clicking on the OK button closes ioSender. If I build the firmware with MPG_ENABLE and KEYPAD_ENABLE commented out (in my_machine.h), ioSender can connect to the Teensy and it seems to work as expected.

I'm building a MPG/DRO pendant and I had everything working (on my bench) a couple months ago, but I've recently gotten back to it and pulled the latest grblHAL and ioSender releases and now I'm running into the issue above. I've stripped my testbed down to just a stand-alone Teensy4.1 and haven't been able to unravel this issue. Just looking for a pointer where to look next.

For some more background on my setup. I'm using the latest grblHAL/iMXRT1062 from github. Using platformIO to build and deploy the firmware to a stand-alone Teensy4.1. The only changes I've made to the distro are in my_machine.h and in there I've uncommented the define for BOARD_T41U5XBB (which is the breakout board I'm using in the actual build). With the "working" firmware on the teensy, if I connect to it via putty (instead of ioSender) it responds as follows to <enter>, ? and "$i<enter>":

ok

?<Idle|MPos:0.000,0.000,0.000|Bf:35,1023|FS:0,0|Pn:PXYZ|Ov:100,100,100>

$i
[VER:1.1f.20230601:]

[OPT:VNMSL,35,1024,3,0]

[AXS:3:XYZ]

[NEWOPT:ENUMS,RT+,ES,REBOOT,TC,SED,RTC]

[FIRMWARE:grblHAL]

[NVS STORAGE:*FLASH]

[DRIVER:iMXRT1062]

[DRIVER VERSION:230526]

[DRIVER OPTIONS:USB.2]

[BOARD:T41U5XBB]

[AUX IO:4,3,0,0]

ok

The firmware built with #define MPG_ENABLE 1, #define KEYPAD_ENABLE 2 gives the following with putty:

ok

?$i
[VER:1.1f.20230601:]

[OPT:VNMSL,35,1024,3,0]

[AXS:3:XYZ]

[NEWOPT:ENUMS,RT+,ES,MPG,REBOOT,TC,SED,RTC]

[FIRMWARE:grblHAL]

[NVS STORAGE:*FLASH]

[DRIVER:iMXRT1062]

[DRIVER VERSION:230526]

[DRIVER OPTIONS:USB.2]

[BOARD:T41U5XBB]

[AUX IO:4,3,0,0]

[PLUGIN:KEYPAD v1.34]

ok

Note that it is not responding to the "?" request for status... I've been looking at this all day and I'm hoping someone can offer some insight. Thanks in advance for any info!

[terjeio]

Oops, it is a kind of a regression - I have added code to later allow non-serial pendants (Bluetooth, WiFi or Ethernet) to connect and it is a breaking change in some configurations.
Can you try with the attached USB code, this is modified to report back connected status so that data is only sent to the USB port when there is a client (ioSender) connected. This will also solve the problem where everything locks up if the pendant is the only connected client (due to the USB buffer getting full and blocking further output).
There is one small problem with this change though, senders has to assert the serial DTR line when connecting...

usb_serial.zip

[kizmit99]

Thanks @terjeio
The supplied changes did correct the issue.

While I have your ear... For my pendant I have been using a hardware handshake pin to request control, but I recently realized that the pin I was planning to use is an opto-isolated input on @phil_barrett's break-out-board. I believe this will effectively break the bi-directional intent of the handshake-pin. So I am considering moving to just using the CMD_MPG_MODE_TOGGLE command character to request control (basically just using the serial connection to request control instead of the dedicated handshake pin). Are there any practical limitations to using the command character versus the hardware handshake?

Thanks again for the quick fix to the connection issue!

[terjeio]

I believe this will effectively break the bi-directional intent of the handshake-pin.

It does. The pro version of the board can reroute the pin to the UART headers enable pin via a solder bridge, but AFAIK that board is not generally available.

Are there any practical limitations to using the command character versus the hardware handshake?

Nope.