Odd Pitch Results

andypugh wrote:

CFLBob wrote: This isn't keeping me from doing anything. The system runs and moves properly, it's more to my understanding of why I need to enter a number of TPI that is 1/4 of what the ballscrew clearly is.

This actually sounds like the driver is doing 4x microstepping regardless of what you tell it to do.

LinuxCNC has absolutely no idea what the drives are set to, so it isn't like LinuxCNC is compensating for the change. The conclusion has to be that the switch you changed does not change the drive microstepping. (and the evidence seems to be that the drive is running 4x despite apparently only being specced for 2x or 8x)

It is unlikely but _just_ plausible that you could see this if step/dir/enable wires were switched in some combinations.

I'll have to think about this, because I can't really see it.

It seems like a hardware issue because flipping the switch makes no difference. If flipping the switch changes something the driver is doing, that should affect how far it travels. Really, my reason for posting here was to see if StepConf was doing what I thought, which is multiplying the 200 steps from the motor times the number of microsteps to calculate how many pulses it needed to send to go some distance.

I contacted the vendor of the motor controllers, Automation Technologies, because I have three of them that behave the same way. The three were all bought as one "lot" in June of 2015. They said, "don't know nothing about LinuxCNC, can you try that in Mach3"?

Well, no, I can't. I do have a 13 year old XP machine that runs Mach3, but it will take a few hours to set up to try it.

CFLBob wrote: I'll have to think about this, because I can't really see it.

It seems like a hardware issue because flipping the switch makes no difference.

That is exactly what I thought I was saying.

The absolute no-ambiguity way to tell would be to step the motors by hand with a (well debounced) switch and see how many presses per motor rev.

If you have 3 different units that all behave identically, surely the hardware is going to be OK. They can't have all failed.

I would be going back to basics. Pull down the wiring diagram from their site and check you've followed it correctly. Something I learnt recently is that when using a parallel port, the step/dir wiring is active low so the wiring is different to what I've used with Arduinos and Mesa cards (which are all I've ever used to drive steppers)

Well, the reason I suspected hardware was that the 3 drivers were bought on the same day, and problems with a specific date code or production run are not that uncommon. On the other hand, I bought them in 2015 and if that many were bad, I'd think the vendor would have heard about it by now. I also had a driver I bought in December, and that behaves the same way, so that essentially clears the drivers.

At the insistence of the vendor, Automation Technologies, I just resurrected an old Mach 3 computer and configured it. That's telling me the the number of steps per inch correlates tightly with 400 steps rotation: 200 out of the motor and 2 out of the driver. But that implies all four drivers are stuck on 1/2 microstepping, and they're supposed to be switchable between 1/2 and 1/8. Your clue about active low step/dir signals and the breakout board are about all that's left to investigate.

Did you change the step time and step space? Increasing that might put you on track.
Regards,
Tom

No, not yet. The StepConf had an option for Kelling and I chose that to get started. That was on my "to do" list along with tuning for good acceleration and velocity.