Error during tool change/calibration

[chaotix-]

During a tool change bCNC issues the following commands (when using 'fastprbfeed'): in CNC.py:toolChange() and ProbePage.py:calibrate()

g53 g0 z[toolprobez]
g91 [prbcmd] f%f z[-tooldistance]
g91 [prbcmdreverse] f%f z[tooldistance]

Assuming that z[toolprobez] is very near the maximum machine Z this throws an error (at least with GRBL 1.1) because GRBL thinks that it might end outside the working area (which would be correct if [prbcmdreverse] would not stop until it reaches z[tooldistance]).

I thought replacing g91 with g90 and moving to z[toolprobez] would fix this but it does not as z[toolprobez] is in machine coordinates. Unfortunately G53 does not support G38.x as move commands so there is no way (I can see) to be sure to stay within the working area.

As a compromise I have replaced the last line with: g91 [prbcmdreverse] f%f z2.0

I don't like this solution as it just uses a random constant. That's why I did not create a PR. It should be fine most of the time (I guess) and it's obviously better than z[tooldistance] because it works. :-)

[chaotix-]

Is there a chance that this will get implemented? The current code will throw always throw an error with GRBL 1.1 under the following condition: ztooldistance + "ztouchplate" > zmin

And as this throws an error during the probing function bCNC does not handle it gracefully and a complete Arduino reconnect is required to clear the alarm state.

[chaotix-]

Just noticed a problem with z2.0... If the machine units are set to inches that's a long way to go up...

So I thought to fix this with the new jog commands in GRBL 1.1. Unfortunately bCNC thought 'J' should be followed by a float and replaced "J=" by "J0" which of course did not work.

Here is a complete patch. But as it's only for GRBL 1.1. The only way I see to get it to work with GRBL < 1.1 is to add a user configurable variable to set the "toolprobe pull-off". And even then it would mess up if the user changes G20/G21. Although to be honest all the variables in the method have the same problem. I think even the move to the touchplate would mess up if the units are reversed.

diff --git a/CNC.py b/CNC.py
index 206e8fe..439e8ff 100644
--- a/CNC.py
+++ b/CNC.py
@@ -1630,6 +1630,9 @@ class CNC:
                                continue

                        for cmd in cmds:
+                               if cmd.upper() == 'J=':
+                                       newcmd.append(cmd)
+                                       continue
                                c = cmd[0]
                                try: value = float(cmd[1:])
                                except: value = 0.0
@@ -1684,7 +1687,9 @@ class CNC:
                                currentFeedrate = CNC.vars["fastprbfeed"]
                                while currentFeedrate > CNC.vars["prbfeed"]:
                                        lines.append("g91 [prbcmd] f%f z[-tooldistance]" % currentFeedrate)
-                                       lines.append("g91 [prbcmdreverse] f%f z[tooldistance]" % currentFeedrate)
+                                       #lines.append("g91 [prbcmdreverse] f%f z[tooldistance]" % currentFeedrate)
+                                       lines.append("g4 p1")   # wait a sec because $J needs GRBL to be idle
+                                       lines.append("$J=g91 g21 z1.0 f%f" % currentFeedrate)
                                        currentFeedrate /= 10
                        lines.append("g91 [prbcmd] f[prbfeed] z[-tooldistance]")

@@ -4128,6 +4133,9 @@ class GCode:
                                        continue

                                for cmd in cmds:
+                                       if cmd.upper() == 'J=':
+                                               newcmd.append(cmd)
+                                               continue
                                        c = cmd[0]
                                        try: value = float(cmd[1:])
                                        except: value = 0.0
diff --git a/ProbePage.py b/ProbePage.py
index 66dd796..b02cd00 100644
--- a/ProbePage.py
+++ b/ProbePage.py
@@ -1690,7 +1690,9 @@ class ToolFrame(CNCRibbon.PageFrame):
                        currentFeedrate = CNC.vars["fastprbfeed"]
                        while currentFeedrate > CNC.vars["prbfeed"]:
                                lines.append("g91 [prbcmd] f%f z[-tooldistance]" % currentFeedrate)
-                               lines.append("g91 [prbcmdreverse] f%f z[tooldistance]" % currentFeedrate)
+                               #lines.append("g91 [prbcmdreverse] f%f z[tooldistance]" % currentFeedrate)
+                               lines.append("g4 p1")   # wait a sec because $J needs GRBL to be idle
+                               lines.append("$J=g91 g21 z1.0 f%f" % currentFeedrate)
                                currentFeedrate /= 10
                lines.append("g91 [prbcmd] f[prbfeed] z[-tooldistance]")
                lines.append("g4 p1")   # wait a sec

