G-code error handling about bcnc

[vlachoudis]

This I could do. The user could dynamically create a database of commands and user customized actions for what grbl complains. ... I leave it for when I will return back home :)

[chamnit]

@vlachoudis : Some ShapeOko users have been commenting on this today and have come up with a similar solution. Some g-codes are inert, like G40, but others are not, like G41/42. They each require special handling. (http://www.shapeoko.com/forum/viewtopic.php?p=47086#p47086)

[vlachoudis]

@chamnit I am bit skeptical on the approach to record actions based on the content of the gcode line. What I mean is that it will be complicated for me to understand which command in an offending line is the one that grbl didn't like. It will strongly depend on the grbl version.

It would be more correct to record the user actions [stop,ignore,feed-hold,wait-user] based on the error code that grbl will return

[chamnit]

@vlachoudis : Perhaps you're right, but then Grbl's errors don't tell you whole story. Grbl will respond upon the first error it detects, not all of them in a block. I'm still in favor of letting the user determine what to do upon encountering an error via a continue-ignore, abort, or re-send with modifications.

I'm also in favor of utilizing Grbl's check-mode to pre-scan for errors and show them to the user before running a job. However, Grbl's check-mode isn't a clean implementation, because it soft-resets Grbl when its done. I'm looking into a way to sandbox the check-mode. Perhaps, this should be standard protocol in the future when I can get around to fixing it.

[vlachoudis]

@chamnit Maybe I was not so clear, bCNC upon and error reported from Grbl it will prompt the user for (continue,ignore,...), and the action will be recorded for similar messages in the future, if the user selects it. However the recording of the action will be based on the error code, grbl returns and not of the offending command inside the line.

Detecting what is the problematic command inside a line, the gui needs to know what grbl accepts and this depends on the version of grbl.

One option could be that grbl to return as well the offending command in the return string.

I am also in favor of a "pre checking" the gcode before sending it

[chamnit]

@vlachoudis : Unfortunately many of the error codes are shared between commands and input words, like when negative values for certain words or when axis words are used by two commands in a line. It'll be equally difficult for Grbl to provide the exact command or set of commands that is causing the error, especially with input words (P,L,R,etc) because they mean different things for different commands.

Another issue is certain error codes may have different implications than others. For example, error code 20 for unsupported g-code command is undefined as to which gcode is not supported. Suppose its an inert command that you want to ignore. The problem is that error code 20 is also used to report the M6 tool change command isn't supported., so you can't ignore this error code indiscriminately.

You also have to resend a "fixed" gcode block, because Grbl has thrown away the block when it responds with an error:.

IMO, there isn't a great silver bullet solution because of how the error codes are defined and how multi-faceted g-codes definitions are. There are an incredible amount of very particular overriding meanings to everything within the canon, which highly depend on previous states. Realistically, it's best to leave that interpretation to the user to decide. But, allow the user to define which ones to ignore or handle specially. For bCNC, you'd likely only need to pre-define only a handful of typical commands to automatically ignore, like M6.

[vlachoudis]

@chamnit I see, it becomes more tricky than what I initially thought. What does the other "gui" do. Silently ignore the errors?

In this case I would be more in favor that I write a gcode-checker and report all these offending commands during loading. So the user has to correct them before starting the run. What do you think?

[chamnit]

@vlachoudis : Yes. Almost all of them just ignore errors by default. Some have an option to halt upon error, I think. Chilipeppr gives you some control when it encounters an M6 tool change.

Writing a full-on g-code checker with a parser would be pretty arduous, but this was the intended function of Grbl's check-mode. This offloads the GUI from maintaining a list of compatible codes. Streaming in Grbl's check-mode is as fast as the baudrate, so pretty fast. There is a bug when it encounters an M0/2/30. Grbl pauses when it shouldn't. That will soon be fixed.

If you do install a checker, I would say that all you'd need to do is scan the document against a list of incompatible codes like M6, which is probably what you mean. I think it would be nice to have the GUI tell you that there may be incompatible g-codes in the program. Although, this might be a lot of work for not much gain..

Realistically, most users will only need to check their programs a few times. Once they figure out their workflow, they can alter their CAM post-processor to automatically remove the offending commands or do it by hand. Having an automated filter in bCNC could be a source of problems later by doing things to a program that a new user isn't expecting.

So, coming back around. I think bCNC only needs better error handling during a program run.

• To bring up a dialog box asking what to do about this error (ignore, halt, or resend).
• Have an automatic ignore or halt upon an error option as a preference.
• Provide an exceptions list, like M6 tool changes, so bCNC can later insert a mini-g-code program to perform a tool change.
• And, make the Grbl check-mode a little more prominent and usable when someone needs to do a program compatibility check. For example, you run a check, and in bCNC's editor, the problem lines are highlighted in red. In practice, you'll likely have to do a few checks of the complete program to uncover multiple errors in one block. Keeping this separate, rather than automated upon load, would lower some of the perceived overhead/lag.

[vlachoudis]

@chamnit Ok, I will go in this direction.

[1bigpig]

I am in favor of telling the user that the g-code is bad and making them re-post process the g-code and starting again. I thought that was the whole idea of the "Check G-Code" function of grbl.

I think a "ignore" or "retrying" option could be a safety hazard. I know that on small machines, wrong/bad g-code commands, at most, is break tools and/or work piece but usually just stall out the stepper motors. This is can be completely different on larger machines. And there is no reason to think that larger machines would not be retrofitted with grbl. I could easily see an old Bridgeport BOSS CNC or a large Mill/Drill type machine being retrofitted with grbl. With a machine this size, bad g-code commands can result in bad things...

Just my opinion.

Bruce

[chamnit]

@1bigpig : I agree with you completely. But, the users of these small machines don't care about the safety hazard involved with ignoring g-codes. For the most part, these are mainly M6 tool change commands. Or, they don't know how to alter their CAM post or their CAM software doesn't have a post processor. With the option to enable or disable it and have the check g-code feature, it should cover all bases.

[HomineLudens]

I found reading this issue really interesting and I like the solution found by your deep analysis. I believe it also cover some special case as custom grbl version with added commands.
I would like to throw my 2 cents, and ask @chamnit if could be possible to have a response from grbl on supported commands allowing some checking of gcode before sending it based on version used.

[vlachoudis]

@chamnit I've started working on that. Now there is a configuration (for the moment only in the .ini) which commands to skip/strip and where to block. The default setup now skips the M6 commands, but in the future I will make a more proper action for it.

[HomineLudens]

After running the first time the
[Error]
M6 = 1
section is deleted from ini file, but M6 is skipped anyway

[vlachoudis]

@effer its a new feature. The program now deletes from the configuration the lines which are the same as the default one. The reason is to have a cleaner ini file and most important if I change something in the default configuration file it will update it to everybody if they have not touch that feature.

[HomineLudens]

I'll will report in wiki asap.

[chamnit]

@vlachoudis : FYI, a new Grbl version has been released just now. There a couple minor ways it will effect bCNC.

• M0 program pause now shows a HOLD state when paused. It used to show IDLE leading users to think Grbl is locked up. You would treat this just a like a feed hold and send a ~ resume character. bCNC needs to be handle this by either the 'Run' or 'Pause' GUI button. As of now, I think it'll require two button pushes of 'Pause' for it to send a ~ character to resume the stream.
• M2/30 doesn't enter a HOLD state anymore. It just sends back a [Pgm End] message and now doesn't automatically soft-reset. This was incorrect. It resets only a few g-code states per the LinuxCNC description of M2/M30. G92 is retained and not lost in this case. A bCNC user should be able to just hit Run again to restart a job.

[vlachoudis]

Thanks @chamnit, once I will be back I will test it on my CNC. So if I understood correctly when I get a HOLD state I should toggle the internal state to match with grbl, and then one click would be sufficient.

[chamnit]

@vlachoudis : Yes sir. That will be sufficient.

[vlachoudis]

@chamnit Now I am correcting the state to reflect grbl status code

[daisyfox]

Hi

We tried bCNC at Xmas but couldn't get it working at all on our RPi, delighted when I discovered how busy you have been and we have it running our eShapeoko this afternoon. A little glitchy but that could be us (we're new too, hubby is the cnc mechanical & electronic, I got dragged in on 'software' because I got leds to blink, once!)

