Teensy 4.1 hangs at full buffer and trigger of emergency stop

[rcp1]

Hi,

thanks for your great work with grblHal.

I am encountering an issue regarding jogging. I am currently trying to implement my own gamepad driver for jogging in cncjs with grblHal on a T41U5XBB board and do send a lot of $J=G91G21X-3.3Y0.0Z0.0F1000.00 jog commands to grblHal. Moreover - due to the unfinished nature of my code or my laziness - I do not check for the Ack from grblHal. Thus, these jog commands stack up until plan and receive buffers are full.

If I trigger with full buffers the emergency stop pin the Teensy is becoming completely unresponsible, only a hard power reset helps.

It may be a stupid question, but is it expected that a full buffer leads to becoming unresponsive? Is it the task of the sender to stop sending in sight of a full buffer? grblHal is my first experience with grbl-based SW and I would have thought that the expected behavior is that grblHal becomes under no circumstances unresponsive.

I can recreate the crash / becoming unresponsive with IOSender, too, if I set the jog values to unreasonable amounts and jog like crazy with the keyboard on all axes:

  <Jog>
    <KeyboardEnable>false</KeyboardEnable>
    <FastFeedrate>3000</FastFeedrate>
    <SlowFeedrate>3000</SlowFeedrate>
    <StepFeedrate>3000</StepFeedrate>
    <FastDistance>300</FastDistance>
    <SlowDistance>300</SlowDistance>
    <StepDistance>300</StepDistance>
  </Jog>

Here are my build settings ($I):

[VER:1.1f.20211010:]
[OPT:VNMZSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,ES,EXPR,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210930]
[DRIVER OPTIONS:USB.2]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]

Thank you for your time.

[terjeio]

... send a lot of $J=G91G21X-3.3Y0.0Z0.0F1000.00 jog commands to grblHal

Avoid this, send a single long distance jog command on key down and jog cancel on key up if possible.

It may be a stupid question, but is it expected that a full buffer leads to becoming unresponsive?

It should not - is it a bug in my code or the Teensy USB code? Can you try with setting USB_SERIAL_CDC to 1 in my_machine.h and reflash?

Is it the task of the sender to stop sending in sight of a full buffer?

Yes! It is potentially dangerous to overflow the buffer as overflowing characters are lost.

[rcp1]

Okay, so in general this is already an edge case since the sender does / I do not care about the buffer.

And yes, I've just tested with USB_SERIAL_CDC as 1 and it happens, too.

[VER:1.1f.20211010:]
[OPT:VNMZSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,ES,EXPR,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210930]
[DRIVER OPTIONS:USB.1]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]

[dresco]

@rcp1 Out of interest, I was hacking around with a gamepad addon for CNCjs as well. Was working generally okay, but had a troublesome memory leak on the Pi that I never got to the bottom of..

I've just stuck my code up on github in case it's helpful to you - https://github.com/dresco/cncjs-pendant-gamecontroller

[rcp1]

@rcp1 Out of interest, I was hacking around with a gamepad addon for CNCjs as well. Was working generally okay, but had a troublesome memory leak on the Pi that I never got to the bottom of..

I've just stuck my code up on github in case it's helpful to you - https://github.com/dresco/cncjs-pendant-gamecontroller

@dresco Nice, you actually check for the acknowledge of grbl... I will probably copy that part... (see cncjs-pendant-gamepad for my current version)

[terjeio]

A pity that the Teensy is not debuggable otherwise I might be tempted to try to replicate this and find out where it hangs. But since it hangs when stressing the system beyond what I regard is safe (and is designed for) I will give it a pass for now.

What might be of interest to you is that I have modified they keypad plugin slightly so that input from a serial port or HID device can be used instead of a I2C keypad. The plugin decodes single character commands for many different functions including jogging. There are support for three different jog modes: fast, slow and step. Jog moves are terminated by sending a standard jog cancel command (on key up events).

A serial port interface will be the easiest to get working as many drivers has support for more than one port. A HID device will be more work and only a few drivers supports host mode(?). The Pro board by @phil-barrett has a connector for a second USB port so this could be used, it would be great if somebody could add host mode support for gamepads to that....