Problem synchronizing position encoders measurements using cDAQ 9174

[Kevin_Price]

Expanding the commentary for the sake of the original poster...

---

@JÞB wrote:

That said. Deserializing the reads is going to help a lot.  Especially if the encoders are operating at nearly the same speed.  ( Exactly in this case)  

---

Specifically, deserializing the reads will free up the loop to execute quicker, helping to reduce your chance of getting the -200279 buffer overflow error.  It wouldn't address the original problem of time lag between the data sets on the two encoder tasks.  Whether the reads occur serially or in parallel, the buffer contents that get returned would be the same.

The time lag problem is solved by a combo of arming the counters simultaneously (you need to control the timing of when the Arm Start Trigger is asserted), sampling simultaneously (you've already shared the same sample clock signal, you just needed the encoder tasks to be started before the sample clock signal task), and maintaining correlation of the data as you read it from the task buffers (you're already doing this right by reading the same # samples from both tasks).

   The trigger and clock are the key to establishing hardware sync.  Handling data from the reads properly just makes sure you don't mess up the sync after the fact.

   My own opinion is that in your particular situation, deserializing the reads may only be a relatively small help for loop speed.  The 1st of 2 serial reads may need to wait for all the data to be available, but once the data is returned and the 2nd read is free to execute, it's same # samples are sure to be available so there will be no extra waiting.  

   Now I primarily say that from a standpoint of experience with desktop plugin boards with low latency.   It's quite possible that the penalty imposed by the USB connection to your DAQ device makes serialized reads a bigger problem for a cDAQ device than I'd expect based on familiarity with desktop boards.

All that said, the example I posted earlier already *did* deserialize the reads so they are in fact free to execute in parallel.

-Kevin P

[Hassen13]

Hi,

Thank you guys, you are helping me a lot.

The problem of the buffer is now resolved. but I still have the delay between the encoders reading.

I am now creating the producer/consumer pattern. hope it will improve it.

you suggested also to control the generation of the Arm Start signal. I don't really know how to do that. could you, please, show me ways to do it ?

Hassen.

[Kevin_Price]

In your screenshot, it appeared you designated "Mod2/PFI4" as the Arm Start Trigger signal.  Where is that coming from?

What I would normally do on a desktop board is identify a PFI pin that also corresponds to a digital output pin.  Then I'd make a DO task that sets the output low before starting the encoder tasks.  After all the counter tasks are started, then I'd toggle the DO high and then back low to create a single triggering pulse.

The counter task wants to refer to the pin by its PFI number, you can't directly refer to it by its DO line number.  If the cDAQ doesn't have the same kind of overlap in pin assignments that I'm used to on desktop boards, you could just physically wire from a controllable DO line to an accessible PFI line.

-Kevin P

[Hassen13]

Hi,

At first I would like to thank you for all your help. I also would like to apologize for my absence all this time, I was out because of an emergency.

I improved my program by using a phisically wired DO line to the PFI7 as you suggested before. 

Now I don't have the constant delay between the encoders readings anymore. But it's working only for ''low frequencies'' (under 2MHz)

At first I thought that the problem is finally solved. but when i do my tests at a frequency of 2.5MHz or higher I get a delay growing in time. as shown in the results files and images (two tests made at a 3MHz frequency which is the least frequency I need to reach) , at first there is no delay but it's growing and becoming bigger and bigger during all the test. 

Could you tell me the reason of this behaviour at high frequencies. and how to correct that ?

Now I am implementing the producer/consumer pattern, hoping that it would emprove the results.

Please find enclosed the VI I am using, the configuration used, and two results files for two tests made at a 3MHz frequency and two images of those results.

I am open to all your suggestions.

Hassen.

[Kevin_Price]

I don't notice anything that looks wrong in the task setup.

To my eye, the data suggests a difference in *scaling* rather than "delay."  There's a very consistent and systematic difference in slope.  Since you don't seem to do any explicit scaling, I would suppose that the same default is being used for both tasks.  It wouldn't hurt to try some runs where your DAQmx Read functions read raw counts by selecting 1D U32 instead of 1D DBL.  I don't really expect that to be the problem, but it's nice to work from raw unprocessed data when troubleshooting.

I think it's more likely that the two encoders are correctly reporting position on two axes whose speeds aren't quite the same, even though you intend / expect them to be.  Can you describe your system and explain why you expect the two readings to agree?

-Kevin P

[Hassen13]

Hi,

As I said in my first post, the main purpose of my work is to read simultaniously and compare signals of two diffrent encoders.

I am using cDAQ-9174 on which is mounted two NI9401 DIO Modules.

To make sure of the sychronisation of my position encoders (ctr1 and ctr2) measurements. I duplicated a signal so that both encoders would have the exact same input in order to see if they are measuring the same.

To test if my VI is working correctly I am using an arbitrary function generator which generates two square signals with a phase shift of 90 deg. The first one is for the A input of the encoder and the other one for the B input of the encoder. I duplicated both signals using a ‘’T BNC’’ so that I have a total of four signals. The idea is to supply the encoders 1 and 2 with the same exact signal and see if they read the same.

As long as I didn't reach the synchronization I need, I will not be able to proceed to the measurements that I intend to do.

Hassen.

[Kevin_Price]

Ok, gotcha.  I thought maybe you were past the part of troubleshooting where both counters were being fed the same pair of signals and we were seeing a real speed difference between the two encoders.

At this point, I'd try reading raw 1D U32 counts instead of scaled 1D DBL position data.  Even though I don't *see* a reason why they'd scale differently, I don't have other strong suspects for the very consistent and systemic difference you're seeing.  If the raw counts show the same divergence over time, then at least we'll have ruled out scaling as a suspect.  

-Kevin P

[Kevin_Price]

Another thought:  you describe this as a problem that you observe at 2+ MHz.  Is there absolutely no problem at all when running at, say, 1 MHz?  100 kHz?    When running at various frequencies where the problem exists (2, 5, 10 MHz), does the discrepancy between the two counters seem more like a function of *time* or more like a function of encoder *counts*?

Try these things out while measuring raw 1D U32 counts.  Try plotting count difference vs. time and count difference vs. counts at the different encoder frequencies.  See if one of them is consistent across the different encoder freqs.

-Kevin P

[Hassen13]

Hi,

No, there is no problem at a 1MHz frequency or lower.

I will try your suggestions and let you know how it turns out.

Thank you very much.

Hassen.

[Kevin_Price]

Another thought:  what happens if you swap the end-point wiring at your terminals?  Does the issue move with the physical wires or does it stay with the counter?   (I'm assuming that problem has been consistent up til now -- one counter is always leading and the other is always lagging).

-Kevin P