Hi all,
I just switched over to gSender from Carbide Motion on my Shapeoko Pro. Everything about it runs great so far, I’m successfully running my test jobs and getting results.
I’m exporting gcode from VCarve using the Shapeoko Post Processor.
My issue is that ever time I start a job (including rerunning the same job twice), it runs the probe routine for the initial tool (there is a T1 in the gcode near the start). Then it immediately runs the probe routine again because I’m using tool T(not 1), which runs M6 tool-change command, which runs the probe.
Is there a simple step or setting I’m missing?
This is a bit of a pain since I’m still at the stage where most of my work is on < 2minute cuts, since I’m running tests, proof of concepts, etc. With such short jobs, the double probe routine is adding a significant chunk of time to these that I’m trying to run in quick succession.
Do I need to change something in the post-processor? (I haven’t done this before but can do it with the proper links/info). Is there a setting in gSender I’m overlooking?
@Ternary Welcome to the group. I’ve moved your post. You posted in the UGS category and since you are using gSender, I’ve moved it the gSender question category.
I made a hacky attempt here to avoid the double probe by changing the initial T1 to whatever the first tool is that actually gets used in the file (T201 in this case).
This unfortunately does not work.
Further info:
I’m using the Auto Z Plate method using the carbide bitsetter.
The Fusion grbl post processor inserts an M6 command on every tool including the initial tool path. I know there are other grbl posts that have the option to not insert an M6 on the first tool path but I would prefer to stick with the stock one. It would be nice if there was an option under the TLS settings to ignore the first M6 command to reduce the time not cutting in a job. I would rather not have to edit every multi-tool gcode file I generate.
@Kerryh2012, funny you bring this up. As of 1.5.5 we implemented an ignore for this first tool change due to the confusion it was causing others. If you can try it out and let us know if it’s worked out for you, that’d be great
Thanx Chris, I’ve just been removing the first tool change manually. I’d almost forgotten about it. I saw that my other issue with the AZTP with a set bit diameter is on the fix list the other day too. I called it a missing divide by 2 issue, the devs called it a double compensating issue. I found that funny. It looks like this release fixes 3 of my issues, 2 I have brought up on the forums. 1 I privately wondered why I had to probe the initial tool on the first tool change since it was the one I zeroed with. I’m looking forward to giving it a run though.
Yeah it a sense it was both since if you double compensate radius then you get diameter, and if you don’t divide diameter by two to get radius, you get diameter XD
Either way, it was all a part of a specific focus on probing for 1.5.5 so the issue should now also be fixed as of the testing I did with the team over the last couple days. Fingers crossed!
Yes it will cause problems. For ATC application we’ll be working on a better long-term solution alongside all the other work we’re putting in to support ATC systems
This is still an aspect we haven’t fully solved yet for Carbide Create and Fusion 360 except a recent update to highlight when it’s the first cycle through so that you can just ignore it the second time around. We initially made gSender skip the first command entirely, but that created other knock-on issues so we had to revert it unfortunately