[vlachoudis]

Thanks.

[Harvie]

Is this still issue?

[chaotix-]

I can't really say as I don't use bCNC anymore. Sorry.

(On a new machine I needed higher step rates than GRBL could provide, so I switched to LinuxCNC.)

[michael-keymont-bose]

I believe it is. I have been getting a bunch of different error conditions while using the Calibrate and Tool Change functions. It's great when it works, but I've never been able to run it 3 times in a row without something going wrong.

Sometimes, whether it is a Calibrate or a Tool Change, the tool will move to the probe position and freeze there, requiring a connection reset. Sometimes it will go to a completely incorrect location and start lowering Z as though to probe. I haven't figured out where that position info is coming from. It's 16 or so inches from the actual probe position...

I'll be playing around with this more and I'd be happy to help troubleshoot. This feature is AMAZING when it works correctly!

[Harvie]

Sometimes, whether it is a Calibrate or a Tool Change, the tool will move to the probe position and freeze there, requiring a connection reset.

I've just merged PR #1139 that sounds kinda related. Can you please check if latest github master version fixed this? Otherwise i would need some ideas how to fix this, it's hard to debug for me...

[michael-keymont-bose]

I’ll give it a go today. FYI, I would believe that this is related to G20/G21. That is, as it turns out, what was causing it to go to the “completely incorrect position” that I mentioned above. Something goes wrong behind the scenes that resets G20 back to G21, and then the probe command is sent and it goes to the “probe position” using relative coordinates, but metric instead of imperial.

FWIW, I’m not a Python guy, but I am somewhat capable with coding (iOS development for work, mainly...), so I think I could get up to speed fairly quickly and possibly be an extra set of hands here. I’d love to be able to give back. I’ll work on getting setup for that - any suggestions for IDE etc? I’m a Mac guy, primarily, but I have access to all 3 platforms... At the very least, I would be better equipped to provide good debug info and minimize the guesswork.

FYI, I’m running bCNC on a Rasp Pi B+, driving GRBL 1.1 running on an Arduino Mega 2560. The machine is a DIY 3 axis CNC Milling machine with a 17”x18”x7” work area, NEMA23 steppers with D542T drivers @36V. I have limit switches on all 3 axis, a probe plate for tool length offsets, Flood and Mist coolant relay outputs, Spindle Speed control etc. It’s a good testbed for debugging since it has nearly every function of GRBL implemented.

Thanks!

[Harvie]

I don't use any IDE. Just my favourite text editor. Since Python is interpreted, there's no need for special setup. Once you have bCNC installed and running, you can edit the .py files and restart bCNC to test the changes. However it's good idea to run latest git version of bCNC, so you are up to date. If you manage to fix the problem in some older version, we can still try to port it to latest git master. But it's easier to run the latest code for development purposes...

[michael-keymont-bose]

Ahhh, I was hung up not understanding how the GUI was done - Tkinter... slowly, I’m learning...

Now that my machine is mostly fully built, I can focus on the software end of it. I’ll do a better job of documenting bugs that I run into etc. I had been using UGS and only recently switched to bCNC, which I find to be wildly superior, but with bugs of its own. I’m really glad to see that this is being actively worked on. I’ll get myself up to speed and try to help however I can. At the least, I can help with documentation and testing etc.

Thanks for the info!

[michael-keymont-bose]

I did some testing, but need to do more as I ran into other, unrelated issues. Before that happened, though, I was able to run 5 or 6 back to back tool changes before I got an error. This beats my previous high mark of 3. Prior to this fix, I could get through 2 full tool changes then it would crash or return an alarm etc.

This time, after the 5 or 6 tool changes, I got a seemingly random, unexplainable soft limit error. I'm not sure that was in any way related to this, but I'm not sure what else might have caused it as all I was doing was tool change after tool change. I'll try to repeat it tomorrow.

[Harvie]

This time, after the 5 or 6 tool changes, I got a seemingly random, unexplainable soft limit error.

What if you disable soft limits? Can you use "spy" feature of bCNC to check if there was some g-code command sent that could caused soft limit error?

[michael-keymont-bose]