You've inspired me to be brave and offer up some of what I have been trying to do. (but don't expect anything of your level)

Re Checking gCode for errors. Would something based around 'pre-grbl' python code help (sorry I don't know how to add links) I have something you'd probably think very 'pre-school' but you are welcome to it. I used the pre-grbl algorithm and put the 'output' into an array of 'ok/error' codes which are displayed alongside the gcode lines using tkinter treeview. We can visually scan for which lines work and which don't (for the version of grbl it related to - so far it has been ok using 9g).

[vlachoudis]

@daisyfox it could be interesting, especially to highlight all lines/paths in the editor that have g-code errors. However the gcode checking of what grbl accepts should be left on grbl as we discussed above in the thread.

[daisyfox]

no problem, will keep it to myself. Was just thinking something is better than nothing (especially in the short term) also the way we use grbl we don't really want to be transferring files between the computer we use for compiling the gcode and the cnc machine just to find out if there are errors (which are usually generated by cam but unsupported by grbl) then having to go back to the non cnc machine to rewrite the gcode.
----- Original Message -----
From: Vasilis Vlachoudis
To: vlachoudis/bCNC
Cc: daisyfox
Sent: Monday, June 08, 2015 6:13 AM
Subject: Re: [bCNC] G-code error handling (#32)

@daisyfox it could be interesting, especially to highlight all lines/paths in the editor that have g-code errors. However the gcode checking of what grbl accepts should be left on grbl as we discussed above in the thread.

—
Reply to this email directly or view it on GitHub.

[daisyfox]

one last question. But I'll start by reiterating I know that I don't know much about coding so this is a question about feasibility not a 'when will something be done'.

If my understanding of the responses sent by 9g is vaguely correct (I tweaked them to give 4 distinct 'ok' messages so I'd know a 'gcode execution ok' from a 'realtime execution ok') The grbl modules which provide the reporting feedback to report.c are system.c, protocol.c, gcode.c and setting.c.

Q: Is there any potential that these modules could be copied to provide/underpin a python library so the grbl code/modules are re-used (the library could then be refreshed whenever grbl is updated)

Thanks again for all you have done, its amazing and I'm learning lots by reading through the code (bCNC on RPi and grbl on Arduino)

[vlachoudis]

@daisyfox probably my answer was not clear. Your code could be potentially useful to check the gcode for errors inside the bCNC editor and highlight them and I would like to give a look to it. For gcodes that do not represent an "error" (vs the gcode standard) but grbl is not accepting them, we have to leave it to grbl to check.

It is possible to call from python c modules and check the code. I don't know how much work that would involve. Furthermore, it will be linked with a specific version of grbl, probably not the one the user has installed. Lastly it would require to distribute a compiled version of the code for every OS.

@chamnit One idea would be if one of the grbl-simulators was operational with the new version of grbl and let bCNC to connect to the simulator and check the code via the $G.

[daisyfox]

help your self, I uploaded anyway after realising how much I wouldn't be able to reproduce if I had RPi sd failure and/or accidental usb delete.

The stuff mentioned is in PyGrbl-WiP-/PyGrbl_gCodeChecker_Treeview.py (pls forgive the repository name, newbie typo which I can't get to edit as my browser is no longer supported, or some other problem)

Think its best to also warn you, I've also been flitting between python 2.7 & 3.2 on RPi as I played with various libraries trying to get the wiimote to work for jogging the machine.

Thanks for your answer on my question. I hope one day to understand enough to try making Python library. We are firmly stuck with RPi for Grbl (size and cost) so just the one platform for me ;-)

Thanks again and good luck with the rest of your project.

[chamnit]

@vlachoudis @daisyfox : I think we discussed the problem with doing in-bCNC g-code checking earlier in this post. The problem is that various Grbl version support different g-codes and, in v0.9, the g-code parser was completely re-written to be fully compliant to the standard. It behaves a lot differently. Still the best and most robust way to check gcode is to use Grbl's check mode. Although it's an extra step, this keeps versioning independent of what bCNC has to suppeort.

[daisyfox]

Hi again

I've been able to get a gcode-checker working using a tweaked version of bCNC.py. It is simplistic, just keeps two lists (sent blocks and grbl replies) then displays them on a text screen (like 'terminal') as matched pairs.

If grbl ever issues multi-line replies it will fall out of step! It doesn't look as pretty as 'editor' and it does add duplication (sent/recd on both 'terminal'/'checker', though out of sync on 'terminal' of course, also gcode lists on both 'editor'/'checker')

I'll need to make notes so I can reproduce in future versions of bCNC as we need something to allow hubby's son to proof his gcode (he will be using the machine during visits, he lives elsewhere)

I wondered if you might have a use for the notes (added code) too.

[vlachoudis]

@daisyfox I had some ideas on how to implement, but I didn't do anything for the moment. Waiting to finish the function evaluation, that can alter the gcode during runtime.
I have to think a bit on how to integrate in the terminal or even in the editor
, but I could use your notes/code to get ideas.

[daisyfox]

@vlachoudis Hope it is of some help
https://github.com/daisyfox/my_bCNC_dotPY

[vlachoudis]

This one is fixed as well with the new interface. Click on the Machine status to get the error information.