search

grblHAL / core

grblHAL core code and master Wiki
Other
305 stars 74 forks source link

sending M6 causes disconnect #355

Closed tcurdt closed 10 months ago

tcurdt commented 10 months ago

I am running PrintNC_EST_20230129_100223.1 on an pre-EST G2K board.

That's GrblHAL 1.1f, if understand correctly from 20230129 built on the 100223.

This is my config

While it works fine in general, a "T1 M6" will get the board get stuck and disconnect from the computer. It needs a hard reset to come back to life.

I am just sending

G21
G90
T1 M6

and it's dead.

Now while it sure could be because I still need to setup a mode and/or location - it still should not crash. Not sure if this might already be fixed in master - but I didn't find it mentioned yet.

Please let me know if this needs more context or information.

andrewmarles commented 10 months ago

You may want to mention that you are using UGS which does not support the GRBLHAL tool modes. Are you able to reproduce this with IOSender?

tcurdt commented 10 months ago

I will give it a try tomorrow.

But the board should still accept a tcp connection on port 23 in tool mode, right?

terjeio commented 10 months ago

But the board should still accept a tcp connection on port 23 in tool mode, right?

Yes, but the sender might be confused by the TOOL state and give up? ioSender connects and sends a soft reset to clear the tool state.

Tip: set $341=4 to make the controller ignore M6 commands.

tcurdt commented 10 months ago

I redirected the connection through a proxy and also checked the port status. As I hoped - grblHAL is fine :)

$ nc -vz 192.168.5.1 23
192.168.5.1 23 (telnet) open

It's in fact the definition of "connected" of the sender that is sketchy.

The mode changes and while still being connected to the socket it calls the state "disconnected". I expected "disconnected" to really mean "disconnected from the socket". After double checking - that's just not the case.

Sorry for not the noise!