Dead in the water on 7i92 config

pid.n,maxerror is a PID tuning parameter and not related to following error

There may still be a thread order error, the sample file for the gantry comp has this thread order:

OK I tried that. Tried putting writes before the pid-calcs, then after. Tried gantry read before the hm2_7i92 read and other permutations, Nothing changed. I'm leaving it at:

addf hm2_[HOSTMOT2](BOARD).0.read servo-thread
addf gantry.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.0.do-pid-calcs servo-thread
addf pid.1.do-pid-calcs servo-thread
addf pid.2.do-pid-calcs servo-thread
addf pid.3.do-pid-calcs servo-thread
addf gantry.0.write servo-thread
addf hm2_[HOSTMOT2](BOARD).0.write servo-thread

I'm a bit confused about the lines from the Probotics Comet.hal example:
#loadrt gantry count=1 personality=2
newinst gantry gantry.0 pincount=2

The newinst gantry line generated errors, I commented it out and uncommented the loadrt gantry line.

I would use the order in the sample file since it works and was written by the same person that wrote the gantry comp

newinst is a machinekit command, it does not exist in linuxcnc

Well, I can't use the Probotix comet.hal file literally because it doesn't use the PID I have for the 7i92. More addf lines have to be there. So it can't be exactly the same thing.

I think I tried every meaningful combination of ordering the addf, and nothing worked or changed anything. I'm thinking the thread ordering is a red herring.

It occurred to me that you don't need an X-gantry machine for others to test this. Just the LinuxCNC RTK and a 7i92 card. They're just stepping outputs, there's no feedback from the machine. It won't matter that no stepper drive is hooked up to it.

here's an example i cobbled up that works for me:

freeby.mesanet.com/gantry.zip

thread order _is_ important

Alrighty! Well, first I just tried reordering my .hal file's threads in exactly the way you have it. It didn't help, same Following Error problem. So I just switched to your .ini/.hal.

I adapted your file pretty easily (set for 7i92, removed Spindle, etc). It did something really weird- X[0] ran like 10x too slow and stayed in motion 10x longer. I found that- the section which should set the pid.3 parameters actually sets pid.0 parameters (being set with the same variables as [AXIS_0], I see that's just a cut-and-paste issue).

Well... WELL! It does move! This is great!

I tried going line-by-line to understand what was wrong but there's more than a few different lines to sort through. Guess it's not really important since it works. It works!

Yes I forgot to replace 0 with 3 in the PID setting

The AXIS 0 setting both PID0 and PID3 parameters and stepgen timing
is deliberate since they are presumably identical hardware it allows setting
all the timing/PID settings on one place