# Setting soft limits as a hal pin?

07 Mar 2019 04:00 #127944

They almost work for this. Problem is that value has to go back in absolute coordinates. My component is taking the absolute position from joint and offsetting it by a set amount. The direction it's offset in and the range limit pins are set by other pin switches. So if the offset is set at 3.000" "from minus side" an absolute position value of 5.000" is shown as a relative 8.000" on an output pin. My relative limits in this case would be say 0 to 17.000" but relative 0 is actually an absolute value of 3.000" and relative 17.000 is absolute 20.000"

Your component can read the various offsets from emcstat() and apply them to the ini-pin outputs internally.

I'm not sure what emcstat would do. The component generates the offsets and it doesn't have an NML channel. It's hard to explain exactly what I'm trying to do here. Going back to it it looks like the ini limit pins are the way to get but I'll internally have to apply a bit of math to the range pins I currently have in the component to reverse figure out where the absolute position of those soft limits will be. and then connect these pins to the ini pins for soft limits. It's not too difficult because the current structure of the component self corrects alot of possible issues.

The complicated thing is that there are multiple schemes for offsetting from one side or the other and extending the range as necessary in the opposing direction. Then there is another scheme where the range is based in the center of the machine and the range spreads from the center out.

14 Jul 2019 23:44 #139338
Have to revisit this....

I've had this working for some time with my component's pins writing to the .ini axis limit pins but I've been running into issues sending an MDI command to the exact limit. I have a program function that reads the actual soft limit and requests an MDI move to that position. I get the error:
```USRMOT: ERROR: invalid command
Linear move on line 0 would exceed X's negative limit
error: Linear move on line 0 would exceed X's negative limit```

Thinking it's some sort of FP error with the way the MDI command is sent I dropped the MDI widget into a config menu of my UI and tested, getting the same result. Tried setting the min limits to 3.000" manually in the ini and disconnecting the hal pins that the component uses to set the .ini limits and I still cannot MDI to 3.000" I can MDI to 3.0000000000001 fine.

I've tried messing with joint limits (2.8pre1) with various joint errors and settled on just leaving them unset.

I'm wondering what LinuxCNC module might be responsible for the fact that the MDI command must be less than the .ini limit, and not equal to within reasonable precision at least. There's obviously some hackery that can be done in program to request a position above the limit slightly but that shouldn't be necessary. Is this the Kinematics module? I use trivkins and have tried setting the kinstype to forward, inverse and both but still the same behavior. I've thought about maybe using a custom kinematics module anyway but I'd have to get some help with that.

15 Jul 2019 09:49 #139396 by andypugh
No, the kinematics modules have no internal knowledge of limits. All they do is transform from joint space to world space and vice-versa.

Limits testing happens here:
github.com/LinuxCNC/linuxcnc/blob/2.8/sr...otion/command.c#L192
and here
github.com/LinuxCNC/linuxcnc/blob/2.8/sr...otion/command.c#L222

(Same file, different places in the 2.7 version, where these things are handled a bit differently)

15 Jul 2019 23:52 #139514
Any idea on the best way to go about resolving this?

I'm not the one writing any code (other than hal) but IIRC the method is this...

-Component figures out limits based on input pin switches,
-I have the component's limit output pins connected to the .ini limit pins.
-Python polls the limit stats and programatically requests an MDI move to a limit, waits for the inpos stat, then MDI to next limit without any number conversion.

Looks to me like that in Python the MDI must be offset some minor amount to be within limits. I'm rather adamant on not modifying LCNC source code because I don't want to deal with it not being portable. Any thoughts on that?

16 Jul 2019 21:20 #139606 by andypugh
I think that the rather bodgy answer is probably to porgram the move to be to a point just short of the limit value.

26 Jul 2019 23:49 #140701
Yeah, it appears you're right and it looks like that's the direction we'll have to go. Easiest way to do it.

24 Dec 2021 07:59 #229864 by szary11
Gents,

I need some help. For tool change I have to change max limit of Z axis from 0 to 140, perform the toolchange and then switch it back to original one.
I have used ini.z.max_limit and that seems to be set ok, I see the borders of working space reflected on axis visual window and the pin value change on Show HAL Configuration menu.
But still, motion seems to be unaware of limits change, whenever I try to move Z into positive values, it throws me an error "joint position exceeding positive limit".

I've tried to sync kinematics by issuing M66 E0 L0 according to above attached links, but no luck, still no change.

Any idea on what else is missing?