Stepper Motors Noisy in Reverse - Loosing Steps

I have been struggling with lost steps for a while now on my EmcoTurn220 lathe. Running LCNC from a PC via a Pico Systems Universal Stepper Control board. I've been using Stepconf, replaced the steppers recently with 'semi-closed' loop ones, reading through thte forum to try and overcome the problem but it's not gone yet.

I loose roughly about 0.005mm on diameter per gcode cycle (depending on the gcode programe of course)

I am convinced this is not a harware problem as re-homing the axis returns the machine to the correct dimensions (I have also marked the pulleys).

I noticed however that the stepper motors on both the X and Z axis are noisy/irregular in reverse and think this may be where steps are being lost. I videoed an example with my phone resting on the lathe for you to hear:



Again, I'm quite sure this is not a hardware issue as it happens on both axis in the negative direction only.

I have attached .ini , .hal, and a pdf with some specs.

Does anyone have any idea why the steppers would be noisy in reverse or why I may be loosing steps??

Thanks in advance


 

Just a WAG but maybe the direction signal has insufficient drive or there's a connection issue?

Measuring the DIR signal voltage in both states at the drives would confirm/eliminate this as a cause of trouble.

Thank you PCW for your reply. I think we may be onto something there.

I measured the DIR signal voltage at the drive which was a stable 3.30vdc when high and 0.15vdc when low. The signal is high when at 'rest'.

When moving in the 'high' direction the steppers are smooth. When moving in the 'low' direction they have the irregular stutter.

There is a dip switch on the drivers which changes from CW to CCW rotation. I switched this, on both drives and reversed the scales from + to - in the .ini file to maintain correct movement. The result was that the irregular stutter changed to the opposite direction i.e. when the steppers were moving in the opposite direction. Therefore I guess this has to be a driver/stepgen DIR issue.

The driver documentation suggests a 4 to 5v signal for pulse/dir and the Pico System USC board should be putting out 5v. However, I only measured 3.3v. Could this be an issue do you think even though the drivers seem happy in the high state??
 

Does the drive have isolated inputs? (so the drive has DIR+ and DIR-) ?
If, so what does the other DIR pin connect to?

Yes, there are seperate terminals on the drivers for DIR- and PUL-.

However, both PUL- & DIR- are commoned together on both Z & X drives and taken back to the negative on the STEP/DIR header on the Pico USC board.

Funny that it works when high (3.3V seems marginal)
but not when low ( 0.15V seems like a valid low )

If you disconnect the direction, it should behave the same as a low
This might be worth testing (with a hand on the estop button)

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(?)