Need help with understanding of one core concept

Hi Guys. I've got motivation to play with writing own component. I'd like to design own thc to drive thcud mesa controller.

My initial experience is rather negative at the moment. I stuck in place where I'm trying to take control over Z axis stepper driver moves.
I've started my experiment with placing of my simple component in between of

axis.2.motor-pos-cmd

and

hm2_[HOSTMOT2](BOARD).0.stepgen.02.position-cmd

Whatever I put there - either trivial component which just copy signal from input to output, standard component like mux, and.. etc which does basically the same, I've always got following error on a rapid move. I'm running RT Preemptive LinuxCnc build and of cource running all hal componets in servo thread.

I slightly stuck here because I have many assumptions which could explain this, and need an expert opinion to point me from what to start to solve this problem. Currently I don't quite distinguish what's exactly happen if I link 2 pins in hal file and if I link them and put a component in between. Does the direct link is thread independent and putting of a component may involve synchronization issue? What supposed to do in such case? Does any tools which could help to synhronize low frequency stream and high frequency? Maybe this could be managed by onboard functionality (I have Mesa 7i76E which based on 5i25).

Any support from lcnc guru which could help me realise full picture would be really appeciated!

LinuxCNC expects motions commanded position and the feedback position returned to motion to match (within the min_ferror/ferror limits) so you cannot simply change the stepgens position without causing a following error

In addition, any changes to the stepgen position must obey the stepgens acceleration and velocity limits

A simple fix is to simply loop motions commanded position back to motions feedback position (but of course you will lose the ability to detect real stepgen faults) A better fix is to add your offset to the commanded position (obeying acceleration and velocity limits) and then subtract this offset from the actual stepgen feedback before handing it back to motion

The thc component already does this so if you are writing a new or improved thc component, it would be a good place to start

Edit: Also if a simple component that simply copies commanded position from an input to an output hal pin fails, this suggests that either the component was not added to the correct thread (no addf statement) or the thread order is wrong (addf in wrong place)

The issue probably caused by wrong thread order, or something similar. THC acting when plasma is up and running, and arc_ok status is true. In all other conditions it just bypass position command from application. It also keeps feedback signal untouched - and main idea is to command next position on every observation moment based on current feedback position + delta. But in fact it failed within part of code which bypass commanded position from input pin to output - case when thc is inactive.

I've attached the files here. The load of thc component happened into specific file which contains all related to thc functionality. It included after main hal file

[HAL]

# The run script first uses halcmd to execute any HALFILE
# files, and then to execute any individual HALCMD commands.

# list of hal config files to run through halcmd
# files are executed in the order in which they appear

HALFILE = plasma-7i76e.hal
HALFILE = estop.hal
HALFILE = probe.hal
HALFILE = thcad.hal
POSTGUI_HALFILE = postgui.hal
HALUI = halui