Stepper Motors Noisy in Reverse - Loosing Steps

I've found the source of the stepper motor stutter (although I don't really understand it fully).

The Pico USC uses PID to count steps. The PID settings in the .ini seem to be the source of the error. I used the following settings from a sample .ini file for the Pico USC and they motors run very smoothly now.
DEADBAND = 0.001
P = 150
I = 100
D = 0.1
BIAS = 0.0
FF0 = 0
FF1 = 1
FF2 = 0.0

I will now run a batch of 50 parts to see if this was the source of the lost steps.

Unfortunately that wasn't the cause of the lost steps.

I've just run 20pcs and lost 0.1mm on diameter (i.e. 0.005 per cycle).

Any other ideas

I looked around in the config files and from what I can see the PIDs use encoder input as position feedback signal.
That being the case I assume the encoders of the motors are electrically connected to the pico board through their drivers or directly.
You should be able to find the lost steps' distance in the pid.0.error pin for x. If the lost step distance is there, the pid parameters has to be better tuned, they don't compensate well enough for deviations in distance. If the lost steps distance isn't there one has to suspect the encoder signal for giving the wrong feedback.

Thanks Andy for your reply. I will check this again to be abosolutely sure.

I have changed the power supply to the stepper drivers to increase the voltage to 60vdc (from 36vdc). I'll run another batch soon and see if that's helped (clutching at straws!)

I did notice that the increased voltage on the drives caused a bit of interference on the computer monitor so I guess there must be some sort of electrical noise from the drivers even at rest. I noticed this previously on my workshop radio as well when I turn the control panel on. Is that common do you know or maybe I have a lot of electrical noise??

Thanks Hakan for your reply.

The encoders are currently fed back to the stepper drivers only, so it is a 'semi-closed' loop system.

The Pico board has a dip switch option that allows it to count steps generated by the board if encoders are not connected so I guess that's what the current PID setup in the ini is doing. I think I have these settings setup as default from the Pico config example files but I don't fully understand that area so it could still be the cause of my issue.

I am thinking of swapping out the closed loop stepper drivers for open loop versions and then connecting the stepper encoders to the Pico board. However, the stepper encoders have six wires (PA+, PA-, PB+, PB-, 5v, GND) but the Pico board is only looking for three signals (A, B, Z,). I don't understand enough about encoders to know if I can match these two so need to do a bit more research. I think the 'Z' is an index signal which I guess I won't have on the stepper encoders I've got (?)

Update on the solution to this problem in case it might be of use to others:
It appears that even though the Pico Systems USC board is counting software steps the PID still needs to be tuned to the stepper scale. With excellent support from Jon at Pico I used the following settings for my scale of 1280. This cured the one direction stutter and the lost steps.

P  40
I 0
D 0.01
FF1 0.84
FF2 0.0001
DEADBAND 0.0009  (you want this slightly more than one step is worth to prevent endless hunting.)

The FF1 is found by using halscope to watch the error with a very low P, so that the FF1 is providing velocity control.  Then, you increase P to reduce the residual error.  This gives the most stable system.

Jon tunes this with a speaker connected to the step output (with a resistor) and listen for a smooth tone.