linking and unlinking a pin based on motion-enabled

You mean like that:
net alt_input limit3.0.in mux2.0.in1 ?
This doesn't work as limit3.0.in is already connected to mux2.0.out 


For what I want to accomplish, it seems that mux won't work, as switching net of signal limit3.0.in from ATC-pos-fb to something else doesn't work for me. Once it has to be connected, and once it has to be disconnected from any other signal. 

To explain what I want to achieve(maybe there is some other, better way of doing it):
When controller is disabled, I want limit3.0.in to get value from ATC-pos-fb, so when controller is back to enable, servo wont jump anywhere, as current commanded position is same as current feedback position. As soon as controller is enabled, previous value has to be retained, but pin limit3.0.in now has to become disconnected from limit3.0.in, so it is available for accepting new values, that would be passed from ngc with MDI setp command.
 

What about:

loadrt mux2
addf mux2.0 servo-thread

net ATC-pos-fb mux2.in0
net limit3source mux2.0.out  limit3.0.in mux2.0.in1
net motion-enabled motion.motion-enabled mux2.0.sel

Simpler still would be a sample/hold component
There is a sample_hold component but it uses S32 rather than float.
It would not be a big deal to re-write a float version of it though.

Forum member Spumco did something about S32 to Float and it worked, more here
forum.linuxcnc.org/10-advanced-configura...ndle?start=10#293042

The mux2 example with feedback above does work
as a floating point  sample/hold (just tried)

This does work as a sample/hold, but it still connects pin limit3.0.in to a signal limit3source. So pin limit3.0.in is not "writable" anymore. I cant set its value in MDI with setp command - and this is my main goal, having it connected to feedback source, and after enable, removing it with a command like unlinkp, which makes pin free to accept value again.

That is a bit tricky because you have 2 states (feedthrough/hold)
plus a load new value function.

You can do the link unlink in a script but not in real time AFAIK

The cleanest implementation might be a specific component

Also it might be possible to use two stacked mux2's, using one mux2
to enter the new value to be latched