Is there Object Model variable for "move outside soft limits"?
-
We're working on tool-changing macros for our printer and are using a U-axis to actuate the Jubilee inspired tool lock and unlock mechanism. In the course of developing and debugging our macros, we've had a few instances where the u axis moves beyond it's soft limits while we have those limits disabled via M564 S0. All OK, so far. When we move back within the X,Y,Z soft limits and re-establish the soft limits with M564 S1, there have been times when the U axis is not back within it's soft limits.
We clearly have a bug in our U axis design, but the behavior when we're in this state (U axis outside limits AND moves outside limits not allowed), is bothersome. Moves that are only X and Y are ignored (and a warning message flashes). We've had a few crashes in the docking area due to this.
So (finally) my question - is there a variable in the Object model that indicates that an axis is currently outside it's soft limit? My thinking is that just prior to running our M564 S1 (return to soft limits), we can see if any axes are outside and take some action - like halting operation.
Thanks. and happy spring to anyone living in a latitude where that's an important milestone.
-
@mikeabuilder Can't you just check the position of the various axes against the limits? I think all of that information is already available in the object model.
I'm surprised that moves of X and Y produce a warning when U is outside the limits can you post the actual message you get in that situation?
-
@gloomyandy - Thanks for the idea. I won;t be back in front of the printer until next week, but I'll grab the precise message then and post it.
And I also had an idea that any single axis outside it's limit would restrict moves only on that single axis, but I can see how moving on another axis could get you into trouble is one axis is out of bounds. I also did not expect that those moves would just be skipped with a warning, allowing future moves (that are preceded with a G53) to be executed. It's also possible I'm not quite a root cause of my bug yet and this axis out of limit thing is a red herring.
-
@mikeabuilder whether movement outside axis limits is allowed is called "move.limitAxes". But the axis limits are also available in the OM, so you can do your own tests to check whether axes are within limits. Note, it's the machine position (not the user position) that's limit-checked.
-
@dc42 - thanks for the pointer to move.limitAxes. This should help us a lot.
A little background on our work. We're developing our tfree.g, tpre.g and tpost.g macros fro tool changing. Our tools are all parked outside the soft-limit are of the machine. Our simplified approach for a tool change has been:
tfree.g -
- G53 move to a position right in front of the parking spot for the tool.
- allow movement outside soft limits
- G53 move the tool to the parking position and call the macro to release it
- G53 move to get back inside the soft limits
- don't allow movements outside soft limits
tpree.g
- G53 move to a position right in front of the new tool parking space
- allow movement outside soft limits
- G53 move the tool to the "grab" position and call the macro to lock it to the carriage
- G53 move back to get just free of the tool parking posts (but still outside the soft limits)
- don't allow movements outside soft limits
tpost.g
- allow movement outside soft limits
- heat the hot end
- purge some filament
- G53 move one (or more) times over a wiping thing
- G53 move to get back inside the soft limits
- don't allow movements outside soft limits
- memory slot 2 relative moves back to the original tool location
Our current theory for root cause is the macro that locks the new tool in place is leaving the U axis beyond it's soft limit which is causing the last moves in tpost to be blocked. When we try another tool change immediately after, the first move (to the spot in front of the parking space) in tfree gets blocked, but the subsequent move into the parking space is not. That lets the tool move into the wrong location, resulting in lots of noise, sometimes broken parts, and a quick run to the power switch.
-
Quick follow up questions for @dc42
The OM move.limitAxes variable seems to indicates whether moves are allowed outside limits, but it doesn't indicate if any of the axes are currently outside their limits. I think this can only be understood if I do a G4 P0 (to wait for any moves to complete), then look at each axis, as you indicate.
Second question: can the extruder be an "axis outside limit"? I think not, only because there is no soft limit set by the user (in config.g) on this "axis". For example, if my extruder is set to absolute positioning and I retract some filament, can this cause RRF to believe I have an axis outside the limit and then throw the following warning: Error: G1: intermediate position outside machine limits? I think it will not, but I've been switching my extruder to relative positioning (M83) before making extruder moves in my tool change macros, then changing it back to absolute (M82).
-
@mikeabuilder extruders don't have position limits. The recommended way to wait for motion to stop is to use M400.
