Determining Angular Scale - Help w/ Microsteps

langdons wrote:

Really bizzare.

Try the motor sans belt, draw a notch on the pulley attached to the motor and count how many revolutions it makes.
 

Yes, I would first check if the unloaded motor is doing what it should.

What is confusing me: Is the encoder in the belt loop or is it on the motor? If the encoder is connected to the motor and the driver is matching, a closed loop system should produce an error if loosing steps. Or not? 

Are you sure the pulleys are not slipping. (do not ask me why I ask this ) 
Had a similar situation, where things went slightly off. (at first I did not notice that the pulleys were not 1:1) after correcting that it was still doing weird stuff. I started searching for an electrical problem, but finally noticed that the set screw thread on the encoder belt pulley was not cut through all the way. It felt tight but it was not, result was the encoder was counting too less.

p.s. Another encounter I had was too short step input pulses to the driver, then the driver "thinks" it needs to move e.g. 1090 steps, but the controller was pulsing 1294 times and some of the pulses (not all) were skipped.
Some drivers have settings for input pulse duration. (just an idea)

pps. Thanks to my skillful EMC design I managed to drive the Z-axis down based on spindle rpm in a random pattern.





 

Full steps, 1/4 steps, 1/8 steps, etc. are all you should use for a 2-phase stepper.

Half steps have torque ripple issues.

Less than 1/8 (1/16) seems too slow for me.

Note that small microsteps don't work with an undersized motor or driver (as is likely the case for you).

A micro step for a 2-phase stepper motor must be 1/2^n | n ≥ 0

Steps/rev should be 600 for full-step, 2400 for 1/4 step, 4800 for 1/8 step, or 9600 for 1/16 step.

Otherwise you have some issue, mismeasurement, miscomunication(bad cabling), or some other issue.

3*200=600

Math is always right (though sometimes it appears wrong at first)

Does speed make a difference?

Hi Friends, 

catching up on replies now, i was out traveling for work the last few days. Here are the links to the motor and driver i am using. 
Motor

Driver

Ill try to reply to everyone in this one reply to avoid any confusion, and ill to to work backwards as much as possible. 

@Langdons
 - Does speed make a difference?
No it doesn't seem like it. The Arduino code i am running does  a slow loop and a fast loop changing the delay int between steps and its been consistent every time. Although i haven't cranked the speed up and don't plan on it. 


@andypugh
- you are correct, i am trying to understand the most optimal way to get this into Lcnc and based on previous posts I can maybe modify the drivers software to make that a whole number. Still investigating this though. 

@timo
- I have and it works as expected and repeatably. The issues comes up when i put it into the pulley system, with the reduction i can't hone in a precise step/rev, from which i can derive the steps/deg for a rotary axis in LCNC. 
- in regard to the pulleys, I am certain the motor pulley isn't (the ole sharpie method) the idler doesn't count, and no am im not 100% certain that the drive shaft is fixed in place, however with everything powered down i can turn the drive shaft and it turns the motor pulley. that on top of the low speeds and it being uploaded gives me a decent amount of confidence in my answer. 
- I also haven't even begun to tackle any of the encoder/ pid error stuff because when i tried initially i discovered this the issue we're dealing with now, that comes next once i have this setup pretty good. 

@spumco
- This is my plan. I have the cable and am able to get it to talk to my PC, the issue is once i get it its all french to me. How would i verify the 4:1 encoder resolution? Should the drive be connected to the motor when i do this? I am going to spend the next few hours messing with it on the software side and ill report back what i learn or how i mess up. 

Thank you all again,
 

Okay so i confirmed that 1600 is the number, but this just makes me question what the micro steps are doing. Its clear i don't know what the step/rev actually translate to.

I guess i am just looking for what the optimal dip switch stetting is for my setup and what this number should be.

This software seems to have a decent scope as well. Is there any reason i shouldn't use this to tune the PID and get it close before moving to LCNC? It just easier when its all on the test bench. I know alot of wiring noise factors in it final resting place will make a difference but could i get it close here? or would the new environment completely change the PID settings?

update,

I changed the number to in the driver gui to 1800 and upped the 'stepsPerRev' variable in the Arduino code to 600 and its working great so far. This is with the dip switches set at default.

If i switch the dip switches to 1600, the value in the gui updates to 1600. So this leads me to believe the dip switches set the steps per revolution. in retrospect i guess its obvious.

I am going to leave it as is because its clean and now going to switch the control to closed and see about tuning in the PID before i reinstall it on the CNC. unless thats not a good idea.

notJamesLee wrote:

I am going to leave it as is because its clean and now going to switch the control to closed and see about tuning in the PID before i reinstall it on the CNC. unless thats not a good idea.
 

 

I'd suggest leaving the PID settings alone in the drive for now.

I think the drive's following error setting is PA0.05, which is factory set to 4000 counts before an alarm.  In your screenshot it looks like that parameter is "Max position following..."  and I think the cut-off text is "...error."  If so, that's the number of counts the motor can be out of commanded position before the drive faults.

Which means:
1 - the encoder PPR setting in the drive is correct (it's looking for 4000 pulses, which is what a 1000-line encoder produces in quadrature), and
2 - the motor can be a full revolution out of position before the drive faults.

Set the following error counts to 200 for now, and you can adjust that up a bit if you start getting drive following errors under normal positioning moves.  Frankly, with as low a torque load on the motor as I expect you could probably get away with 50 counts (or less).

Regarding your earlier question about the encoder... the motor datasheet indicated a 1000-line, 4000-pulse encoder is on the motor.  If the drive wasn't programmed to expect a 4000-pulse encoder the motor/drive pair would act really wonky.  Those drives are usually set to match the motors, but it doesn't hurt to check.

thank you!

I did find the 'encoder resolution' in the GUI and it was at 4000. Probably a dumb question but since we adjust the steps/rev to cleanly be divisible by 3 do we have to do something similar here? I again dont think i understand what encoder resolution means, what are the units of this? 

ill hold off on any pid tuning for now ill just update the error readings and reinstall it on the machine and start tuning it there.

Thank you all again for sanity checking and showing me the way!