Problem synchronizing position encoders measurements using cDAQ 9174

[Hassen13]

Hi,

Thank you very much. As always your help is very precious. I am making big progress thanks to you.

I was applying your suggestions. But, by mistake, I swap the A and B channels of the encoders instead of swapping the end-point wiring at the terminals. and I got better results (''results 1'') even though i can't explain why. I dont have the delay anymore but i still got a jump shown in the graph ''difference 1''. for that I used the VI ''synch_count 1''

 To get rid of that jump i applied the producer consumer pattern in th VI ''synch_count 2'' hoping that it would resolve the problem. Unfortunately it got worse (''results 2''). now i get many small jumps that create big differences between the two counts of the channels as shown in ''differences 2''.
for all the tests I used the configuration shown in the ''config'' image. I also tried tests at a higher sampling ferquency (500kHz) and i got the same results.

My questions are :
1. could you explain the fact that it got better when inverting the A and B channels of the encoders ?
2. Am I applying the producer consumer pattern appropriately ?
3. could you explain those jumps I am getting in the results 1 and 2 and is there a way to get rid of them ?

Hassen
 

[BrandonC1]

Hassen,

Did you make sure to respond to Kevin's last message? Since it's been a while since you guys last spoke on this thread I want to make sure he was notified you are revisiting this topic!

Thank You,

Brandon 

Applications Engineer 

[Kevin_Price]

1. No, I can't think of any plausible reason why swapping A & B should give better results.  In an encoder task, all that should do is reverse the apparent direction of motion.

2. The producer / consumer method looks essentially correct, but I'd tweak a couple things to allow the DAQmx loop to have max performance.

• bundle the two 1D arrays into a cluster instead of making a 2D array.  Let the cluster of two 1D arrays be the queue datatype.  (It'd be a good practice to make this a typedef.)
• move the GUI array indicator terminals out of the producer loop and into the consumer loop
• it'd be a good idea to terminate the loop on a DAQmx error

3. I have no specific theory about the "jumps", but the graph that shows them looks like it comes from a post-processing Matlab script.  I don't know your scaling and from where I sit, it isn't even certain that the data capture in LabVIEW is where the problem is.  There could be a bug in your Matlab script for example.

That said, I *STILL* advocate that you try reading 1D U32 data from the tasks.  I don't think you'll also need to specify Units==Ticks when you create the task, but it wouldn't hurt. 

The reason I keep suggesting this is that I've had a less-than-stellar experiences using the built-in scaling options for position encoders.  Maybe everything's fine now, but I felt burned by it long ago and generally stick stick with reading raw counts and doing my own scaling.  Raw counts are extremely transparent, and transparency is a great aid in troubleshooting.

-Kevin P

[Hassen13]

Hi,
Thanks a lot for your help.
I applied all your suggestions except terminating the loop on a DAQmx error because i don't know what you meant by that.
I still get the same results.
I double checked my post-processing Matlab script and I verified the graphs and the result files and they perfectly coincide. the graph shows perfectly the counts in the result file. So there is no problem with the matlab script.
In the first graph I just plot both encoders counts.
In the second one I plot the diffrence between the encoders counts at each point.

Is there any other suggestion I could try to improve my results ?

Hassen.

[Kevin_Price]

No specific new ideas.   However, I need to get clear on a little context.

In msg #14, you thought all was fine below ~2 MHz and issues only arose at higher frequencies.  In msg #21, you seem to describe issues at 500 kHz and lower.

I also am not even sure what "frequency" you're referring to.  Is it the sample rate?   The encoder pulse rate?  Something else?

I don't know the cDAQ platform all that well.  If problems are only present for higher frequencies, it may be a hardware limitation.  The limitation could be either on the cDAQ side or in your source signals.  Perhaps signal integrity degrades at high frequencies?

As stated before, the code looks pretty solid, I don't see a reason there for the kinds of things you're observing.  I think you need to experiment carefully with different sample rates, different encoder rates, cleaner source signals and try to figure out where your crossover points are between correct and troublesome behavior.  Get some clarity on which changes your system is and isn't sensitive to.

-Kevin P

[Hassen13]

Hi,

sorry for not beeing clear enough about the frequencies. 

In msg #14 I meant the source signals frequency that needs to reach at least 3MHz (The frequency of my measuring device signal).

In msg #21 I meant the sample rate. Until then I was always using a 100kHz sample rate. But I tried tests at higher samling rate (500kHz) to see if that would emprove the results or have any effect on them.

Even if signal integrity degrades at high frequencies, both encoders should read the same, because all I did is, duplicate  that signal so that both encoders would have the exact same input in order to see if they are measuring the same. I think that the limitation is on the cDAQ side.

I will try the experiments you suggested and let you know.

Thank you very much Kevin. You help is very precious for me.

Hassen.