How to jog when beyond soft limits

Now that you confirm this feature is supported and should work. Which would have been good to know in the first response. I can dig deeper, I assume this is exposed in the hal, correct? Is there a special condition or hal pin for jog while within soft limits? While, there is tons of ductiontation, it is hard to find it when you don't know what you are looking for. If I had to guess, the issue is that it's not a direct EtherCAT issue (has it just a HAL component), but rather a dependency on the configuration from a configuration wizard.

I do agree a machine should never be beyond the limits, but if the logic is just a straight greater than or less than than I think there could be an edge case that needs better logic. Maybe this has already been addressed. I have 23-bit encoders, so that is > 8.3 million per rev. So even with the translation to machine units there is a very very small "error" factor. Meaning the "actual" location will fluctuate (bad word choice) with no movement by this very small amount. This can make the axis and/or joint appear its beyond a soft-limit. For instance, when I zero the DRO will remain "zero" but the "-" will flash on and off. Again, maybe all this has been addressed.

Additionally, I have found incorrect and inaccurate details regarding the setup of absolute encoders and how LCNC handles them in both document and forum searches. I am more than willing to contribute back, but "guidance" would be more helpful.

Lastly, tommylight  Thanks for all your efforts as a moderator; it's a thankless task.

are you on the soft limit or the hard limit? if the hard limit, then set a home offset so you have a bit of cushion for drift on power cycling. if its a hard limit switch, in probe basic in the side bar tab for "WCS" there is a button for LIIMITS OVERRIDE. this should ignore the limit switch and allow you to jog away. but this isn't really going to fix the issue over all. you should set the home offset with enough distance away from the limit towards the useable axis travel side so it doesn't ever encounter this situation.

This is just soft-limits as I am using absolute encoders and while I "home" it only sets the axis as homed, there is no travel or switches involved. I may add hard-limit but that is really more of a belts and suspenders solution.

I am not understanding how HOME_OFFSET will fix this for soft-limits. My understanding of HOME_OFFSET my be wrong. but it will offset the home and then the soft-limits will be offset, but I can still jog right to them, and my "little over error" will still be an issue.

Does the LIIMITS OVERRIDES only there for hard limits or will also work for soft-limits?

This all can be just me and my very limited understanding of how to correctly set-up high resolution absolute encores and soft-limits.

On my AXIS gui setup, I can switch to "joint mode" by hitting $ (shift-4)
which lets the servos jog slowly back into the normal travel range. Hit $ again to go back to "world mode" to run as normal from there. Im guessing the other GUI have an easy way to get into joint mode as well. you could also manually turn the ballscrew a little

I can see you issue and agree that a better solution is needed for absolute encoder setups.

Maybe two sets of software limits are needed?
Working area
Absolute maximum travel
If machine is within "working area" travel/jogging outside is needed
If machine is outside "working area" but within "absolute maximum travel", then allow jogging. Once within "working area" don't allow jogging/movement back out

Work around:
Move machine off soft limits on shut-down
forum.linuxcnc.org/49-basic-configuratio...tion-shutdown#226443

Limit switches should never be hit so need to be outside the working area. If you use use shared home/limit switches, a home_offset in the inI file should be used to move the axis away from the limit switch during homing, Your home_offsets are set to 0

@pippin88, Thanks for the move on the shutdown workaround! It will help with the symptom.

Thinking about this more and doing some more testing. Adding more limits will not address the root issue, as any we could be at that new limit and this could still exceed it.

I believe it's a limit resolution issue. Note, I do not know how the code works in comparing and testing for limits. I should be able to specify the resolution of the comparison. In the current case it looks like is doing the comparison at 10ths (.0001) and that scale is just too small. One should be able to set limits at the granularity required for their hardware. My max machine limit is 0.3 absolute in this case. I tried changing my limits to 0.3, 0.30, 0.300, etc. But is seem to compare .3 to the current position of 0.3007 (example). Again, in my case, the axis can shift by 0.0005 +/- .0002. So I would like my limit to be 0.300 (truncated (not rounded) at thou) thus 0.3007 would not be beyond the limit. Think 0.30007 > 3.000 vs 0.300 > 0.300.  Another means would be to add a VARIANCE ini setting to use to calculate the amount of variability in the limit comparison.

Also, this could be a issue for anyone with limits, but maybe due to off_set on the hard limit people don't see it. Or I am completely wrong in my limited understanding of limits work....

In addition, I am more sure the JOINT vs AXIS limit works as documented. (more on that later)

There are a few issues. Should we break them into new threads?

1. The discussed issue about being on or over a limit. The resolution/variance comments.
2. Axis UI will allow an AXIS to be moved back within limits, but Probe Basic does not
3. The docs state: "The [JOINT_N]MIN_LIMIT/MAX_LIMIT settings are enforced while jogging in joint mode prior to homing. After homing, [AXIS_L]MIN_LIMIT/MAX_LIMIT coordinate limits are used as constraints for axis (coordinate letter) jogging" but that is not the case. This is different for Probe Basic and Axis.
3a. Using the Axis UI, the JOINT MAX_LIMIT and MIN_LIMIT are ignored before homed, meaning no limits are enforced.
3b. Probe Basic seems to enforce the AXIS_L limit, whether homed or not