Encoder Issue

[mrjimmy]

I can use MAX to move a stepper motor in open loop mode, but when I switch to closed loop mode, I get a following error everytime.  The specs of my encoder tell me that B leads A in the clockwise rotation (and vice versa for CCW roation), but I don't see a place in MAX to input this information (yes, I realize that almost every encoder in the world is the opposite way). 

First, I am wondering if this mix-up with clockwise could be the cause of my following error
Second, if so, I am wondering if there is a setting in MAX that I am missing to switch A and B, or if I just have to reverse the wires?

Thanks

[Brian_Beal]

The easiest way to check this is to turn the motor by hand and see which way the counts go.  If they are going the wrong direction, then swap 2 wires of one phase only.

[Jochen]

Besides checking for wrong wiring you should also make sure that the encoder counts per rev./stepper steps per rev. ratio is correct. Please have a look at this document in our knowledge base for more information.

Best regards,

Jochen Klier
National Instruments Germany

[mrjimmy]

I correctly set the motor and encoder counts, so that is not a problem.  The motor is connected to a lead screw that I cannot manipulate to extend or retract, so I cannot manual move the device to see which way the encoder counts go.  I assume my only option is to switch the wiring and see if things work.

Thanks

[mrjimmy]

So, I got everything working in closed loop (no following error).  Luckily, the wires were not tough to switch.  

A couple of other issues:
1)I could have figured out this problem in MAX because under the advanced tab, the encoder counts were indicating the opposite # than what I indicated in the target position if I set it for relative movement.  Example: I set a relative move for 1000 steps, and under the advanced tab, the encoder counts read -1000 steps

2)I'm wondering if the closed loop mode is working correctly because even though I tell the stepper to move 1000 steps, it'll move 999 or 1001 on 1 out of 7 or so times.  Is that because MAX isn't really working in closed loop mode?  Or is there a setting somewhere that I can set to make sure motor always pulls back (or pushes forward)  to match this up?  Or does it have to do with that the motor might not be lined up at the start of the index, so there is a little slop.  Either way, how do I correct these problems to make sure that I am getting exactly 1000 steps when I say 1000 steps?

Thanks

[Brian_Beal]

I'm not sure how to do this in MAX, but there are functions that say if, and how many times, it will try a pull-in move.  You can also set the limit for pull-in moves.  I believe that you also need to set the "move complete" criteria in MAX, expecially the deadband.  Keep in mind that your system may not be capable of moving to the exact count.  This depends on the resolution(microsteps) of the driver versus the resolution of the encoder.

[Jochen]

Brian, thank you for the good answer.
The function to change the number of pull-in moves is

status = flex_setu32(u8 boardID, u8 resource, u16 attr, u32 value);

Parameter discussion:
resource = <axis number>
attr = NIMC_PULL_IN_TRIES
value = <desired number of pull-in moves>

In LabVIEW this is the Set u32 VI.

I have been working with NI-Motion borads for a long time now and I'm 100% sure that if you tell the board to output 1000 steps that it does exactly that (I have verified this with external counter devices). There are a lot of reasons that could result in the motor not reaching the exact end position, even when you use closed loop mode. Typically this is caused by reversal backlash in the mechanics or very high microstepping ratios.

By default the motion control board tries to reach the exact position with a maximum of 3 pull-in moves. You can increase this number with the function mentioned above but in order to reach fast move cycles you still should limit it to a reasonable amount.

Best regards,

Jochen Klier
National Instruments Germany

[mrjimmy]

From reading the Set U32 VI help file, it seems that the pull in happens by default (3 pull in moves max, and to an accuracy of 1 stepper count, this second parapmeter being defined by pull-in window)

I don't expect any major loads, so I think I'll be able to leave this alone, and rely on the deafults to get me to within 1 count.  But of course, I am still curious, I assume that setting pull in window  to 0 stepper counts to assure max. accuracy has its drawbacks?  If so what are those?

Thanks

[AnalogKid2DigitalMan]

Drawbacks may be a long settling time to final position and continual hunting about the zero point.

What does 1 count relate to in terms of degrees of rotation? What is the pitch of the leadscrew? With these two numbers you can calculate the actual linear error resulting from 1 count.

Example: 1 count = .36 degrees. Pictch of screw is 10mm/rev.

(0.36deg) / (360deg per rev) = .001 of a revolution. (10mm/rev) * (0.001rev) = .01mm stage movement per 1 count. (=10 microns or about 1/5th the width of a human hair)

Note that mechanical 'slop' (stiction and backlash) in the the screw and nut of the stage may totally nullify 1 count of commanded movement. That is, it may not even move.

[Buechsenschuetz]

"2)I'm wondering if the closed loop mode is working correctly because even though I tell the stepper to move 1000 steps, it'll move 999 or 1001 on 1 out of 7 or so times. Is that because MAX isn't really working in closed loop mode?"

The problem might be the resolution of your encoder. If your encoder resolution is the same as (micro-)step resolution of the drive depending on the actual position of the drive the encoder might be just "on the edge" of one of the encoder lines engraved on the encoder disc. So sometimes the drive will make 999 steps and the encoder will count to 1000, sometimes the drive will make 1001 steps with 1000 encoder counts.

Usually it is recommended to use encoders which have at least 4x the (micro-)step resolution of the drive to be able to detect position with an error of 25 p.c. of a single drive (micro-)step.

BTW your problem also shows the limits of using micro-steps. If you select, for example, 10 micro-steps for a full step not all micro-steps will be equal. So depending on which of the micro-steps the drive comes to a stop the (precisely equidistant) encoder will count a few counts more or less than expected.