UGCS help - hard limits being hit

I’ve posted this on the UGCS git hub page, but I figured I’d also try here as I’m sure this is a machine or something else setting - likely due to the new Z axis.

I’m having an issue with my m3 command - I home my machine, find datum on my stock then reset 0. Upon running my program my Z axis retracts and hits the z axis homing switch. I then get the error "an error was detected while sending ‘s20000M3’ (alarm:1) hard limit has been triggered… I then have have to restart but get this every time I try to run a program

I feel this is either a code or gbrl setting error but I have ran quite a few programs successfully but this is new to me, and now I can’t seem to run any commands…

Cheers, Luke

Are you outputting your GCode from Fusion 360 using the Carbide3D Post?. I was getting the same issue and solved it by using the generic GRBL Post in Fusion. I am on GRBL 1.1 and trying UGS Platform on a Macbook Pro.

Hi Patricio

I was using the generic version so did try the CM version and got a G54 error (same place etc). I’m having the same issue on files I ran in the past.

Can you confirm the post processor you are using? I’m using generic - grbl.

Do you have soft limits enabled? If so, try turning them off.

Post the pre-amble of the code?

Wait, something here doesn’t make sense. That’s a spindle on command…that can’t be the one actually causing the error. A spindle speed/on command isn’t going to cause a limits error. What goes the G0/G1 before look like? Could you show a few before, and a couple after? If there are commands in the buffer when it finds the error I think there are some issues with which command actually caused the error.

1 Like

I don’t think it’s the spindle command actually causing the error but at the point the spindle command is triggered the Z axis is at the top of its travel and the limit switch is triggered.

Here is the code I’m trying to run (14.5 KB)

I’m having issues on all files, including ones previously ran which makes me think this is a settings issue but not sure which one?

I am using the generic version of GRBL Post. Latest version and also the nightly build of UGS Platform. To be honest, I have only run air milling tests and probing. My intention is to get comfortable with it and learn it to maybe replace Carbide Motion. I wish it wasn’t so but I am a little fed up with all this waiting for the probe and decided that I might make my own.

I don’t use Fusion 360, but is there a setting for “safe height” or “clearance height” or anything? If your zeroing your Z on the top of some thick stock, and you only have 10mm of travel left in your Z, a “safe height” of 15mm would cause the spindle to attempt to move up 15mm before moving laterally, and that would hit your hard limit.

Just thinking out loud…

1 Like

I thought that but the Z is moving say 100mm up, and the program is 15mm

Here is a question if someone can test, If you run the above job how far up does your program move Z - does it go all the way to the Z limit switch?

If it doesn’t it’s a machine calibration issue - although I’m not sure how as when I job 1mm it moves 1mm

Here’s the top snipped of your gcode:

G90 G94
G28 G91 Z0
T8 M6
S20000 M3

G91 Z0 I -think- will retract Z all the way to the top (enter abs coordinates then move Z0 in last G0/1 mode…I think…not an expert here then switch back to relative mode. To >me< seems a little weird) I would expect that to trip the switch. The question here is why is your program doing that?

1 Like

Good question.

I’m using fusion 360 and haven’t changed anything. What do you mean by relative mode? I’m newish to G code configuration. In CM (which I can’t use due to software limits). It raises and prompts the tool change dialouge in CM

I’ve just compared 2 g code files, one ran 2 weeks ago and this one. The starting string is near identical.

I’m now trying to work out if it’s a machine configuration issue (most likely) or a UGCS issue.

Can anyone confirm if when running a job the machine Z will retract to 0 then allow it to keep going?

I’ve looked into this more this evening and it looks like the error is caused by this command right at the start and the whole issue might be cause by how I home.

G28 G91 Z0

The Z is traveling past the 5mm safe distance trying to reach absolute machine zero and tripping hard limits. I’ve never had this issue so think there might be a really simple fix. Is there a command to reset G91 Zero.

Currently my starting procedure is Home machine, reset zero with top button (although that places 5mm safe distance on each axis. Should I then create another command/macro to wipe the 5mm safe distance from the machine?

Or should I swap my post processor?

I tried my third post processor which removed this command. Is there a UGCS preferred post processor?

Hey @Luke. Can you set your zero anywhere else other than your “home” position, set this new position as your new zero and then run your GCode? I am not at my Nomad or I would try. I will later on tonight if you haven’t tried this. What is happening to you sounds exactly like what was happening to me earlier this week. My problem was that I was using Carbide3D Postprocessor and not the generic GRBL Post. After I discovered this, homed and set my zero, it all seems to be running smoothly. I have not milled anything yet though. Only air. I want to try to mimic Carbide Motion functionality with macros. It makes my head spin just thinking about it. I want a macro for moving to the center of the table to a known coordinate on X and Y. The tool length probing is already there with the probing function in UGS Platform. I would love to have a macro go to the Nomad probe and do this after a tool change.

I can but g91 relates to absolute position. Rather than just going to the set 0 on z it’s trying to go to absolute 0 which is past the Homing switch. When that is triggered it kills the code as it’s a hard limit.

I was using the generic post processor but still had this issue. Do you have a g code file you can upload so I can take a look? I’m using one I installed a while back, I’ve only ran one test but very different g code.

I’m with you on replicating the CM functions, I’m slowly working on it. I just keep on reading up on g code to understand all the commands.

I updated to the latest UGCS platform this evening.

@Luke, I’m getting the same results as you. Hitting the Z limit switch. Here is a small test that runs ok. GRBL Post out of Fusion 360 zero set at bottom lower left of stock in Fusion. (3.9 KB)

Figured out my first macro to rapid position to the center of my table. Started looking at what the console shows to see how things work. Here is my first line of GCode:


This code is, of course, specific to my machine as the center coordinates are not exactly the same in all machines.

I’ve just been messing around with UGCS, I love it’s level of flexibility.

I now have my basic coordinates programmed in. I used the command G53 x-200 y-200 f2000

Obviously chance the coordinates for you machine.

I also setup my Rii keyboard properly, for the first time in forever I can jog the Z axis with the keyboard :slight_smile:

I just started playing around with UGS and I see the same issue. I got the same error as Luke did originally, but I also get an error when I manually try to rapid Z to zero.
Home machine, jog Z down a few inches, MDI “G53 G0 Z0”
I get this, “An unexpected error was detected: (ALARM:1) Hard limit has been triggered. Machine position is likely lost due to sudden halt. Re-homing is highly recommended.
[MSG:Reset to continue]”
I always start out my codes with this machine coordinate Z0 rapid. It’s just a poke-yoke for myself. I have all of my post processors set up this way, and all of my macros in CNCjs started with this line.
I would say this is a UGS issue.

Z0 is at the top of limit switch in (G53) machine coordinates. I bet G53 G0 Z-5 would work as it would set it 5mm below zero

1 Like