I suppose I COULD disable soft limits, but I don't think it was a legitimate Soft Limit error as I was only performing tool changes - not sending any g-code other than whatever is contained within the tool change code. I didn't tell the machine to go anywhere that would have triggered a travel error.

The only thing that I can imagine might have happened was if "zero" was reset to something other than what it was before performing the tool change, and within the tool change code, it directs the machine to go somewhere that it now thinks is out of range. Whether that code is the part that tells the tool to go to the tool change location, or to the probe location or back to where it was prior to the tool change, I'm not sure, but it seemed to get confused in the middle of the tool change operation. Does that make sense?

BTW, I just did a clean install on a fresh Raspberry Pi. I notice several things that are different with this version compared to the install that my actual machine is running on. Notably, the Config; Controller; Fonts; Shortcuts etc menu is now on the CAM tab and it actually seems to do something! I had been unable to get those buttons to do anything and they were located on the File tab.

I'm going to continue to document what I'm doing, including using the Spy feature, which is very cool, btw. I'll repeat the "keep doing tool changes until something goes wrong" test to see if what happened yesterday was a fluke or repeatable. I'll try to 'Spy' the whole thing - thanks for the tip!

[michael-keymont-bose]

OK, progress. I got the machine updated to the latest, not before I took a picture of the screen being different despite reporting the same version number...

This time I ran using the spy feature in another terminal window and watched while the tool change took place. What I noticed is that at the end of the cycle, after the 2nd pause at the tool change location, press resume to go back to work. It sends the tool to the correct work location, but once it gets there, GRBL is resetting. You can see funny characters in the serial stream while it's happening, and then when it's back up, you see the same prompt as when GRBL first boots up.

Fortunately, I have been setting G20 in $N0, so when it came back up, it sent the G20 and I'm back in inches. Prior, without G20 being reset, it would have rebooted and then come up in metric which would have caused any subsequent moves to be incorrect.

The question is, why is it rebooting GRBL when it finally gets back to the work location?

[Harvie]

it sent the G20 and I'm back in inches.

Maybe you have inches enabled in bcnc.ini? Check your config:

[michael-keymont-bose]

I definitely do - I usually work in inches. Sorry... American... all of my instruments are in thousandths... ;) What I'm describing is possibly what was going on a few days ago, when the machine would randomly go to an "odd" location during tool changes. Based on observing that GRBL is, for some reason, rebooting at the end of the tool change operation, my guess is that I previously didn't have $N0=G20 AND it wasn't set in config. So, when this random reboot would occur, my GRBL would go from inches to metric and then to the wrong location.

Should GRBL actually be resetting at the end of the tool change? That doesn't seem right to me. I'll try to redo this test and capture the terminal output to a file.

[Harvie]

Recently i've added code that resets the GRBL after job is finished. I've done this based on some other issue after discussing with GRBL developers. If it's triggered mid-job after toolchange that is a bug.

[michael-keymont-bose]

OK, I was able to get this behavior to repeat, but the good news is that it does repeat and repeat. I haven't had it fail in a while. It DOES appear to be resetting GRBL after the completion of the tool change operation, but since I do have everything setup properly, it recovers in inches and goes back to working as normal.

Attached is the output from the session. I see the 1st Grbl Reset at line 639, and then again at 1368. I'm sure it repeats for each of the 5 or 6 or so times that I performed a tool change. Between each change, I would just jog a little bit and run the spindle, just to have something happening in between tool changes. You can also tell that GRBL is resetting because the UI goes inactive for a few seconds, no buttons are clickable, then it comes back online and is working normally.

You might have fixed this!! I'll try to setup a job with multiple tools and see how it does in a more real world scenario. TEST_SPY2.txt

[Harvie]

You might have fixed this!!

But i didn't changed anything... Did you changed the bCNC settings or version?

[michael-keymont-bose]

I do think that I changed the version, but I'm not sure which version I changed from / to. The version that I had been using, with errors during tool change, had the Config, Controller, Fonts etc menu in a different location, not on the CAM tab like it is now. I've been able to do 6 or 7 tool changes in a row without error since upgrading to the latest version. From my previous post, you can see in the attached text file that GRBL IS resetting after the tool change cycle completes, but it recovers fine.

Unrelated, I also started playing around with Python a little and I changed the bCNC UI to work better with my touch screen. I changed the State and Control frames to no longer collapse, which was driving me nuts. I also made all of the User and Jog buttons bigger to minimize misplaced touches etc. Much better now!