Alarm soft X-limit

[bictonmensshed]

MASSO is throwing random soft limit alarms.

The most common is X-limit.

This piece of code was running when it threw an soft x-limit alarm

(2D CONTOUR1)
N15300 M5
N15305 M1
N15310 T9 M6 Successful tool change (Tool change position is X600 Y100 Z0)
N15315 T10
N15320 S20000 M3
N15325 G54
N15330 G0 X120.413 Y37.21 Moved to this position
N15335 G43 Z17. H0 This is interesting - G43 is not listed as supported.
N15340 Z7. This is line of code that the MASSO stopped at.
N15345 G1 Z-6.2 F5000.
N15350 G18 G2 X121.213 Z-7. I0.8 K0.
N15355 G1 X164.2
N15360 G17 G3 X165. Y38.01 I0. J0.8
N15365 G1 Y1057.99 F10000.
N15370 G3 X164.2 Y1058.79 I-0.8 J0. F5000.
N15375 G1 X163.4
N15380 G18 G3 X162.6 Z-6.2 I0. K0.8
N15385 G0 Z7.
N15390 X171.551
N15395 G1 Z-6.2 F5000.
N15400 G3 X170.751 Z-7. I-0.8 K0.
N15405 G1 X127.8
N15410 G17 G3 X127. Y1057.99 I0. J-0.8
N15415 G1 Y88. F10000.
N15420 Y42.
N15425 Y38.011
N15430 G3 X127.8 Y37.211 I0.8 J0. F5000.
N15435 G1 X128.6
N15440 G18 G2 X129.4 Z-6.2 I0. K0.8
N15445 G0 Z17.
N15450 G17

Have attached full gcode file, screen shot and settings file

This code was generated by Fusion using post Version: 42267 updated 8th March.

As stated in this post https://www.masso.com.au/forums/topic/z-axis-drift/?part=2#postid-5079 it is not only occurring when running files but when issuing commands in the MIDI.

Regards,

Arie.

 

[tayloredtech]

Yep....

This happens to me.. Not sure if they're actually going to fix it.

Had to disable soft limits to get a job actually finished

@masso-support

Please can we focus on these bugs over new ventures... The big list is growing and we're struggling

 

[breezy]

@masso-support

Peter,

The attached files were produced by another member of the shed who reported an x soft limit alarm.

I don't know which file produced the alarm other than it was the final cut that produced tabs.

Also after I started this topic I rerun the file with soft limits turned off and the router performed beautifully. No glitches in movement.

I didn't pick up on the trace diving across the screen, so I don't know if was there when the file was loaded or that it appeared after the program started.

Regards.

Arie.

 

[masso-support]

Hi Arie,

The glitch was present on loading of the file but that was the file on your previous posting so I will try the one on this post for my next test next.

I loaded up the config file so have a better idea of the setup. Could i just ask if BictonMensShed and Breezy are the same people? I get the impression that there is a club of some description involved here.

Still getting to grips with your issue at this time.

Cheers

Peter

 

[breezy]

Quote from MASSO Support on March 26, 2019, 11:31 am

Hi Arie,

Could i just ask if BictonMensShed and Breezy are the same people? I get the impression that there is a club of some description involved here.

Still getting to grips with your issue at this time.

Cheers

Peter

Bicton Men's Shed is the owner of the 3DTek Heavy Mill and I'm a member of the shed. My home username is Breezy and BictonMensShed is the shed's username.

The shed purchased the mill on my recommendation and hence I have ended up being the assembler / maintenance person.

The shed is open 3 days a week (Monday, Wednesday & Friday). I usually attend on Mondays.

Here is a bit of history about Men's Sheds. The Bicton shed is a member of Men s Sheds of WA.

Regards,

Arie.

 

[masso-support]

Thanks Arie,

Sounds like a good place. A good way of meeting others and learning new skills.

We don't have anything like that where I live. (Now, back out to my shed)

Cheers

Peter

 

[masso-support]

@breezy

Could you please confirm the software that generated the files. You have probably said but I have missed it.

I am picking Fusion 360 with the Masso Post Processor.

Cheers

Peter

 

[breezy]

Quote from BictonMensShed on March 25, 2019, 4:11 am

This code was generated by Fusion using post Version: 42267 updated 8th March.

Regards,

Arie.

I didn't explicitly state that it was HSM MASSO post.

The radius100x files were also generated by Fusion but using Mach3 post - not sure about that will have to confirm that with the member who created them.

Regards,

Arie.

 

[masso-support]

Hi Arie,

I have been looking at your issue and one thing I notice is your home position is outside of your soft limits so if you home the machine and don't manually jog to inside the allowed area, then as soon as you start to run your file you will get a Soft X or Y limit alarm depending on the first move.

