possible pendant/communication issue after a5ecb4c commit changes ....

[gyordanov]

I have a 4 axis cnc with smartpendant running on flexihal board, i'm using the serial to control my modbus vfd spindle, and the i2c port is configured as second uart for the smart pendant.
It has been working fine, until i updated the firmware (this repo) - the pendant has a hard time connecting with lots of "Com Error" errors and sometimes even usb/network(telnet) connections wont work, but websockets seem to work (strange stuff).

if i build from commit 12f5a76 - all is good
commit a5ecb4c - no good, com errors etc ...
commit a5ecb4c, but with the keypad module not update - still not good (i was trying to narrow the issue somewhat)
the last commit i tried was f96ba7f and it seems to have the same issue

not sure how to debug this or if its just a "me" issue caused by the 2 uart ports in use

let me know if i can try anything to help with this or any more info i can provide.

[terjeio]

Can you post your $I output?
I do not have a flexihal board nor a smartpendant, however when testing with a STM32F466 board and my own I2C pendant everything seems to work as it should.

[gyordanov]

yes here is $I from 12f5a76 (working just fine so far)...

GrblHAL 1.1f ['$' or '$HELP' for help]
$I
[VER:1.1f.20260320:]
[OPT:VNMZHTA0SL2,128,1024,4,0]
[AXS:4:XYZA]
[NEWOPT:ENUMS,RT+,HOME,PROBES=7,ES,MPG,REBOOT,EXPR,TC,SED,ETH,FTP,YM,SD]
[FIRMWARE:grblHAL]
[SIGNALS:HSEP]
[NVS STORAGE:*FLASH 16K]
[FREE MEMORY:9K]
[DRIVER:STM32F446@180MHz]
[DRIVER VERSION:260311]
[BOARD:Flexi-HAL]
[AUX IO:3,4,0,0]
[PLUGIN:Bootloader Entry v0.03]
[PLUGIN:Laser PPI v0.09]
[WIZCHIP:W5500]
[MAC:02:08:dc:d8:3c:86]
[IP:192.168.1.112]
[NETCON:Telnet]
[PLUGIN:FS stream v1.08]
[FS:FatFs@/ size 7.43 GB, free 7.43 GB]
[PLUGIN:FS macro plugin v0.22]
[PLUGIN:MODBUS v0.23]
[PLUGIN:H-100 VFD v0.11]
[PLUGIN:Keypad v1.44]
[PLUGIN:Macros v0.19]
[PLUGIN:SD Pause v0.02]
[PLUGIN:SDCARD v1.26]
[SPINDLE:H-100]
ok

i'll flash with the latest commit later and add that too.

[gyordanov]

and here is the output from the latest commit 223879c

GrblHAL 1.1f ['$' or '$HELP' for help]
$I
[VER:1.1f.20260326:]
[OPT:VNMZHTA0SL2,128,1024,4,0]
[AXS:4:XYZA]
[NEWOPT:ENUMS,RT+,HOME,PROBES=7,ES,MPG,REBOOT,EXPR,TC,SED,ETH,FTP,YM,SD]
[FIRMWARE:grblHAL]
[SIGNALS:HSEP]
[NVS STORAGE:*FLASH 16K]
[FREE MEMORY:21K]
[DRIVER:STM32F446@180MHz]
[DRIVER VERSION:260324]
[BOARD:Flexi-HAL]
[AUX IO:3,4,0,0]
[PLUGIN:Bootloader Entry v0.03]
[PLUGIN:Laser PPI v0.09]
[WIZCHIP:W5500]
[MAC:02:08:dc:d8:3c:86]
[IP:192.168.1.112]
[NETCON:Telnet]
[PLUGIN:FS stream v1.08]
[FS:FatFs@/ size 7.43 GB, free 7.43 GB]
[PLUGIN:FS macro plugin v0.22]
[PLUGIN:MODBUS v0.23]
[PLUGIN:H-100 VFD v0.11]
[PLUGIN:Keypad v1.44]
[PLUGIN:Macros v0.20]
[PLUGIN:SD Pause v0.02]
[PLUGIN:SDCARD v1.26]
[SPINDLE:H-100]
ok

[terjeio]

Thanks, which sender are you using and do you have a link to the smart pendant?

On thing to try is to comment out this code, it may delay $I output excessively.

[gyordanov]

im using gsender, but i did try ioSender when gsender did not connect initially and it behaved more or less the same, the pendant issue is apparent right away after i power up the machine, when i toggle MPG it shows com error and the machine does not respond to jogging commands (i did not have any senders connected to the machine at that point - just boot and try to jog a minute later kind of test)

the smartpendant is this one https://github.com/nickshl/SmartPendant with i believe the latest firmware released there

will try to comment the code later today and report back!

[gyordanov]

ok commenting the FS: chunk of code did not help, another observation: on boot - toggling mpg on the pendant will consistently show com error and jogging does not work, but if i run gsender and connect (telnet/networking) and then press mpg -> it will work just fine and jogging does indeed jog.

[gyordanov]

ok bunch more testing this weekend ... so compiled the latest unmodified firmware from this repo ...

1. boot the controller
2. try to control it from the pendant (toggle mpg, try to jog) - nothing
3. do telnet ip 23, i get this right away
   GrblHAL 1.1f ['$' or '$HELP' for help]

• if i type ? ... nothing back ..

4. leaving the telnet open, if i toggle mpg on the pendant - still nothing, but if i press Rst on it .... then on my telnet output:

<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0|S:0|WCO:0.000,0.000,0.000,0.000|WCS:G54|Ov:100,100,100|A:|Sc:|MPG:1|H:0,0|T:0|P:0|TLR:0|SD:1|FW:grblHAL>
<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0|S:0|WCO:0.000,0.000,0.000,0.000|WCS:G54|Ov:100,100,100|A:|Sc:|MPG:0|H:0,0|T:0|P:0|TLR:0|SD:1|FW:grblHAL>
<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0|S:0|WCO:0.000,0.000,0.000,0.000|WCS:G54|Ov:100,100,100|A:|Sc:|MPG:1|H:0,0|T:0|P:0|TLR:0|SD:1|FW:grblHAL>
<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0>
<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0>
<Idle|MPos:0.000,0.000,0.000,0.000|Bf:128,1023|FS:0,0,0>

and from that point on seems to work just fine! i can toggle mpg off, then on and pendant jogging works fine and ioSender connects and works just fine

if i try to connect ioSender right away (before pendant sends rst) ... nothing it errors that the controller is not responding and closes, so far the same behavior seems to repeat if i try to use web sockets or usb serial ...

its very strange and i dont understand what is going on, if i build from a5ecb4cf but undo the change in
FLASHMEM static status_code_t report_status_message (status_code_t status) function, then it works fine,
but if i build from the tip of the repo with the same change (undo report_status_message) .. it does not make a difference - it just confuses me on what is going on....

and FINALLY i did one more test:
left power to pendant plugged in, but disconnected rx/tx .... on controller boot -> both telnet and senders connect and work just fine right away, if i then connect rx/tx pins -> pendant also works fine ..

so it must be that the pendant is sending something too early or triggering something that puts the controller in a funky state ... so complicated ...

[terjeio]

if i type ? ... nothing back ..

This is normal with PuTTY, not sure about telnet clients in general - at least PuTTY, per default ,require one to press the <enter> key before anything is sent.

I have a SmartPendant that I updated to the latest firmware version (0.033.0) and it seems to me that it behaves oddly at bootup, claiming full control and then not sending any real-time status requests. This confuses ioSender.
It might be due to controller code changes if the MPG mode input pin is not pulled high at startup, I will add code to ensure that it is in the next commit. However, it get pulled up as it should with the controller I am testing with.
A workaround is to use the mode switch character instead of the physical input by building with MPG_ENABLE 2 and changing the pendant to use this instead - set MPG request to sw command in SETTINGS.

I will look at this issue a bit closer when I get time.

[gyordanov]

yes i did type enter after the ? in my testing above
i have MPG_ENABLE set to 2 and the pendant is configured to MPG request to sw command indeed ..

[gyordanov]

updated my SmartPendant to the latest fw 0.033.0 (was on 0.032 before) .. more or less same results, but now this morning ... i cannot seem to replicate it working with the tx/rx pins not connected during boot.

i have to send 0x18 (ctrl-x) for grblhal to start responding, without that it sends GrblHAL 1.1f ['$' or '$HELP' for help] but does not respond to anything else (both gsender and ioSender will not fully connect) ...

and as i was messing with ncSender i figured out why does it always work with it - it seems like ncSender always sends soft reset 0x18 on connect ... so that explains that ...

is the sort reset requirement feels like something maybe in my firmware config or the options i compiled it with ?
i don't think it does that with the build from commit 12f5a763

[gyordanov]

amazing - that fixes almost all of my issues!!!
i've attempted similar changes (well hacks) in order to narrow this somewhat ...

now another part that was for sure contributing to my frustrations .... and was for sure part of why this issue is/was clear as mud...

as i was testing this happens:

1. connect flexihal with usb to my laptop to flash, flash fw, disconnect and reconnect (to test cold boot) - everything works just fine (tested at least 2-3 cold boots)
2. disconnect the usb and connect a power only usb cable into the flexhal

• i can connect over telnet but only get the grlbhal welcome line and it will not respond until i send 0x18/ctrl-x - then it starts working perfectly again ...

i added a report_realtime_status(write, &hal.stream.report); to report_init_message just to see if i can see if any alarm code is triggered, but no difference in the status between usb-power-only and usb-to-laptop connection - both show idle and no alarm code.

not sure why it will behave differently, for all this tests i dont have a sender or anything that is trying to talk to grbl while connecting to my laptop, other than whatever the kernel does to init the serial ....

[gyordanov]

ok with the help of gemini (i know i know and feel free to just ignore any of that) ... this is what it supposedly found after i wrestled with it for a while ...

When the controller starts up, it initializes the USB peripheral. Because grblHAL often has auto-reporting enabled or sends an initial welcome message, it immediately tries to write to the USB
serial stream. If no USB host (laptop) is connected to acknowledge the data, the STM32's CDC_Transmit_FS function returns USBD_BUSY indefinitely. This causes the driver to enter a blocking loop,
effectively hanging the main loop.

When you connect via Telnet, the connection is handled by the networking stack (which may run in interrupts or be partially processed), allowing you to see the welcome message. However, the main
loop remains stuck in the USB transmit function. Sending 0x18 (Ctrl+X) works because grblHAL's realtime handler detects the reset flag and breaks the blocking loop, finally allowing the main loop
to proceed and switch the active stream to Telnet.

i'm sure what it did is not how it should be done, but maybe it will be helpful starting point on a proper fix ... this is for sure STM32F4xx specific but maybe similar issue exists in other drivers ... patch attached

tested it laptop powered - both usb-serial and networking work perfect, and usb power only cable - networking works perfect (cannot test usb-serial as well we dont have usb cable connected in this scenario).
in both cases - combined with the latest commits in master branch - smartpendant works perfectly also.

usb_serial.patch

[terjeio]

Which variant(s) exhibit this issue? And is it a specific version of the ST framework that calls CDC_Control_FS() before the state is configured?
FYI the F412 I have on my bench does not output anything via USB on boot.