Should GRBL GUI restore TLO after reset?

[Harvie]

In bCNC we have this PR here: vlachoudis/bCNC#1140

User is complaining that TLO is reset when GRBL is reset and wants us to save the TLO in GUI and restore it every time... How comes that WCS is stored in GRBL, but TLO not? Note that we reset GRBL after every successful g-code file stream (as reccomended by @chamnit in #564). So after each cuting job the TLO gets reset.

Is that good idea to restore the TLO every time by UI? May it cause some troubles? I don't use it myself, i use only WCS, so i don't know. I just want to know what are the reccomended practices...

[carneeki]

Issue #590 has a little discussion about this, but I see your point about TLO and WCS being treated differently. grbl/grbl#590 (comment) I have a guess as to why TLO and WCS are treated separately: that most users probably load their tools into collets, and need to touch off each time, so a tool table with tool lengths stored does not make sense given how limited the memory is. Hence, leave it to the GUI which has more memory and can be as flexible as the user desires. However, this is just a guess.

…

On Thu, 14 Mar 2019 at 05:36, Tomas Mudrunka ***@***.***> wrote: In bCNC we have this PR here: vlachoudis/bCNC#1140 <vlachoudis/bCNC#1140> User is complaining that TLO is reset when GRBL is reset and wants us to save the TLO in GUI and restore it every time... How comes that WCS is stored in GRBL, but TLO not? Note that we reset GRBL after every successful g-code file stream. Is that good idea to restore the TLO every time by UI? I don't use it myself, i use only WCS, so i don't know. I just want to know what are the reccomended practices... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#623>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdYqFYjAfvS8BXCt7n9ncfpzFbmkm6Dks5vWUVDgaJpZM4bvVYg> .

-- Adam "carneeki" Carmichael p: +61 415 37 1990 w: http://bigneek.com e: carneeki@carneeki.net i: 2207644

[Harvie]

update: beside of TLO and WCS there's even guy using G92 to handle the toolchange...

[dshaded]

Tool table really looks like an overkill here. But persisting TLO (and probably G92 offsets) into eeprom would take just a couple of bytes. And this should be really simple and stable at grbl level while being a bit fragile at sender level.
Probably I'm missing some use cases when user expects TLO reset on every controller reboot? Because in my scenarios controller reboots almost never happen at the time of tool change.

[109JB]

Soft resets are commonly used for stopping motion and IMO should not change TLO.

For example, during a program run, the only current way to immediately stop program execution and cancel a run of a g-code file is to perform a feed-hold, wait for the machine to stop, and then perform a soft reset to clear the buffer of all the commands that follow the feed hold. The TLO should not be reset in this case. No commercial controller I know of ever resets TLO for anything except a complete shutdown of the machine. So, a hard reset it would probably be OK to have TLO reset, but for a soft reset it shouldn't. This is my opinion

[Harvie]

Soft resets are commonly used for stopping motion and IMO should not change TLO.

That makes sense.

And this should be really simple and stable at grbl level while being a bit fragile at sender level.

Yes. That's exactly why i didn't merged the patch to bCNC.
But i guess we still have to wait for Sonny's opinion...

Tool table really looks like an overkill here.

Yes. I don't think GRBL should store tool table. If we need tool table, we should handle it in GUI.

[chamnit]

Grbl on 328 does not have the room to deal with TLO (interface primarily). Dynamic TLO was introduced into Grbl to allow GUIs to simulate true TLO and tool libraries. It was never an idea solution but it was the best I could do with the limited resources.

Ultimately it is up to the GUI if they want to support multiple tools and their offsets. Upon reset or any power cycle, I would have whatever TLO active to whichever tool number is active. If the tool number is reset at a power cycle, then it’s the users responsibility to remember to change the tool number but that is usually in the gcode.

[109JB]

@chamnit I don't think anyone is talking about Grbl supporting multiple tools but just about Grbl retaining the one tool length offset value. I myself am only talking about retaining that one value only. In my opinion this could easily be a safety issue. For example, if the TLO is positive and a reset is performed the TLO will be reset to 0. Then if the user were to start a g-code run the tool would now crash into the part because the TLO got reset. Since the soft reset is the only way to cancel a held command and to flush the planner buffer it is also the only way to stop a running program. Commercial machines don't reset TLO simply for a program stop, nor does LinuxCNC, but since Grbl has no other option that I am aware of it does reset the TLO.

[Harvie]

In my opinion this could easily be a safety issue.

Exactly. What is the point of storing WCS, when you loose TLO anyway?

Commercial machines don't reset TLO simply for a program stop

I guess this is the result of GRBL protocol minimalism. Tries to do lots of stuff with minimal number of features. Suddenly there is no difference between stop and reset. I think it's generaly a good thing, but we need to figure out all use cases and create some guidelines on implementing them.

[chamnit]

Dynamic TLO, by definition, is zeroed upon reset. Yes, it can be problematic but it is clearly defined. Again, it was the best I could do given the constraints and other higher priorities, like true real-time overrides.

Honestly, I view Grbl on 328 as complete. There is nothing else I can cram into it without negatively effecting something else. On ARM, that is a completely different story. I don’t see any issue with supporting tools and proper TLOs on that.

[Harvie]

BTW Is there easy way to find which parameters are persistent across GRBL reboot/reset and which are just in RAM?

Also how often are these written? I've noticed that when i unplug USB powered GRBL it sometimes does loose its position. Why is that? are WCOs stored after delay to prevent wearing out arduino by overwriting the flash too much?

 [G54:0.000,0.000,0.000]
 [G55:0.000,0.000,0.000]
 [G56:0.000,0.000,0.000]
 [G57:0.000,0.000,0.000]
 [G58:0.000,0.000,0.000]
 [G59:0.000,0.000,0.000]
 [G28:0.000,0.000,0.000]
 [G30:0.000,0.000,0.000]
 [G92:0.000,0.000,0.000]
 [TLO:0.000]
 [PRB:0.000,0.000,0.000:0]

[109JB]

Dynamic TLO, by definition, is zeroed upon reset.

I have to strongly disagree with the above statement. While in Grbl a reset zeroes TLO, I would argue that since the soft-reset MUST be used for normal operations in Grbl GUI's, you cannot compare it to the reset of any other controller.

For example, in order to stop a running g-code program using grbl you MUST use the soft-reset command to clear the buffers and to cancel a motion command that is in hold. In other controllers, commercial and non-commercial, stopping a running program doesn't require resetting the entire control system. Therefore comparing a reset of another controller to a soft-reset in Grbl is not an apples to apples comparison.

I can guarantee you that the commercial controllers I used as well as linuxCNC do not reset TLO if you simply invoke a program stop. The fact that Grbl has to be reset to clear the buffers is where the difference lies.

If there was a command that would cancel the current motion and clear all the buffers without doing anything else, then this would be the ideal thing. Then the GUI developer could decide what if anything needs to be reset. This is a feature that has long been asked for and one that I feel is necessary. I understand that in the 328p it may not be feasible, but in the ARM version this is definitely what I would consider a needed feature.

[Harvie]

you cannot compare it to the reset of any other controller.

In fact in #592 @chamnit even suggested that you need to do soft-reset if you want to implement "jog during feed hold" feature...

[dshaded]

@chamnit, can you take a look at my pull request? It adds what we want here and reduces flash consumption. The price is extra 8 bytes of RAM and some EEPROM.
I haven't tested it on hardware yet. There may be some bugs. But it is enough to demonstrate what we'd like to get here.