Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The tablet program is stopping in the middle of milling #20

Open
Franckapik opened this issue Jan 16, 2020 · 13 comments
Open

The tablet program is stopping in the middle of milling #20

Franckapik opened this issue Jan 16, 2020 · 13 comments

Comments

@Franckapik
Copy link

Franckapik commented Jan 16, 2020

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
Copy link
Collaborator

MitchBradley commented Jan 16, 2020

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
Copy link
Author

Franckapik commented Jan 16, 2020

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
Copy link
Collaborator

MitchBradley commented Jan 16, 2020

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

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

@Franckapik
Copy link
Author

Franckapik commented Jan 16, 2020

Yes, in the middle. And i use GRBL.

@MitchBradley
Copy link
Collaborator

MitchBradley commented Jan 16, 2020

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

@Franckapik
Copy link
Author

Franckapik commented Jan 21, 2020

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
Copy link
Author

Franckapik commented Jan 21, 2020

IMG_20200118_175209

@MitchBradley
Copy link
Collaborator

MitchBradley commented Jan 23, 2020

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

@MitchBradley
Copy link
Collaborator

MitchBradley commented Jan 23, 2020

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

@Billiam
Copy link

Billiam commented Apr 12, 2020

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
Copy link
Collaborator

MitchBradley commented Apr 12, 2020

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

@MitchBradley
Copy link
Collaborator

MitchBradley commented Apr 13, 2020

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
Copy link

Billiam commented Apr 13, 2020

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

@MitchBradley MitchBradley mentioned this issue Nov 24, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants