I thought I'd found the issue when I realised the Pico board step & dir singnals were negative and the common should be positive. I corrected the wiring to the drivers and now have 4.6vdc High and 0.0vdc Low on DIR.
This did not solve the issue but had the effect of the irregular stutter happening on the High direction (rather than the low as before).
I removed the DIR signal wiring from the drivers as you suggested which resulted in the irregular stutter still happening when the Z- or X- jogging buttons were pressed but not when the Z+ or X+ jogging buttons were pressed!!! The steppers motors of course were always moving in the same direction.
So, it now seems like this is a stepgen issue rather than a driver issue(?)
Could this be a .ini/setup issue or do you think the Pico board may have been damaged by the PUL/DIR polarity error? Strange that the steps generated in one direction are fine but not in the opposite direction when DIR is not being used.
Hi Tommy, no. I increased the ram of the PC a couple of years ago which eliminated latency issues. I’ve also been very conservative with Base_period, acceleration, velocity in the .ini ( or at least I think so in my limited experience)
I replaced the stepper drivers this morning with quality 'open loop' ones just incase the issue was caused by the encoders on the steppers but the problem still exists with the open drivers.
I'm fairly sure now that it is a stepgen issue now(?)
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.
