Connection goes to "Not connected" after a few seconds. No error massage or cause of action given

[sa2kaa]

I run bCNC-0.9.14-dev installed using pip on a Raspberry Pi (using latest lite) and a GRBL 1.1f controller currently only powered over USB. The setup is run from remote on a LAN using ssh -X to the machine and I start bCNC from the command line. bCNC starts and it is possible to connect to the GRBL controller and manually jog the position using the buttons. Then after some seconds the connection state goes to "Not connected". The command window from which python program was started does not indicate that there was any error. The Jog and Idle state transitions was shown. In the bCNC "File" tab view the USB connector icon remains green with the close text shown. Toggling this button will restore the connection state to "Idle" and green.

[Harvie]

Can you please run dmesg -w on the raspberry during the operation to see if there are any messages when this happens?

[sa2kaa]

I used dmesg to see if there was any problems with the usb kernel subsystem but there was none. Then after reboot this behavior ceased. I assume that possibly unattended upgrades completed the more processing time for the python program became available. My guess is that this i timing dependent and not related to USB instabilities.

There is also a timeout setting that affected communication i bCNC that might have fixed the problem on a slow machine. Had the problems sustained or reapperard I would have tested extending it.

The observation still is that there was not error message about the cause genereated when the state whet from connected to not connected. I also was obvious that the USB connection was not really dropped but that the state did connect state did not recover. Possibly this behavior can be replicated by setting the timeout very low since it not current replicatable on my original setup with standard settings. I guess there could be more timeout settings that a less obvious from the code. Like such hidden in default settings in pyserial or whatever is used.

[Harvie]

Did you installed GRBL from http://github.com/gnea/grbl yourself? People often have issues with weird GRBL forks from unknown source. (eg. came preloaded by vendor on the board).

[sa2kaa]

I don't see any casualty between the lack of proper error messages in bCNC and the improper fault handling when some fault occurs i bCNC and the origin of the source code for the GRBL motion controller.

Why is this question relevant?

[Harvie]

Because we only suport GRBL and grblHAL. We do not support random stuff from unknown source which might or might not be loosely based on GRBL.

[sa2kaa]

Even with that intention you need to handle fail modes cased by the platform on which bCNC executes. I have not claimed that the delay (assuming a delay was the root cause) was cased by the motion controller. Although nor can I exclude that possibility. But considering Raspbian is not a real time operating system it is more likely that the delay is caused on the bCNC host side. You are aware of the possibility that your program might not always execute at the same rate when running under a preemptive OS?

[Harvie]

aware of the possibility that your program might not always execute at the same rate when running under a preemptive OS?

bCNC is not a motion controller, so it does not matter it is not running in realtime mode. GRBL handles all the realtime stuff.

[luckypickle1]

I had exactly the same problem this week! I also have the candle software working on a RPI 5 and it didn't work, I replaced the Arduino IC and it started working but after about 3 hours it stopped working again... so frustrating. I had a similar problem on an rpi 4 but it was a synchronization glitch between the terminal and the config file which were not in sync.

[luckypickle1]

Make sure you use optocouplers in your system specially if you have limit switch

[vadimyar]

SOLUTION (possibly...)