Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: WoodChuck15 on July 11, 2021, 09:39:47 AM
-
Hello,
I'm running MACH4 Hobby and program using Aspire. I had machined some parts last weekend with no issues. Then this weekend i go and try and do some machining and i get the following error: X axis commanded over SoftMin. The router will drop down to safe height above the table and turn on but won't move. So i tried one of the programs from last weekend to see if it would work and still same issue. Have did try and reset of Softmin/max in X. Is there something that I need to be looking for?
Thanks
Charlie
-
Have you homed your machine? Your machine needs to know where it is so it can implement soft limits correctly.
Steve
-
Yes, I have homed the machine. I even went into the table to look at what SoftMin and SoftMax where and they are set correct.
Steps I do at start up:
Turn machine on, start Mach 4 on computer, make sure machine coordinates tab is selected, Home machine, then change to working coordinates, do tool touch off, then load Gcode file and start program.
-
Hi,
SoftLimits are a set of numbers that describe your intended machine travel extents relative to the Home position. The mechanical boundaries
will be just a little bit bigger again.
For instance I have my Z axis set up so that the home position is very near the top of the axis stroke. That is to say the home switch is 4mm
lower than the mechanical stop. My limit switch is 2mm lower than the mechanical stop. My Z axis SoftMax is 1mm. That is to say that the Z axis can actually go
1mm higher than the home switch before SoftLimits prevents it from going any higher....hopefully! If it does, for whatever reason, travel beyond 1mm it will hit the limit
switch at 2mm and presumably Estop before it hits the mechanical limit at 4mm.
My axis has 358mm of travel, in machine coordinates from +4mm to -354mm at the bottom before it hits the lower mechanical stop. The SoftMin is set at -350mm, the limit switch
is at -352mm and the mechanical stop is at -354mm.
Note that all these number are machine coordinates, and they are ONLY valid after the machine has homed that axis:
mc=4mm mechanical upper bound
mc=2mm upper limit switch
mc=1mm Z axis SoftMax
mc=0mm home switch
mc=-350mm Z axis SoftMin
mc=-352mm lower limit switch
mc=-354mm mechanical lower bound
When Softlimits are active the machine will travel from +1mm to -350mm for a travel of 351mm. Between the two limit switches (+2mm to -352mm) the
travel is 354mm, and of course the absolute max travel from mechanical stop to mechanical stop (+4mm to -354mm) is 358mm.
Craig
-
I have the same problem on my machine...a Z axis softmin error. My Avid CNC Pro 4x8 machine is homed properly, softmin limits are set properly, I use touch off plate to set the WCS within the limits, gcode toolpaths are all withing the working bounds and I cannot get rid of the Zmin error. I've even opened the softmin limits way past my machine limits and it still gives me the same error...usually on a rapid move that doesn't even change Z height. This feels like a bug and I am not sure how I can work around it. Right now I have a $15k machine that I can't run a g-code program on because of this problem.
-
Ok, I've figured out the problem but Mach4 does not handle the issue in a way that helps understand what is causing the problem (this needs to be fixed somehow in Mach4.) It has nothing to do with homing, setting WCS, or hitting a softmin on an axis (although that is what Mach4 seems to imply.) The issue seems to be with how Mach4 interprets canned drill cycles. I use Cambam as my cam tool and most documentation I've seen says use the "Mach3" post processor for Mach4 output as well...this is fine for anything but canned machine cycles. After reading in several forums about Mach3 and Mach4 gcode interpretation, I saw that this is the biggest difference between the two versions in terms of gcode interpretation.
Mach4 needs G81 line to occur only ONCE before a G80 code occurs. Any subsequent holes before G80 cannot have another G81 code...unfortunately, the Cambam Mach3 post-processor DOES include G81 codes for each subsequent hole and causes Mach4 to either halt on the subsequent G81 operation or kick out a softmin error...which is not helpful at all to debug this problem!!!
So, the way I've gotten this to work on Cambam and Mach4 was to use the "Centroid" post-processor which correctly formats the canned drill cycles for multiple holes in gcode properly for Mach4 to understand. None of the Fanuc post-processors do this correctly for Mach4 interpretation.
Hopefully this helps folks like me who wasted 4-5 days trying to figure out the problem...I could not find this information on the internet in a helpful place!!!
-
Hi,
I have discovered the same problem with G83 cycles when drilling PCBs.
Mach 3 would accept a G83 block but with not all parameters specified. Thus the first line would include the X and Y coords, plus the drill depth,
dwell etc. Thereafter a G83 block might include ONLY the X an Y coordinates, and assume all the other parameters unchanged.
Mach4 adheres rather more strictly to the ANSI Gcode standard, that if a G83 block is encountered then all parameters must be explicitly defined.
Drill cycles are modal however so subsequent lines may just have X and Y coordinates WITHOUT a G83 prepending them, very convenient.
I have written a macro that converts the Gcode from the rather lax Mach3 interpretation to the stricter Mach4 interpretation.
This is the only example, that I am aware of, where Mach3 compliant code will not run on Mach4...Mach4 being somewhat more particular
about Gcode ANSI compliance.
Craig
-
I have run into the same issue today. but I have no G80, G81 or G83 in my g-code.
I can Home, set part zeros, load a file and run it.
If I try to run it again after its over (ie, load a new blank and restart) it gives me the "X axis commanded beyond softmin" error.
if I re-home, I can then run the file.
It does not happen with all files. So there must be another command like the G80 etc, as mentioned in the other posts.
load file A...runs fine time after time
load file B...runs fine the first time, but will not run subsequently without the softlimit error unless re-homed
reload file A...and it wont run without the error unless re-homed.
Now trying to chase this down.
My obvious workaround is re-home after every run cycle, but that shouldn't need to be the case.
Mach: 4.2.0.4612
Mach 4 post: 42473
-
Hi,
I'm not sure that these are the same issue.
In the case of my previous post I described Mach4's adherence to ANSI standard Gcode that requires careful attention to modal cycles like g83.
What you are talking about it that Machs trajectory planner has determined that a planned move would take it beyond the programmed SoftLimit.
If you turned SoftLimits off and ran the code, it would run but according to the warning at some stage of the job it would exceed the boundaries
of your machine.
I would guess that you have g91, that is, incremental moves in your Gcode.
Lets say your SoftLimit x-- is -221mm, say. Now if you had code:
g1 x-255 say,
then you would expect that Mach4 would error out. You have called a move beyond the boundaries....thats what mach is supposed to do.
Lets say however that the machine is in position x=-100, y=0 and you had code :
g91
g1x-150 y0
This code would fail also, because you have made an INCREMENTAL move of -150mm when you were already at -100mm, that is an absolute position of x=-250mm, y=0.
This is an excursion of of bounds and Mach would error rather than crash. My guess is that Mach is not able to detect that error will be encountered until the moment actually
arrives, whereas Mach WOULD determine a fault with an absolute move out of bounds from the very moment the Gcode is loaded, parsed and the toolpath plotted.
Lets say you want to drill a series of five holes 10mm apart, you could do it this way:
g90
g83 x0 y0 z-5 f500 r2 p1
x10 y0
x20 y0
x30 y0
x40 y0
Each hole is drilled at a specific and predetermined ABSOLUTE position. You could also do it this way:
g0 x0 y0
g91
g83 x0 y0 z-5 r2 p1
x10
x10
x10
x10
Where the first hole is drilled at the start position, namely x=0,y=0 and then INCREMENT x+10mm each subsequent hole.
Mach would know immediately if the first code violated SoftLimits whereas it may not know with the second code because that requires tracking of previous history.
Craig
-
Thanx Craig
I am pretty new at this, and do know there is stuff over my head at this time.
I totally understand soft limits, and the concept of ABSOLUTE and INCREMENTAL are also pretty familiar to me.
whats confusing me is that the CODE RUNS FINE WITHOUT ANY ERRORS THE FIRST TIME ITS LOADED AND RUN.
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?
if you care to look, attached is the file that will run fine the first time, but if you cycle start again after it runs successfully, it will not rerun.
I have been dissecting it and manually editing the code to try and understand. hmmm, since it runs fine after I do a "ref all axis" I should probably investigate that code too.
-
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?