ALARM:2 Soft limit alarm Help

Software / Firmware Jackpot Board / FluidNC
1

Apologies for the format below but I keep running into an issue with a simple drawing gcode that is triggering the machine soft limit (Soft limit on X target:-1625.076). I’ve manually reviewed the gcode in the section where it stops but all moves are well within limits. Any ideas on how to troubleshoot this? I’ve tried 3 times and it throws the error at the same spot every tiime.

[MSG:INFO: Soft limit on X target:-1625.076] <Run|MPos:246.180,198.840,-17.230|FS:557,0|Ov:100,100,100|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:246.180,198.840,-17.500|FS:1260,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:246.200,199.300,-17.500|FS:777,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:246.440,200.360,-17.500|FS:1261,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:247.020,200.460,-17.500|FS:1800,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:248.060,199.460,-17.500|FS:1800,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:249.200,198.020,-17.500|FS:1800,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:250.300,196.580,-17.500|FS:790,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:251.360,195.180,-17.500|FS:300,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:251.980,194.380,-17.500|FS:1020,0|WCO:103.000,103.000,-17.000|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,194.360,-17.500|FS:1740,0|Ov:100,100,100|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,195.160,-17.500|FS:1800,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,196.640,-17.500|FS:1164,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,198.480,-17.500|FS:444,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,199.880,-17.500|FS:517,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.080,200.540,-17.500|FS:919,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:252.500,200.580,-17.500|FS:157,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.380,200.580,-17.500|FS:877,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.660,200.480,-17.500|FS:1717,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.660,199.720,-17.500|FS:1306,0|WCO:103.000,103.000,-17.000|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.660,198.180,-17.500|FS:657,0|Ov:100,100,100|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.660,196.640,-17.500|FS:174,0|SD:35.57,/sd/LifeSpring Logo.gcode> <Run|MPos:253.660,195.860,-17.500|FS:0,0|SD:35.57,/sd/LifeSpring Logo.gcode> [MSG:INFO: ALARM: Soft Limit] ALARM:2 Soft limit alarm. G-code motion target exceeds machine travel. Machine position retained. Alarm may be safely unlocked, click the Reset Button. <Idle|MPos:253.660,195.740,-17.500|FS:0,0|SD:35.70,/sd/LifeSpring Logo.gcode> [GC:G2 G54 G17 G21 G90 G94 M5 M9 T0 F1800 S24000] [MSG:ERR: Reset to continue] <Alarm|MPos:253.660,195.740,-17.500|FS:0,0|SD:36.99,/sd/LifeSpring Logo.gcode> [MSG:INFO: WebUI: Request from 192.168.0.2]

2

Which axes do you have soft limits enabled on? Which axes is the machine moving in when it triggers the alarm? Where is the machine head located on your table when it triggers? Is it possible it’s triggering in Z, as opposed to in the XY plane?

Enabling soft limits involves not just turning them on, but also making sure that you correctly specify the travel limits of your machine. Then that forms a build volume area. If you execute G code that tries to travel outside those bounds that triggers the alarm.

3

Have you ran the verified test crown code?

4

I had soft limits set on X and Y (not Z) and thought I also ran the gcode with them turned off but apparently not. Worked fine with the soft limits turned off.

I would like them on though because I think it’s a nice touch not having to worry about jogging the machine too far. Do they normally cause problems?

I have and it ran fine with the soft limits enabled

5

For each axis, there is a parameter that is the max travel distance in millimeters. That should be accurately set for soft limits to work. If you enable soft limits, but you didn’t verify what that max travel distance was for each axis then you may have inadvertently set your soft limits to be triggered at the wrong place.

6

Why? Nothing happens if you job too far. You can see adding that means you now have more things to worry about including what workspace you are operating in.

I suggest going back to default and turning them off. If you are making something big and worried you are too close you need to 100% do an air pass, not rely on the soft limits. One takes a few minutes, the other wastes material.

7

Yep, I ran each axis to it’s max and noted the measurement and put those in the max travel distance for both the X (660mm or 26") and the Y (1270mm or 50").

8

I cant imagine the core running into the 3D printed side plates is great for the machine in the long run.

