Incorrect Direction at Lower Speeds

[JimSchwendeman]

Hey Everybody,

I have a new problem I've stumbled upon, and it definately has me a little confused.  I've checked the hardware in max and I can't seem to simulate this problem...

In my program, I can manually drive a motor (for a linear slide) while reading it's encoder.  If I drive the motor slow enough, I get erroneous position counts due to what I believe is a confusion on direction (i.e, it begins to go down in position (like for CCW), even the motor is turning CW and the position should be increasing).

I am using X4 for both sets of encoders, which are the standard A,B,I (though index is not currently being used).

Any thoughts?  I've checked the hardware in max and I can't seem to simulate this problem...

.jim

[hoffiz]

I would like to make sure I understand your issue, let’s first start from: when you say: “I've checked the hardware in max and I can't seem to simulate this problem” I guess that you are creating a “task” in MAX and testing just the counter input of your application and not that you are simulating a DAQ board to test the behavior of its counter.

I’ll be interested in knowing the result if you run; “Measure Angular Position.vi” example VI this way we can isolate the counter input from all the other task you have on your code. Is it the same for the “Slide” and the “Capstan”? Also what happens in your code if instead of doing x4 you try using x1 or X2?

I’m asking you to try this because X4 has a higher resolution of ticks but at the same time is more sensitive to vibrations and noise. Please see the picture attach found in the NI-DAQmx help.

Message Edited by Jaime F on 11-06-2007 03:46 PM

[JimSchwendeman]

Jaime,

Correct in that I created the task in MAX, no simulation.  I also tried using both X1 and X2.  The behavior still showed up, and it seemed like it might have been less, but it's hard to quantify as it's intermittant.  I ran the "Measure Angular Position.vi" example, and was able to see this same "position creep".

Here's a thought that did cross my mind, and could potentially be the cause of this:

The motor controllers that I'm using already close the loop around the encoders, i.e. they try to hold the motor at a certain encoder count, until you give them a step frequency, and direction.  (The are not PWM, think more along the lines of steppers, even though they are DC servos).  Could the fact that the motor is banging back and forth between a count or two be the cause of this behavior?  If so, is there any way to eliminate/minimize this behavior?  The controllers are hardcoded, so there's nothing I can do about the back and forth...

With regard to the encoders, would there be any improvement by enabling the Z-index?

I'm currently doing a quick rewire to minimize any possibility of crosstalk, etc.

I appreciate the help!

.jim

[hoffiz]

The back and forth movement of the motor can be the issue of the behavior only if you see this behavior when the motor is slowing down if you see it in any other situation I might be due to a different reason. Regarding using the Z-index I don think it will help since the Z-index is intended to reset the counter after a one revolution is completed. Re-wiring will be very useful in the case you have crosstalk, like you said, or noise in your Laboratory.

[hoffiz]

Can you confirm me if this is how your system is set, I will really appreciate as much help as you can give me since the more descriptive you are the easier for me to come up with a solution.

Also the back and forward should not be an issue if you are manually driving the motor in this case you are only going to be reading the encoders and the controller is isolated from the system. I’ll be very interested if you can to read the output of the encoder into an oscilloscope.

So when you slow down the motor the counter miss one count i.e. you are moving CW and the counts are 2,3,4,5, (slow CW speed) 4,5,6,7 or it completely changes the direction of the counts i.e. you are moving CW 2,3,4,5,(slow CW speed) 4,3,2,1?

[JimSchwendeman]

Jaime,

I attached a picture of how the system is setup.  The controller, encoder, and 6602 share a common ground, A, and B.  The connections between just the 6602 and the controller are +5v, direction, and step.  All of these signals are currently being sent down cat5 cable to the 6602.

It's important to note that the 5v for the encoder is generated by the motor controller, and that the +5v for the encoder is NOT common with the +5v between the 6602 and the motor controller.

.jim

[Kevin_Price]

You say that the +5V for the encoder is NOT common with the 6602.  Do you mean that you haven't connected the encoder's digital ground back to the 6602's terminal block?  If so, perhaps the encoder outputs are floating relative to the 6602.  If, for example, it floats 1 or 2 volts above the 6602, then the low states are in the TTL "indeterminate" zone and can produce erratic behavior.

Another similar question -- is the encoder giving you differential outputs, i.e., +A,-A,  +B,-B,  +Z,-Z?    I've seen funky encoder behavior before if the (-) side of a differential output is hooked up to a 6602 DGND pin, as though it were a common single-ended ground reference.  The differential output "wants" that (-) side to float while your connection from DGND to the controller wants it not to.  Result: conflict, possibly including encoder states that are TTL-indeterminate.

I'm not an EE by training.  This is just a seat-of-the-pants description from experience.  But one general rule is that if the encoder puts out differential, you should convert to TTL before wiring to the 6602's terminal block.  One possible device (which includes screw-terminal convenience) is here.

One more shot in the dark -- what kind of encoder does the motor have?  Is it optical (shouldn't require a minimum speed)?  Or is it based on Hall effect or magnetic field sensing (may require minimum speed)?

-Kevin P. 

[JimSchwendeman]

Kevin,

All good questions:

The motor controller generates the 5 volt supply for the encoder.  The encoder ground, A, and B channels are common between the controller and the 6602.  (All I meant to say was the the 6602 was not providing the supply voltage for the encoder).  No floating outputs as far as I can tell.

One of the encoders does provide differential outputs, the other just provides relative.  Coincidently, the encoder that seems to be having a more noticable problem with this jitter is the one that has differential.  It also has a lower number of counts per rev.  All the negative outputs are disconnected/floating.

Both encoders are optical.  One is 500 (2000 quad) the other is 250 (1000).

Interestingly enough, when I put the scope on pin A, the jitter seemed to stop for a while, which makes me suspect wiring.  Perhaps all shielded twisted pairs is the way to go?

.jim

[hoffiz]

Some information I have found to reduce noise is to carefully separate motor and all power wires away from encoder wires. Always separate the channels from each other. All encoder wire "should" be shielded and carefully terminated.

Is it possible for you to disconnect the controller from the encoder?, break the loop, to test the read counter by manually driving the motor?  I’m wondering if you are driving the counters on the 6602 with enough current (from the specs min 10uA and max 200uA.

I hope it helps.

[Kevin_Price]

...the encoder that seems to be having a more noticable problem with this jitter is the one that has differential...    All the negative outputs are disconnected/floating.

This sounds like an area to investigate further.  There's some possibility that the stuff I was talking about may be hurting you here.

The purpose of the differential output is that the +A and -A are *both* allowed to float relative to your overall digital ground shared by the 6602 and the controller.  When they both float, then common-mode noise is induced on both to the same degree simultaneously, but the signals maintain the correct ~5V *difference*.  When compared to true digital ground however, they may measure out at 6.5V and 1.5V.

If you wire just the +A, +B signals up, and they are pulsetrains that transition between 1.5 and 6.5V relative to the 6602 digital ground, you could expect indeterminate behavior.  If the encoder's logic low state comes in at 1.5V, you can't know how the 6602's TTL circuit will respond.

A "line receiver" or differential-to-ttl circuit should be used to convert back to TTL near the 6602 terminal block.

-Kevin P.