Setting soft limits as a hal pin?

I have a somewhat complicated setup (not a machine tool) that requires some axis movement limiting. I have a component written that basically does all the heavy lifting as far as figuring out what a "relative" position is in regards to offsets applied through a GUI. Trying to enable a dynamic soft limit of sorts becomes a bit difficult to implement because producing that soft limit value in absolute coordinates that will be useful for LinuxCNC requires a whole bunch of program switches to be set in order to figure out what these absolute values will be ahead of time.

That's not super important, the way the component is structured it would be easier to have 2 output pins that would set true when the minimum or maximum relative position was reached as the component calculates it. The problem is that there doesn't seem to be anything to connect the pins my component would set to. Halui has on-soft-xxx-limit output pins (that never seem to set) but I need soft limit input pins. I would think that after homing halui "soft-limit" pins would set at the point that LinuxCNC figures as the end of travel based on the homing sequence and HOME_OFFSET in the .ini but that doesn't seem to be the case.

The only thing I can find regarding soft limits and setting them at all is to do so in Python but that would require me to have a method of figuring out what the absolute position of the soft limit would be. I think having a soft limit hal pin that would just silently stop travel in that direction once it were set true would save me some headaches.

you may use limit3 as a componet it has unlimited movement outside the workplane

pl7i92 wrote:

you may use limit3 as a componet it has unlimited movement outside the workplane

I tested limit3 for a bit, it's not setup for what I'm trying to do I can't find a way to make that work.

I have a relative position (float out-pin) that's based on the absolute position but offset whenever necessary. I have a min and max (float out pin) position that is already. The relative-position output pin is already limited to stay within the min/max pin ranges when a mode pin is toggled.

The problem is that if the absolute position range after homing is 0-20", My relative position range will be something limited within this range, offset to one side or from center out. My component can get this "relative" position range wherever it needs to be within the absolute range just by converting it accordingly. The problem is that I cannot tell linuxCNC that my soft limit is supposed to be a position, but in absolute coordinates. So in Python there would have to be quite a few "if's" to figure out what the absolute value of the soft limit is supposed to be and sent back based on my relative.

It's easier for my component to be modified to have min and max-limit-out pit pins so when the relative limit is reached it sets a bit and LinuxCNC sees it as something to halt motion in that direction, like a limit switch, A soft-limit input pin would be great but anything that would stop motion and commanded velocity in a single direction silently would work.

I'm not sure if I understand you right, but did you consider setting a "normal limit switch"?
Mike

Mike_Eitel wrote:

I'm not sure if I understand you right, but did you consider setting a "normal limit switch"?
Mike

Not quite sure how to respond to that.

If you make an OR you can stop the machine by either HW limit switch fx. Xmax or your artificial signal "out of boundary" that will stop motion directly.
Hope I expressed it better this time.
Mike

Mike_Eitel wrote:

If you make an OR you can stop the machine by either HW limit switch fx. Xmax or your artificial signal "out of boundary" that will stop motion directly.
Hope I expressed it better this time.
Mike

The machine has 2 inductive proximity switches (hardware) on each axis. These are the hard limits of the machine just like any other machine.

I'm aware I can use an OR component to connect extra HAL pins to the joint.N..xxx−lim−sw−in, but that is the HARD limit switch input. It forces an Estop because it is a safety input. Even in normal use of LinuxCNC you do not really trigger the limit switch input after homing if your home sequence is set to use a limit switch. LinuxCNC enforces the SOFT limit based on the "HOME_OFFSET" setting in the .ini. and this is what typically stops jog motion in real usage.

What I am trying to do is shift the soft limits to further limit motion, not trigger an E-stop as if the machine hit the hard limit switch. Moving the soft limits is supported but as far as I know the only pay to do it is to use a python NML call to change it's position in absolute position values.

What I'll likely wind up doing is just stopping the jog command from executing in Python when my relative position has exceeded in that direction. I think I'd prefer to trigger a soft limit "input" but it's not something that seems to exist.

andypugh wrote:

blazini36 wrote:

That's not super important, the way the component is structured it would be easier to have 2 output pins that would set true when the minimum or maximum relative position was reached as the component calculates it. The problem is that there doesn't seem to be anything to connect the pins my component would set to..

You can set the min and max limits using the ini.N.max-limit and min-limit pins.
linuxcnc.org/docs/master/html/man/man1/milltask.1.html
(Note that the HAL commands to net these pins typically need to appear in the Postgui HAL files.)

I forgot about ini pins. They're easy to miss in the docs because it's under milltask. 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". I can show 0.000" and 17.000" on HAL pins. Problem is I can't connect those pins directly to the ini limit pins because the ini pins need to see 3.000 and 20.000.

The only way I can think of to do that is apply offset components to counteract my offset pins. That gets a bit sticky and convoluted. It's kind of counter intuitive to use an offset component to counter offset a custom offset component.

Right now I had my friend re-write the Component to add the limit bit out pins. In Python it is just reading these pins and issuing a jog stop command and disallowing a jog in the limited direction. It works and I expected a bit of overshoot doing it this way but it's a bit too much overshoot. Running at 2ips it overshoots about .300". It's not a big deal for it to overshoot on this machine but I was hoping for < .010". I guess this is caused by acceleration and velocity not being considered before hand, as well as probably the thread speed vs python polling rate being different.

Any tips on tuning the overshoot down doing it this way?