Hi,

And you are correct, there are G91's, so that is probably the root of my issues....but...why would it run the first time?

My guess is that at the first pass Mach concludes that there are no moves that would violate the SoftLimits but at a second pass it has accumulated
a 'history' from which position an incremental move would violate SoftLimits.

hmmm, since it runs fine after I do a "ref all axis" I should probably investigate that code too.

No, there is nothing wrong with the RefAll code, it has an effect because it resets Mach ie wiping it previous movement history.
Most CNC Gcode texts  (Peter Smid) recommend NOT to intermix incremental and absolute code....and this is a prime example why that is.

Craig

Hi,
a quick scan through the code shows that g91 ocurrs ONLY at the end of the file:

G28 G91 Z0.
G90
G28 G91 X0. Y0.
G90
M30
A g28 move is the machine moving to its Home location. I think the g91 is misplaced in both occasions that it ocurrs. This code looks like some post processor would generate?
What program are you using to generate it? If its Fusion 360, and I suspect it is on the basis of the Gcode that results then you can reconfigure the post so that it does not happen.

I've just run a Fusion design through the post processor with the 'G28' option  active and it produces this code at the very end of the file:

M9
G28 G91 Z0.
G90
G28 G91 X0. Y0.
G90
M30

I've just re-run the same design through the post processor but with 'Clearance Heights' option active:

G0 Z15.

M9
M30
Note that this code just retracts to z=15mm, the current z axis clearance height, and no BS g91 moves in sight!

Craig

Well...that may be my answer. I've just been using all the defaults for the post processor.
I'm actually using Autodesk Inventor HSM.
But other files from that post processor, which have the same code at the end work just fine (also tried the mach3mill.cps).
In that first file I attached there is something in the "main body" of code (the 2D Adaptive section) that is throwing the monkey wrench into the works. if its not G91, then what? By the way, there is a G91 up at the very top of the file as well. and all the G91's have a G90 immediately after to reset back to absolute.
I took that exact file, and just replaced all the adaptive paths with a simple square...left all the stuff at the beginning and end the same (including those damn G91's) and it works just fine.

I also took that original file I sent, and removed all the G91's...guess what, it still does the same thing and will not run a second time.
I really dont get it, but I may be sneaking up on it.

I dont have a "clearance heights" option in my post proc dialog box (mach4mill.cps), but there is a "G28 safe retracts" option. If I turn that off, I get the same code you had. But I want it to return to my home position though. So looks like I need to now learn how to edit post processors.

I'm starting to get why people badmouth Mach...this isnt the first issue. And other hicups have damaged parts and tools.
But I'll keep at it for awhile still.

Thanx again for trying to help, but I seriously think this is a bug somewhere.

Hi,

Thanx again for trying to help, but I seriously think this is a bug somewhere.

Heard it dozens of times...'must be a bug in Mach4'. I've been using Mach4 for seven plus years...do you suppose if there were such a basic bug I
would not have encountered it? Or the thousands of other users?

It will be interesting what you come up with, keep us posted.

Craig

I've heard the corollary from software developers dozens of times too, in my years doing software validation..."that cant happen, show me".
But software that works fine once, and differently a second time is a bug, you and thousands of other users not withstanding. They say insanity is doing the same thing over and over expecting different results...what is it called when that is actually the case?
And using your train of thought...must mean there will never be another bug fix release ever. software like this is hugely complex and sometimes the smallest thing will set it off, I get that. is the problem in Mach? the post processor? maybe its the interaction between Autodesk and the post...I dont know.

Anyway, I'm done wasting time on this one. I have another workaround that I've added to the workflow to makeup for limitations in the software.

Hi,

And using your train of thought...must mean there will never be another bug fix release ever.

incorrect, there have been dozens....out of thousands reported.

Craig

I've heard the corollary from software developers dozens of times too, in my years doing software validation..."that cant happen, show me".
But software that works fine once, and differently a second time is a bug, you and thousands of other users not withstanding. They say insanity is doing the same thing over and over expecting different results...what is it called when that is actually the case?
And using your train of thought...must mean there will never be another bug fix release ever. software like this is hugely complex and sometimes the smallest thing will set it off, I get that. is the problem in Mach? the post processor? maybe its the interaction between Autodesk and the post...I dont know.

Anyway, I'm done wasting time on this one. I have another workaround that I've added to the workflow to makeup for limitations in the software.

Can you tell me what values you are using for softlimits? Do you have homing offsets setup on any of the axes?