Could I suggest you increase your pull Off Distance and adjust the home positions accordingly to reflect the new position.

It may have nothing to do with the problem but I thought I would mention it especially since you have different people operating the machine and they may not all be aware of this.

Cheers

Peter

 

[breezy]

Peter,

When I first setup the machine, the home position was left front, but due to the cupboard & the dust shoe as can be seen here, it was moved to right rear, I reduced the pull off distance to increase work space real estate, because of the lost space on the left & front of the machine.

I understand that soft limits could be thrown if working from the home position, because I've had soft alarms trying to jog from there using MIDI, but I'm moving to machine X0,Y0 to start my job and I had successfully completed the first part of the job and not thrown a soft alarm. The second part was to run a contour down each side with a downcut bit to clean up the edge. I'm starting at X0,Y0 to get the maximum Y travel.

The thing that intrigues me is the G43 command on line N15335. I have had a look at the Fusion MASSO post processor and in the onSection function there is this portion of code

if (insertToolCall || retracted) {
var lengthOffset = tool.lengthOffset;
if (lengthOffset > 256) {
error(localize("Length offset out of range."));
return;
}

gMotionModal.reset();
writeBlock(gPlaneModal.format(17));

if (!machineConfiguration.isHeadConfiguration()) {
writeBlock(gAbsIncModal.format(90), gMotionModal.format(0), xOutput.format(initialPosition.x), yOutput.format(initialPosition.y) );
writeBlock(gMotionModal.format(0), gFormat.format(43), zOutput.format(initialPosition.z), hFormat.format(lengthOffset));
} else {
writeBlock( gAbsIncModal.format(90), gMotionModal.format(0), gFormat.format(43), xOutput.format(initialPosition.x), yOutput.format(initialPosition.y),
zOutput.format(initialPosition.z), hFormat.format(lengthOffset) );
}
zIsOutput = true;
} else {
writeBlock( gAbsIncModal.format(90), gMotionModal.format(0), xOutput.format(initialPosition.x), yOutput.format(initialPosition.y) );
}

Variable insertToolCall is set on entrance to the function by this portion of code

var insertToolCall = isFirstSection() ||
currentSection.getForceToolChange && currentSection.getForceToolChange() ||
(tool.number != getPreviousSection().getTool().number);

because of the tool change request at line N15310. So the code will always insert a G43 after a tool change, but MASSO documentation doesn't show it as a supported command.

Could this command confuse MASSO and cause it to throw an alarm for the X axis even though the code is commanding it to move on the Z axis?

Regards,

Arie.

PS. I had the sample code nicely formatted but the forum removed the formating.

 

[masso-support]

Hi Arie,

Like you I don't think the homing position being out of the limit area is the cause as such but stranger things have happened. I don't think increasing the pull off distance will reduce your machining area at all, it will just bring your spindle into the working area. You still get the same working area if you set your limits to reflect this. My concern is that you have multiple people using the machine. If someone forgets to move out the spindle into the working area before running their file then reports it to you saying, I got an X limit trip running one of these files then we are both chasing our tail looking for something that doesn't exist. I have been unable to fault the Radius files.

The presence of the G43 is a bit of a worry because you are right that Masso does not support the G43 command and ideally a custom post processor should not throw up unsupported Gcode. I'm personally not up on Fusion post processors so am not much help there but I will query this further and see if this could be a source of the issue.

I also ran a simulation of the CrossVertical file you supplied at the start of this thread using your settings and I get a Z limit alarm every time at line 2972 but from what I could tell Z was not requested to move at the time. This is strange in itself because this is not what you are experiencing. I put all the info together and have submitted it for further inspection to find out if it is a problem or maybe an error with my testing.

I also managed to get my machine moving this weekend with limits and the touch off plate. Since the table is big enough to run your CrossVertical file I thought I would give it a try. It runs perfectly without tripping any limits so I am now scratching my head. I have run it 6 times and each time without issue.

Will keep looking but if you get another file that gives you a limit alarm can you please post it with which limit was tripped and which line it failed on and I will test it.

Cheers

Peter

 

[breezy]

OK, I seemed to have solved the cause of my soft limit alarms, it was G28 commands at the end of the file. I removed them and the g-code ran perfectly. It turned out the G43 code, which was in the line just before the soft alarm was thrown, was a red herring.

@masso-support

Could you explain the line number reported in the F2 screen, when viewing in a text editor (Notepad++) does it include comments & blank lines, or are they stripped out?

Also how many lines do you look ahead?

Because when looking at my g-code that was throwing a soft alarm MASSO reported line number 3079 which is this piece of code N15340 Z7. But if is stripped of comments & blank lines then it is this N15410 G17 G3 X127. Y1057.99 I0. J-0.8. Which is way down the other end of the table. The last seen movement is this N15330 G0 X120.413 Y37.21 which is two lines before the reported line number.

