Odd Pitch Results

Over the course of the last month, I've slowly been getting a system I've built up running and now everything runs, but something confuses the heck out of me. I'm running Kelling KL-6050 motor controllers and 570 in-oz NEMA 23 motors.

I'm running in English units, with metric ballscrews, which just means some of my numbers have several decimal places. The screen in StepConf says to enter turns per inch if you're using English units or pitch if you're using metric units. My units are English, and 5mm pitch is 5.08 TPI. If anyone were to put a ruler on the screw, they'd enter 5 as "close enough".

The weirdness is that when I enter 5 the results are off by a long way. The correct number of TPI so that the mill runs accurately is 1.27. That's 1/4 of 5.08.

The motor has 200 steps per rev. and the controller steps in either 2 or 8 microsteps. I'm set to 8. Since there's that ratio 4 again between 8 and 2 microsteps, I thought I'd power down my controller, change the switch over to 2 and see what it does. I expected it to step 1/4 of the distance, but it went exactly the same distance. If I tell it to go 0.1", it does so regardless of that switch position.

I do NOT change the .ini file or anything in LinuxCNC when I flip the switch. I leave LinuxCNC running, turn off power, flip the switch and turn the power back on.

I come from a background in Mach3, where I'd multiply the 200*8 and get 1600 steps per turn and 5.08 turns per inch. Is StepConf doing this? Or LinuxCNC?

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.

CFLBob wrote:

Over the course of the last month, I've slowly been getting a system I've built up running and now everything runs, but something confuses the heck out of me. I'm running Kelling KL-6050 motor controllers and 570 in-oz NEMA 23 motors.

I'm running in English units, with metric ballscrews, which just means some of my numbers have several decimal places. The screen in StepConf says to enter turns per inch if you're using English units or pitch if you're using metric units. My units are English, and 5mm pitch is 5.08 TPI. If anyone were to put a ruler on the screw, they'd enter 5 as "close enough".

The weirdness is that when I enter 5 the results are off by a long way. The correct number of TPI so that the mill runs accurately is 1.27. That's 1/4 of 5.08.

The motor has 200 steps per rev. and the controller steps in either 2 or 8 microsteps. I'm set to 8. Since there's that ratio 4 again between 8 and 2 microsteps, I thought I'd power down my controller, change the switch over to 2 and see what it does. I expected it to step 1/4 of the distance, but it went exactly the same distance. If I tell it to go 0.1", it does so regardless of that switch position.

I do NOT change the .ini file or anything in LinuxCNC when I flip the switch. I leave LinuxCNC running, turn off power, flip the switch and turn the power back on.

I come from a background in Mach3, where I'd multiply the 200*8 and get 1600 steps per turn and 5.08 turns per inch. Is StepConf doing this? Or LinuxCNC?

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.

Did you power down the driver when you changed the settings?
IT is definately suppose to change if you change microsteps.

Yes, I powered down the stepper motor driver. I didn't change anything in the SW, just let it keep running. It didn't care, or even seem to know, that drivers were off.

tommylight wrote:

First choose mm in the screen where the name of the config is, that is in stepconf. At the motor setings you have a 1 to 1 ratio if your steppers are driving the ballscrews directly, then microsteping (if it does not work when changing it in the drive, you will have to test a bit to figure out where it is at), in the pitch set it at 5, not 5.08. Open test tbis axis and set it to move say 50mm or more if the space alows, hit run and measure roughly if it is as it should. Repeat the last step after you change the microstepping value, do not change anything else. Only after that you can save and check actual distance using MDI commands.

My original thought was that it was somehow messing up metric and SAE units, but when I realized how close those were I thought it couldn't be. The only difference between what I enter in that screen is 5mm vs. 5.080 TPI. Numerically, they're so close the results would have to be similar. I haven't actually tried to set up a metric .ini file.

My system has the motor driving the ballscrew directly, so no pulley, just straight 1:1 drive. The motor's data sheet says which DIP switch to set, and one way is 2 microsteps, the other is 8. That switch is having no effect.

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.

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.