Plus I’m just trying to understand what’s going on, seems odd that the error mentioned a --1625.076 X move. The soft limits are a neat idea and worth exploring what is causing the bug rather than just turning them off in my opinion, but maybe I’m the minority

9

I designed the machine to handle that. That is exactly why I built it the way I did and not with nema 23’s and ball screws. Absolutely nothing happens if you hit a max.

You need to understand workspaces. It sounds like you reset your zero and overran your soft limits.

2 Likes
10

The soft limits are respected with regard to the “machine coordinates” as opposed to “work origin” coordinates. Is there any chance that when you ran it to the max and took note of the location, it was with regard to a work origin location instead of the underlying machine coordinates location? The machine coorindates are registered by homing. If you happened to be “zeroed” (XY) to some work origin instead, the values shown for the work origin based location should be ignored when getting max travel.

1 Like
11

Also it’s been a while since I was into the weeds on this, but I’m trying to remember if max travel includes, or does not include, the “pulloff” mm’s stipulated for each axis with regard to homing. For example, if you set pulloff to 5mm, does max travel need to include or exclude that 5mm? I think to be on safe side, exclude. Cannot remember for certain.

12

I dont think so because I homed before the numbers passed the sanity check in regards to how large I designed the cutting area to be. But even if they were off, it still shouldve been plenty of room. Somehow a -1625.076 X move was read which caused the error

1 Like
13

Is the G-code file, at the start, stipulating to work in relative coordinates or absolute coordinates?

A G90 command tells your machine to use absolute positioning, while a G91 is for relative positioning. Having one mode in place while “thinking” in the other headspace, can lead to confusion. A -1625.076 X move can indeed be a correct move while in relative coordinates mode.

14

This confuses me as well because there is a pulloff parameter and also a machine position after homing parameter. The default is to pull off 4mm and then set the current position as Xm = 3.000 which doesnt make sense to me

15

I can post the gcode but I checked for absolute vs relative as well and didnt see any issues which is why I find it so odd

16

I genuinely wish to help. I’m hindered by two factors. One is I’m still suffering some detriments, that are sometimes called mind fog. The other is, it’s been a while since I was down in the weeds on this topic. Does this reference doc provide any clarity?

http://wiki.fluidnc.com/en/support/machine_space_and_homing

1 Like
17

This is extremely helpful actually. I think I understand why axes/x/homing/mpos_mm < pulloff_mm now. On X for example, it will move 4mm away from the X limit switch after homing and set the machine coordinates to X = 3.000 so that you can move back in that direction 3mm and still have a 1mm gap from hitting the limit switch. Makes sense to me at least.

Still can’t figure out why the gcode was triggering the soft limits though unfortunately

18

For what it’s worth, I use soft limits without any issues. I started off also having hard limits enabled, but turned those off for a couple of reasons. One is that without any extra limit switches installed on the X-max and Y-max locations, hard limits make no sense. The other is that enabling them tells the machine to be watching for them (i.e. extra limit switches on X-max and Y-max locations) and if during a job your LowRider brushes against something, say a vac hose, that just happens to bump the limit switch on the side assembly, your machine will instantly think it has reached a hard limit and abruptly halt the cut job. I actually had it happen. But soft limits, once set correctly, work fine. I have seen instances in a slicer for 3D printing in which a glitch in producing G-code resulted in code that could not be executed. I don’t remember seeing that happen with ESTLcam. I do hope you get it sorted.

Also, you can paste your Gcode into as “viewer” that will depict a graphic of the resulting actions. If you see a huge spike sticking out where there should not be a move, it’s a clue the G-code was erroneously created. There are free online viewers. I’ve used one before named “NC Viewer”:

19

While that would seem to make sense, I don’t think it quite jives with the documentation. Here’s the pertinent part, and I will set a key portion in italics:

  • axes/x/homing/mpos_mm The endpoint of the travel range in the homing direction. The homing switch is pulloff_mm beyond mpos_mm. While homing, the machine will travel toward the switch, touch it, back off by pulloff_mm, and set the machine position to mpos_mm.

The example they give has mpos_mm set to 0. I welcome someone else chiming it for why mpos_mm would be set to anything other than 0. You may be right, but the docs seem to indicate otherwise.

20

I just checked my config.yaml file, and my value for mpos_mm is 0 — for all three axes.