The tablet program is stopping in the middle of milling

[Franckapik]

When i use the tablet program instead of cncjs regular interface, the reading of grbl code seem's to stop (randomly?) . I try differents gcode files. I use rpi 4. Somebody have the same problem ? Thank you !

[MitchBradley]

There have been reports of problems with very large GCode files, larger than 4 MB. How large are your files?

When you say stop, do you mean that part of the file will be read but the rest is not there, or do you mean that when you select a file it will not load at all?

[Franckapik]

My files are less than 100 Ko. I read the 4 MB file problem but in my case this is strange. I see the entire file in the viewer. And it make a kind of a pause on a line, and not going to the next one. I am sorry to not be more precised, but may be i can make some screenshots later ...

Thank you for your answer ! F.

[MitchBradley]

Do you mean that the execution of the file is stopping in the middle?

What controller are you using? GRBL? g2core? tinyg? Marlin?

[Franckapik]

Yes, in the middle. And i use GRBL.

[MitchBradley]

With a given program, does it always stop in the same place? Or does a given program work sometimes and fail sometimes?

[Franckapik]

I don't know if it could help but i tried again yesterday and as always the machine stop the milling on this line in the grbl file (see next picture)

[Franckapik]

[MitchBradley]

Do you have limits enabled? It's possible that one of the moves is exceeding a limit value, causing the controller to stop.

[MitchBradley]

Another possibility - when you turn on the spindle, maybe it is causing electrical noise that falsely trips a limit switch.

[Billiam]

I'm having this issue and I can replicate it reliably, so here is a bunch of detail:

• It only occurs when using the the shopfloor-tablet interface.
• When it happens, I see debug controller:Grbl Stop sending G-code: hold=true, sent=51, received=51 with verbose logging enabled. (sent/received numbers will vary, but always match in my logs).
• It occurs reliably with small gcode files (the one I've been testing with is only 3kb, maybe 10 minutes of job time).
• It occurs with the stepper motors disabled, and the spindle off.
• If I initiate a job via shopfloor tablet on my phone, and turn the phone off immediately, the job will end up halting a minute or so later.
• If I initiate a job and the phone goes to sleep, the job will end up halting a minute or so after the device goes to sleep.
• If I initiate a job, and leave the shopfloor interface open, and force the device to stay awake for the whole job, the job will complete successfully.
• If I initiate a job and immediately close the shopfloor interface tab (and there are no other open shopfloor tabs on other devices), the job is able to complete successfully

CNCjs: 1.9.22 Node.js: 10.19.0 NPM: 6.14.4 GRBL Raspberry Pi 3B+

@MitchBradley Per your comment, since it seems to be related to device sleeping/inactivity, I'm not sure how to replicate it the same way on a PC (so that I can keep an eye on the JS console). I'll keep trying though.

[edit] With the shopfloor interface open on a PC, and phone, if I initiate the job as above from the phone, and turn it off (or it goes to sleep), the job will end up halting. When it does, it does not generate any console logs in the desktop chrome instance.

My app.js did not have the mentioned console.log. After adding it, I see this in the desktop instance, after the phone has started the job and gone to sleep with the tablet interface open.

G3 X860.9 Y-0.315 I0 J6.972 (line=22)
app.js:273 error:8 (Not idle)

Tried a few times, and the line it fails on will change depending on when the error occurs, but that error is followed by the Stop sending G-code line in the server logs.

[MitchBradley]

Okay that's a good clue. I'll look into it.

[MitchBradley]

Looking at the GRBL source, error 8 means that there was an attempt to execute a non-GCode command that won't work when a GCode job is going on. Such commands include $ to read setting, H for homings, and commands that alter settings. The most likely thing, I believe, is that the shopfloor-tablet UI is getting restarted and then issuing a $ to get the settings. Here is something to try:

In app.js, comment out line 103: // controller.writeln('$$'); and change line 306 to: var grblReportingUnits = 0; // Initially millimeters The line numbers might be a little different due to debugging code that you may have added.

[Billiam]

With those changes, I wasn't able to make it halt over a couple of runs. 👍