Increase timeout parameter for serial port

[kkugelblitz]

Currently at opening the port, the timeout for the serial interface is set to 0.1s (sender.py). This value seems to be on the borderline when using serial over ethernet (additonal latency), but also with slow hardware and local connection.

Under these conditions, I randomly experienced situations where bcnc crashed when parsing the serial feedback from gbrl. What happens is that the serial.readline() call (which should be blocking until a complete Line with EOL is received) returns before getting the EOL because it runs into the timeout. bcnc does not check for the timeout event and crashes when trying to parse the incomplete line fragment.

Increasing the value to 0.5 solved the issue for me (value chosen randomly). With my limited knowledge of the overall code, there seems to be no negative impact of increasing the value, as normally continous serial feedback should be expected. Do you see any problem in changing it?

[vlachoudis]

I've increased the value to 0.5, but I am bit puzzled, since your problem was not happening during a timeout of the reply but during the readline, that it is supposed to operate once a line is send completed.

[kkugelblitz]

Back then, I had a look into the implementation of pyserial's readline function, and if I got this right, it implements the timeout internally. This means there are two cases in which a call to readline returns:

1. EOL received (the nice case which returns a complete line)
2. no EOL received, but no new character received within the timeout intervall; in this case, the function typically returns an incomplete "line" which causes bcnc's parser to crash.

Anyways with the increased timeout it works fine.

[ghost]

This change did have an impact on my setup. Jogging is erratic on my RPi 2 when SERIAL_TIMEOUT is 0.5s. When SERIAL_TIMEOUT is 0.1s then jogging is smooth ie hold down the arrow key and the axis platform moves smoothly until the key is let go. When SERIAL_TIMEOUT is 0.5s then jogging is erratic : the axis moves in spurts while the jog key is held down.

I've changed the timeout back to 0.1s for me since that setting works well for my setup. Just posting the info in case others have this issue.

[vlachoudis]

Its correct what @jeffmd found out, so I am forced to restore the timeout back to the original value of 0.1s. The problem I see is that if the serial has something available the routine goes in the waiting state to read a line. I have to find a more robust solution by reading everything as it comes and then check for a newline inside the read buffer.

[aop1971]

i had exactly this problem, while using a home-made cnc based on Arduino UNO, cnc shield, running grblv1.1. After started to sent the gcode to the machine, it only took a while (10 seconds?) for the process to crash, leaving the machine frozen in a random position. In the very beginning, I suspected about bCNC (it was supposed to be the machine controller), but noted that this situation not only was produced while using it. I tried with UGCS, and the results were similar (milling process crashed after a while). Then, checked the software backwards in the process (flatcam, Orcad, EasyEda) ... with no sucess at all. Friends, in my case, the problem originated at the induction caused of my milling tool (a common mototool) over the cnc hardware (of course, it involves the communication process). Just make this test: while keeping turned off the tool, "start" the milling process a couple millimeters above the piece (in other words, allow only for the xyz positioner to work, not the tool). For sure, it will complete the whole process with no errors My solution was to to run the ac power away from the cnc hardware&cabling system So, for the creator of the software, my applauses to you, and dont crack your mind finding this problem in the software

[MARIOBASZ]

I think this is already written. I also suffer from electrical noise problems. Precautions that have not served: Faraday cage to Arduino / metal barrier. USB cables not too long Shielded cables as much as possible everywhere. Arduino far from where the noise comes (influences inversely proportional to the square of the distance) In my case I have disconnected the hard limit switches, I use soft to perform homing / care not to exceed machine limits

[colinluthier]

On my machine I set the limit switches to normally closed and put a choke on the uab cable and I am pretty sure I am not crashing because of noise.

On Sat, Oct 26, 2019 at 3:13 PM Mario Basz notifications@github.com wrote:

I think this is already written. I also suffer from electrical noise problems. Precautions that have not served: Faraday cage to Arduino / metal barrier. USB cables not too long Shielded cables as much as possible everywhere. Arduino far from where the noise comes (influences inversely proportional to the square of the distance) In my case I have disconnected the hard limit switches, I use soft to perform homing / care not to exceed machine limits

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vlachoudis/bCNC/issues/594?email_source=notifications&email_token=AH3WJEBZSIYNZ23ZRC6OXHLQQS6KHA5CNFSM4DMBZKBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKR64Y#issuecomment-546643827, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3WJEBSETOHQTJIWC7EEZLQQS6KHANCNFSM4DMBZKBA .

[MARIOBASZ]

If the problem appears when you turn on the spindle, do not rule out electrical noise. I am not an engineer or a doctor, I have suffered that problem, I only share my little experience.