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.

[dshaded]

And if increased RAM usage is unacceptable or if you think that those offsets shouldn't be kept during power-offs here is another option. Just do not clear those variables at soft-reset. It should help in 99% of use-cases.
Actually I'd prefer to keep those offsets even during hard resets (in noinit section) but arduino bootloaders make it really hard to distinguish between powerup, brown-out and external reset sources.

[zeevy]

I think for 328 its better to handle this in GUI
Just keep a track of last TLO and leave it up to end user.
If user is restarting the program after a soft reset, its up to him to apply the TLO or not.
What GUI can do is prompt/alert the user if TLO is applied on last job and is not cleared.

[dshaded]

It's just a matter of adding a few dozens of code lines to every existing grbl frontend vs changing one constant in grbl code. It is much easier to keep a fork of grbl with this one-line patch and tell people to use it if they want adequate TLO or G92.

[chamnit]

@109JB : Finally got around to digging into this. Looks like I was incorrect on both fronts for G92 and G43.1.

LinuxCNC doesn't reset G43.1 upon a program stop or soft-reset, but it does clear upon restarting the application (at least as far as the live CD build I have behaves). What's weird is how this behavior is undefined in the LinuxCNC documentation. All it says is that G43.1 is not recorded in the tool table. It also doesn't state behavior upon M2/30 program end.

Also looking at G92, both NIST and LinuxCNC documentation states that it's recorded in parameters, but has changed in definition over time. NIST and older LinuxCNC versions apply G92.2 upon M2/M30 program end. The current LinuxCNC doesn't. G92 remains active.

Not sure where I got the impression that both G92 and G43.1 always clear after a soft-reset and M2/30 program stop, but it's probably from the machinist I often consult with. He has a very strong opinion that both G92 and G43.1 are magnets for accidents, as he's personally seen G92 destroy CNC machines several times, even by seasoned machinists. You can easily misuse them and forget if they are active or not. He's always told me to discourage the use of temporary offsets, even deleting G92 from Grbl.

Because of this, I am tending to keep it the same and just noting this difference on the wiki. There is also the addition consideration that changing both G92 and G43.1's behaviors could cause more issues with users and vendors used to how it behaves now.

That said, I can offer adding/merging a compile-time option for fixing G92 and G43.1 behaviors to be compatible with LinuxCNC. For this, G43.1 would remain active throughout until a power cycle (although I disagree with this behavior for the reasons above). G92 would need to updated to include G92.2 and G92.3 and save in EEPROM. Would this be a reasonable compromise?

[dshaded]

Been using grbl with patch #634 since april. It does the job - no more broken tools and unexpected movements. Loosing tool length after hard reset or power down is well expected as these events indicate either a start of daily work or some kind of hard failure.