Determining Angular Scale - Help w/ Microsteps

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!

[Sorry for the following Wall-O-Text, but I got on a roll ]

OP-
Incremental encoders have a resolution which can be expressed either as 'lines' or 'counts'.

In the case of a wheel with slots, each opening is considered a line.  For optical glass encoders, a line is one of the etched or printed black lines on the encoder disc.

If you have a 1000-line (or 1000-count) encoder, that means the disc has 1000 of these interruptions in the optical sensor/reader.

What causes things to get a little confusing is that the drive doesn't just sense one pulse for each line that passes the optical sensor.

There are two sensors in the read head, and one is slightly advanced from the other.  Both of these sensors send signals to the drive, and we call them the "A" and "B" pulses.  So that's two pulses per physical line on the encoder disc.

But it gets better... the drive can sense the rising edge of each electical pulse, as well as the falling edge.  For example, when a line goes past the A-sensor the drive sees a voltage change from 0 to 5v.  Then when the line gets all the way past the sensor the drive sees a transition from 5 to 0v.  Each transition - 0-5 and 5-0 - counts as a 'pulse' to the drive.

Same thing is happening on the B-sensor, and since the A-sensor is advanced a little bit from the B-sensor, the drive can count 4 pulses for each encoder line.  So we basically get a 4x improvement on encoder resolution for free.

Since your motor has a 1000-line encoder, the drive expects to count 4000 pulses per revolution.  This where the "1000/4000" jargon I dropped on you earlier comes from.

www.motioncontroltips.com/faq-what-do-x1...ncremental-encoders/

You can imagine what happens if the drive is programmed to expect 4000 pulses per rev, but the encoder is a 800-line (or some other non-matching value).  The drive thinks the motor is spinning at a different RPM than reality, and the motor magnetic poles don't line up with what the drive has calculated should be the case.  The drive won't turn on/off the coils at the right time, and the motor might turn but would make noise and not move to the correct position.  A significant mismatch would probably result in the drive erroring out.

That's why I suggested checking what value the drive was programmed.  It was unlikely there was a mismatch as most of (if not all) these cheap closed-loop steppers have 1000-line encoders so the drives are generally programmed for 4000 pulses, but it doesn't hurt to check while you're in the tuning software anyway.

You do NOT adjust the 4000-pulse encoder setting in the drive, regardless of the INPUT steps-per-rev setting in the drive (or in LCNC).  That encoder number is explicitly determined by the encoder on the motor.

Input steps per revolution on a programmable drive can be just about any arbirtary number.  While the motor has 200 physical steps (positions) due to it's construction, you can program the drive to move however far you want per input pulse (not encoder pulses).  If you program 1ppr input, then the motor will turn one full revolution for each pulse.  If you program the drive to 3157ppr, it will move 1/3157 of a rotation per input pulse.

Setting the drive to a higher input ppr than the encoder pulses means the drive is just guessing - the encoder resolution has to be higher than the input pulse setting for everything to work cleanly.  You can set the input higher than the encoder in the software, but there's no way the drive can accurately move the motor exactly where you want it because the drive has to guess where the motor is between the encoder pulses.

Older, non-programmable stepper drives were limited to either 200 input steps/rev for a 1.8 degree motor, or some multiple of that native 200 selectable via dip switches.  So when you see '4x', '8x', etc. that means you got to pick 200ppr, 800ppr, 1600ppr and so forth.

If after you take in to account the mechanical transmission (ball screw, belt ratio, etc.) the math didn't work out cleanly, you wind up with some strange number of input steps per machine unit (inches, mm, degrees).  Thats how you get from a drive set to 8x (1600ppr), through a 3:1 belt, and your units are in degrees (1/360)... so you have to tell LCNC to output 13.3333... steps per degree of spindle rotation.

LCNC can't output one third of a step, so whenever you have a non-whole number of steps per unit of measurement, there's a bit of "ish" involved with where the motor lands. LCNC doesn't lose track of where it is, but it can't move the motor exactly where you want.

However... if you program the drive with an input ppr that results in a whole number for each machine unit - degrees in your case - then LCNC can output a number of steps/pulses that can resolve to exactly one degree.  For your belt drive, that means 1200ppr at the drive input results in 10 steps per degree - a nice whole number which means LCNC can resolve to 0.1 degrees per step.  And 2400ppr gives you 0.05 degree per input step resolution.

Remember a few paragraphs ago when I mentioned keeping the input ppr lower than the encoder resolution?  Both 1200 and 2400ppr input values are lower than the 4000 pulse encoder, which means the drive would still have a chance of positioning the motor fairly accurately.

You machine isn't going to actually be 0.05 degree accurate due to variations in the belt, pulleys, friction, lost step here or there... but your INI file will certainly look neater.

Hope that helps.