Hi Forum,
In my simulation I have no errors on this file. However, when I try it on my onefinity I get a soft alarm on line 1571. It all stops. SO my question, what is the cause of this alarm? I use Fusion 360 and a Onefinity foreman with PWNCNC 2.2kWh spindle.
cutout v4.f3d (190.6 KB)
Is it the original or Elite CNC you have?
Also, which toolpath is giving the error? Could you please provide a screenshot of the gcode around line 1571.
Can you also share a copy of your printable settings file. See below link…
https://docs.masso.com.au/wiring-and-setup/save-and-load-settings
And you are in G54, the same (Fusion “1”) WCS chosen in your setup correct?
MASSO Settings v5.07 (G3-18630).txt (13.7 KB)
Yes, if you mean WCS Offset = 1
Did you happen to note what your MCS was when the soft limit was triggered?
Nope I’m sorry. Did not note it, but the setup is still on the exact same place as I left it
Homed the machine with homing button and then set the WCS on the workpiece
Can you start the controller without homing, and look at the X and Y MCS DRO?
Am curious what it reads…
After homing the WCS and MCS DROs for all axes should read zero (0).
Are you placing your stock at the very front, close to MCS Y=0?
If so is it possible your toolpath is entering off the stock (Y=-2.1867), and this is out of the MCS Y limit?
Stock is placed in the middle (on x-axe) plenty of room.
I did the first toolpath which had no issues.
I think if what you say in your last line, then the cutout would be compromised?
Anyway, if there is softlimit error I would expect it to be on the y-axe
You can see my workpiece in the picture
These grooves are the first toolpath which went okay
I understand what you are saying, but it is odd that the MCS Y DRO reading when the machine stops is only 2 mm (~.08") from Y=0.
Were you able to get more support to figure out what was causing the alarm?
Morning,
I redesigned the cut-out to the four lowest cuts. This gave my no alarm on the x-axes. The cut went fine.
Ill try another one this week and see if there is any alarm. If so a will report back, otherwise I will close the ticket.
Possibly I will do some research about the homing issue were all axes should be 0 and which in my case is not.
The MCS DRO should have all axes read zero after homing. I would make sure of this.
The WCS DRO may read other values depending on whether you zeroed out a workpiece first and then homed after that. When you first home after the machine/controller has been turned off, both DROs would read zero for all axes.
Thanx for the answer,
I always home first and then place the work piece. After this I zero out on the work piece.
Need to check if homing is again not set to zero after I try it today. Let you know. But if not, I need to figure out how that is possible and need to work on a solution so that homing give 0 on all axes
I doubt this will help but add it in anyway. The other day I went to make a simple cut and after loading the file, the position of the spindle was near the X-Y zero points and the screen representation of spindle location showed the + indicator to be in the middle of the cut. Couldn’t figure it out and after a bit, just went for it. After the initial tool change, the spindle quickly overran the X hard limit and stopped.
After returning to my workstation to FAFO and preparing another post, I realized that while I had the correct MASSO post processor selected in Fusion as default, I had NOT selected the proper “Autodesk Generic” machine. As soon as the correct machine was selected with the MASSO post processor, the resulting generation ran with an arbitrary zero X-Y set via the touch probe.
EDIT: Looks like Allen and I were typing at the same time. I believe what I am describing here fits his fourth point about “origin”. Now that I think about it more, the MASSO displayed units at the bottom of the graphical cut plan on the screen and the zero was in the middle of the plan. Setting the correct machine fixed that (and probably other things).
Hi.
Pardon me for jumping in here. I know your level of frustration with these “soft alarm errors”, but I have found that Soft Errors are most always related to the same issue, and I need to remind myself how simple the fix is, as I panic each time I get one.
From your code snippet I can see that even if you “adjust” things to get past line 1571 the error will return on line 1572.
How do I know that? Because if you look at the previous lines of code you will see the X axis values are gradually increasing until the OneFinity can no longer reach the specified X location.
Line 1564 specifies X 0.742 and on line 1571 X 2.699 and on line 1579 X5.735.
So your OneFinity stopped on line 1571 because the increasing X value of 2.699 could not be reached.
As I said earlier “soft alarms” are almost always caused by your machine can’t reach the destination specified in the gcode file.
So what to do about it?
Here are a few things to try.
