Thanks for you help.

I found the problem, I guess I am getting too old. (72)
It was a new install and I copied the wrong hal configuration.
I do regular backups and name folders by date (2025-11-11)
I must have read the folder wrong.
Culprit was
setp pid.x.maxerror 0.0005

Every thing is back to normal

If you get a following error, no further movement will be possible so a configuration
issue the causes a following error is s show-stopper.

Other possible reasons for no motion are wrong scaling, too short step lengths
high drive requirement (try single  ended wiring rather than differential)

Single ended wiring:

DRIVE STEP+  --> 7I76EU STEP+
DRIVE STEP-  --> 7I76EU GND

etc
 

yeah, think that is all machines, but could be wrong

I think you are spot on with the "enable" output comment, the motors where not locked. I disconnected "EN+ -> TB2 pin 6 +5VP" and bingo, the motors where locked. So far so good, thank you I have measured Dir+/- and the voltage here change when I jog the axis.

But alas, the motors will still not move. How ever, now I get the "Joint 0 following error" immediately when I try to move the X axis, so I suspect this is why nothing is moving. I have tried to read up on the error, and it seems to point at a misconfiguration in the PID/Acelleration/etc part of the config. But I can't really see it being SO wrong, that the motor won't start at all?

Found it out myself: it was: Is it a known problem that in "linuxcnc probe basic sim" jogging is not working after a program was run.

Workaround: clicking the “Manual” button after stop.

great glad you got it sorted out! what thread for the other issue, i do not see it in the qtpyvcp section?

The watchdog error is a sign of network latency issues.

I would try:

sudo chrt 99 ping -i .001 -q-c 60000 10.10.10.10

which should run for 1 minute and then print timing statistics
to see if this is the issue.

 

could be lost steps causing some errors. i would set the drive settings to fault for ANY lost steps and tune the system until it is not faulting. this would eliminate that. you don't want to run the system in a state where it is losing steps because of motor sizing and machine mass problems.

also i would make sure that your acceleration calculations for both axes come out to be the same.and ideally give both axis the same reduction. just takes several things out of the equation.

Progress has been made. I opened up the mini ITX PC and examined the 5i25 assembly. This is a Jetway mobo with a single PCI-E slot. I had fitted an adaptor (PCI-E to full size PCI) and a PCI extension ribbon cable to connect the 5i25 which sits parallel to the mobo. This was the root of the problem, as the adaptor board wasn't seated properly. The mechanical assembly isn't ideal, so I will need to address that to avoid a repetition in the future.

gmoccapy now works as it did previously, so I can now move on to installing a new SSD with the current version of Mint and LCNC. I will then tackle the config files etc. Watch this space.....

You are right.
the firmware that the seller gave me was 7i92_G540x2D_custom.bit
I did upload it but it gave an error when i started linuxcnc
 

I install Mesa Configuration Tools and download a firmware from there the 7i92_G540x2D without the custom part and it works.
For now i just tested the pin output
The next problem is when i start linuxcnc it gave me an error: Watchdog has bit!
from the post "Mesa 7i97 Watchdog has bit!"  i did latency-histogram --nobase --sbinsize 1000 and its like this:
 
 
 

btw the pc is minipc Fujitsu Esprimo Q920

Thanks for your help.
I forgott that twopass is not working for POSTGUI_HALFILE.
So I moved the declaration of the "not" function to the core.sim3.hal (which I had to change into the "names=" format) and change the function names accordingly.


in probe_basic_postgui.hal:
comment out:
#loadrt not
#addf not.0 servo-thread
and in core.sim3.hal insert:
loadrt not names=not1
addf not1 servo-thread


in probe_basic_postgui.hal:
comment out:
#net prog-running not.0.in <= halui.program.is-idle
#net cycle-timer time.0.start <= not.0.out
change in:
net prog-running not1.in <= halui.program.is-idle
net cycle-timer time.0.start <= not1.out



in probe_basic_postgui.hal:
# changed due to a conflict
# halui.program.is-paused is used is gamepad-encoder-16.hal and in probe_basic_postgui.hal
#net prog-paused halui.program.is-paused => time.0.pause
net net-halui-program-is-paused => time.0.pause


I have another problem with pb, but in a new thread.

I must admit with bitterness that version 2.8.4 with its errors in the g38.3+g38.5 part (Probe tripped during non-probe move) works more stably than version 2.9.7 with all its fixes and error (Queue is not empty after probing). The same object (on the machine desktop), ode and the same g-code program, but in version 2.8.4 there are about 60,000 continuous measurements, and in version 2.9.7 there are no more than 40,000.

Good morning everyone and thanks for the replies.
It's clearly a machine axis, the Z axis.
The machine is old, and in some operations, it's more convenient to be able to drill manually. We're talking about a machine that works with enormous cast iron bases, 10 meters long, so it must have maximum flexibility.

Rown, basically, using your component, I would have:
net Zenable joint.2.amp-enable-out pid.2.enable isfreewheeling
net Zpos-cmd joint.2.motor-pos-cmd pid.2.command
net Zpos-fb joint.2.motor-pos-fb pid.2.feedback

But I don't understand where to connect: pos_fb_out

You don't need a new component for connecting commanded to feedback position
when the joint is disengaged, and the mux component can already do this function.

That is not the tricky part anyway, the tricky part is returning to LinuxCNC control after
the hand motions  were completed.

Ideally there would be a per joint enable signal (that forced LinuxCNCs internal commanded
position to track the feedback position when disabled) but lacking that, a simple hal profile
generator (using limit3 for example) could be enabled to move to the original position
before control is handed back to LinuxCNC.

Are the drives locked?

Note that on many step drives. the "enable" input is actually a disable input
and disables the drive when powered.

For checking outputs without a oscilloscope, you can measure the DIR output and
see if it changes when jogging in different directions

A following error may indicate a setup issue and needs to be resolved.