Step and Direction input vs output Resolution

[Troy_O]

Hi,
I have been using Kflop + Kstep in closed loop step mode with encoders for a couple years to drive our 4 axis XYZA gantry test platforms with excellent results. I have now increased XYZ speed, accel, and smoothness for a new application. I switched from 5 to 10mm pitch ballscrews and have met our speed/accel requirements but now the low speed resonance characteristics of the motors are more noticeable at normal low feeds (motor speeds of around 1000-4000 microsteps/sec). I have had some damping success by varying the derivative value of the PID at these speeds but would like to try Kflop with some higher end stepper drivers with built in anti-resonance algorithms and finer microstep resolutions (32x minimum), The problem I'm running into is that the drivers such as Leadshine's MX4660 all seem to interpret incoming step/dir signals as one full step (200/rev) and then will output these at very fine microstep resolutions. This is fine at higher speeds but has the negative effect of reducing the minimum programmable resolution of the system to .05mm (10mm pitch/200 steps). I would like to have a programmable resolution of at least .01mm. It seems like there should be drivers available with a setting to change the incoming value of step/dir to microsteps instead of full steps like Kstep does but I haven't found any. Am I missing something obvious here? Has someone else found a workaround for this, perhaps by altering the Kflop output? I know we could use microstep drives with different programming control but I'm pretty committed to sticking with Kflop for the controller.
Thanks for your help,
Troy

Similar Threads:

• Mitsubishi MR-J2-40A Servo Drive Native Step and Direction Input!
• Mitsubishi MR-J2-40A Servo Drive Native Step and Direction Input!
• Need Help!- Tranlate puls/dir control signals to Step Time, Step Space, Direction Hold (LinuxCNC)
• Need Help!- Step/Direction pins should be Step FWD and Step BACK
• Other controllers that output step/direction?

[CitizenOfDreams]

The problem I'm running into is that the drivers such as Leadshine's MX4660 all seem to interpret incoming step/dir signals as one full step (200/rev) and then will output these at very fine microstep resolutions. This is fine at higher speeds but has the negative effect of reducing the minimum programmable resolution of the system to .05mm (10mm pitch/200 steps). I would like to have a programmable resolution of at least .01mm. It seems like there should be drivers available with a setting to change the incoming value of step/dir to microsteps instead of full steps like Kstep does but I haven't found any.

That's strange. All stepper drives I've seen interpret incoming step pulses according to their microstepping settings - one step pulse means either full step, or 1/2 step, or 1/8 step and so on. I seriously doubt MX4660 would be an exception.

[Troy_O]

Thanks for the quick reply. 1 to 1 microstepping would seem to make sense. The incorrect behavior was observed with 16x microstepping on the MX4660 but perhaps the drive wasn't working correctly because I noticed it was only stepping consistently in one direction. Possibly has to do with the direction setup time ... I had the Kflop set to use Step/Dir outputs 8-11 and pulse length to this: FPGA(STEP_PULSE_LENGTH_ADD) = 63 + 0x80; (should be 4us) which may be on the short side for the Leadshine driver although the manual states a 4us min direction setup time. The Kmotion Changes/fixes for 4.33l show that setup this was increased to 5.7us but I'm not sure how to implement that.
-Troy

[TomKerekes]

Hi Troy,

A Direction Setup Timing shouldn't cause any irregular motion. Rather only a possible loss of 2 microsteps when the direction changes. Once you are moving at some speed it shouldn't have any effect.

You get the additional ~1.7us of Direction Setup Time (5.7us total) with the new Version automatically. There isn't anything to activate.

I see that drive has a "smoothing" option. I'm not sure what that does. You might try turning that off as it shouldn't be needed with KFLOP.

Regards