Hello Guest it is April 27, 2024, 12:08:21 PM

Author Topic: SoftMin Error  (Read 2123 times)

0 Members and 1 Guest are viewing this topic.

SoftMin Error
« 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
Re: SoftMin Error
« Reply #1 on: July 11, 2021, 06:19:08 PM »
Have you homed your machine? Your machine needs to know where it is so it can implement soft limits correctly.
Steve
Re: SoftMin Error
« Reply #2 on: July 11, 2021, 08:50:23 PM »
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.
Re: SoftMin Error
« Reply #3 on: July 12, 2021, 09:19:25 PM »
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 enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: SoftMin Error
« Reply #4 on: February 06, 2022, 05:32:26 PM »
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.
Re: SoftMin Error
« Reply #5 on: February 06, 2022, 08:51:59 PM »
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!!!
Re: SoftMin Error
« Reply #6 on: February 06, 2022, 09:14:58 PM »
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 enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline rubes

*
  •  14 14
    • View Profile
Re: SoftMin Error
« Reply #7 on: February 16, 2022, 02:03:50 PM »
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
Re: SoftMin Error
« Reply #8 on: February 16, 2022, 02:33:26 PM »
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
« Last Edit: February 16, 2022, 02:51:50 PM by joeaverage »
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline rubes

*
  •  14 14
    • View Profile
Re: SoftMin Error
« Reply #9 on: February 16, 2022, 04:16:28 PM »
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.