At the end of the file is this batch of code which seemed to be causing the soft alarm,

N15455 G28 G91 Z0.
N15460 G90
N15465 G28 G91 X0. Y0.
N15470 G90
N15475 M30

Now if the soft alarm is thrown by the look ahead then it could be this N15465 G28 G91 X0. Y0. that caused it. Looking at the documentation it is not clear what happens when a G28 is used with X & Y parameters.

I set Fusion to use G28 because I want the gantry and spindle to move clear of the job so the next batch can be loaded without having to issue separate commands in the MIDI. We need to set things up so that anyone can run this as a batching job. 500+ pieces required, 22 pieces at a time.

At the moment I have edited the file to send the spindle to X1000, Y1000, Z0 which works for now.

I ran out of time to do further testing. If anyone can supply ideas how to get Fusion to move the spindle to the home position without throwing a soft alarm it would be greatly appreciated.

Regards,

Arie.

 

[breezy]

Quote from MASSO Support on April 1, 2019, 7:39 am

The presence of the G43 is a bit of a worry because you are right that Masso does not support the G43 command and ideally a custom post processor should not throw up unsupported Gcode. I'm personally not up on Fusion post processors so am not much help there but I will query this further and see if this could be a source of the issue.

Cheers

Peter

The HSM post processors use a variation of C programming language which is quite easy to understand, once you know the rules.

Regards,

Arie.

 

[masso-support]

I think you just solved the case Arie.

I was racking my brain last night why the G28 caused you the problem and then inspiration. I take back what i said about the limit setting not being the cause of the problem but that was before you spotted the G28. You did well to spot that as the line number is no where near it. I work that out by knowing the file is 3105 lines long, (it said so in the screen), then counting backwards. I think the line number being reported in this case is wrong and will need to investigate further.

Your home position is X1103 Y1075 but your travel limit is X1100 Y1070 so as soon as you do a G28 you are asking it to travel to a position outside your limits and so trips the limit alarm.

My understanding is that G28 tells the machine to travel back to the home location. By adding an X Y Z value you tell it to stop off at the specified position on the way. By adding a G91 to the command you change it to incremental so a G91 G28 X0 Y0 tells the machine to add 0 to the X & 0 to the Y coordinate and move to the new location then go home or in other words adding X0 Y0 does nothing. However if you make it use G90 for absolute position then G90 G28 X0 Y0 then the machine will move to Working coordinate X0, Y0 then head home from that point. The idea is to use it to avoid obstacles such as clamps on the way.

I think setting your limits will fix your problem.

Cheers

Peter

 

[breezy]

Have spent some time looking at the HSM MASSO post processor, in particular the onClose() function, this function makes two calls, writeRetract(Z) and writeRetract(X, Y). Now the writeRetract() function looks at properties.useG28; // can be either true or false which is set to true, by default, in the properties window which is in the lower right corner of Fusions post dialog. Next if useG28 is true it sets XYZ values to 0(Zero) otherwise looks at machineConfiguration.hasHomePosition() (for XY) if true, it set XY values to the configuration values else it set them to 0(Zero). Then it writes the output depending on useG28. If it is true then you get this output

N15455 G28 G91 Z0.
N15460 G90
N15465 G28 G91 X0. Y0.
N15470 G90
N15475 M30

if it is false and you have configured a home position then you get

N1380 G53 G0 X1000. Y1000.
N1385 M30

But there is no Z axis retract because with useG28 = false & axis = Z the function returns before it gets to the write output part of the function.

So you need to make sure that you have your clearance level set high in the last CAM operation to guarantee tool clearance on the XY move. As you can see in the drilling code below.

(DRILLING 6MM HOLE)
N1345 G0 X126.5 Y997.
N1350 Z37.
N1355 Z7.
N1360 G83 X126.5 Y997. Z-18. R-3. Q3.5 F485.
N1365 X151.5 Y1022.
N1370 G80
N1375 Z37.

So if you don't want to use G28 Safe retracts you need to set it to No in the Fusion Post dialog properties window.

Also you need to have your soft limits set correctly as Peter and I worked out in this topic.

Regards,

Arie.

 

[breezy]

UPDATE​

@masso-support

Adjusted the travel limits in the X & Y axis settings to a value greater than the homing position setting. Then run the program that was throwing the soft limit alarm without any problems. It went to the homing position at the completion of the program.

So using G28 in Fusion is OK.

Then turned Auto tool zero on and re-homed the machine, it homed ok including measuring the tool length.

Very HAPPY VEGEMITE.

Regards,

Arie.

For the Bicton Men's Shed.