Incorrect Direction at Lower Speeds

[JimSchwendeman]

Kevin,

Cool!  I will definately give this a whirl and see how it goes.  I have replaced ALL wiring with shielded twisted pairs, so I'm confident that there's minimal/no crosstalk.

Thanks!

To All,

I really appreciate the advice!

.jim

[JimSchwendeman]

Kevin,

So a couple of new updates:  The encoder output isn't differential, rather complementary (when A+ = 5v, A- = 0v, not -5v). 

Both ranges go between 0-5 volts relative to the digital ground, so it's not a threshold issue, as far as I can tell...  Is the differential-to-ttl circuit still potentially the way to go?

.jim

[Kevin_Price]

There are a variety of different kinds of differential.  RS-422 is one kind which puts out +A and -A that have a difference of only ~5V.  The key factor is that those outputs aren't strictly referenced to a common digital ground.  So even if you've got +A measuring at 5V and -A at 0V, they may still be differential.  Any encoder I've encountered that brought out separate -A, -B, -Z signals were generating differential outputs.  The spec sheet should clear up any question. 

If indeed the outputs are differential, it'd definitely be a good idea to convert to TTL for the 6602 board.  However, given your observations, I'm not sure it'll fix your immediate problem -- it may just help prevent some future ones.    For the long run, you're going to want the electrical interface to be right.  The device I linked earlier in the thread is specific for converting RS-422 to TTL.  You'll need to make sure the converter you pick is the right kind for your encoder signals. 

My past experience where I had a big problem with thresholds from differential signals was one where there were 2 independent sources of differential coming into my counter board.  Wiring either encoder individually tended to work quite well.  But when the two independent A- signals were each tied to the 6602's common ground, then I was setting up a fight.  For troubleshooting purposes, try unwiring all but one differential source at a time.  Technically, I'm not certain whether "one differential source" should be interpreted as "1 channel from 1 encoder" or "all 3 channels from 1 encoder".  My own experience showed good behavior with all 3 channels from 1 encoder at a time.

(I'm using the term "differential" in its common industrial usage.  It's quite possible that "complementary" is more technically accurate, just not a term I've happened to encounter.   I just briefly Googled some info and it appears that with complementary outputs the *difference* between +A and -A changes from +5V to -5V whereas with RS-422 differential it changes from +5V to 0V.  I could easily imagine this causing a problem when wired direct to TTL, though the speed dependence remains a puzzle.)

-Kevin P.

[JimSchwendeman]

Kevin,

This one keeps getting stranger and stranger (I hope that means I'm closer to a solution :)).  Circuitry is in place to verify that the signals from the differential encoder A,B,A-,B- to the PCI-6602 are in the appropriate range/values relative to digital ground.

After some extensive scoping, I've verified this discovery:  The motor controller causes the motor to dither back and forth at the current encoder position.  When we scope channels A and B, we see that when the motor is dithering around a channel A position we don't see any drift.  However, when the motor is dithering around a channel B position, we get our slow positive drift!  This seems to be very repeatable, too.

Would this be a software issue in the Labview encoder counting subroutine?  We've tried to use X1 and X2 with little improvement...

Any thoughts?

Thanks!

.jim

[hoffiz]

If it is an issue with the LabVIEW counting subroutine, we can try to reproduce it by manually driving the motor, like you did on your first post, and try it with this example code:  “Measure Angular Position.vi” what I would like to do is to isolate “angular encoder” task from other tasks you have in your code.  I replicated your issue by manually driving an encoder very slowly and everything worked fine, even though simulate the back and forth movement of the motor and I do understand there are some differences with your setup and mine but is the closest I can get to your system. 

If it works we can try running the previous VI at the same time with “gen pulse train change freq”, I’m not really sure how your motor should be controlled (I guess is PWM) but this is a counter output code in which you can change the freq on the fly you might just need to adapt it a little bit to your code.

After an extensive conversation with one of our Motion Control teams since I’m leaning towards one of two either a problem with the encoder no changing the phase when it jitter back and forth; we can check this if you read A and B at the same time, or the way the loop control is been coded in LabVIEW. My colleague also advise me that you might be interested in a Low-Cost 2-Axis Stepper Motor Controller and I know you probably have already have everything setup but this might help for future references.

Message Edited by Jaime F on 11-19-2007 01:29 PM