USB 6210 Using counter as an external clock

[rose8]

I was referencing an old post for how to read and write data from a quadrature encoder. I am using a USB 6210 card along with Labview 8.2.1. In the previous post it describes needing to:

"You will have to create an external clock using the other counter on the board then route the signal either externally or internally"

I do not know what this means and I do not understand what is required to do such (Changes to wires, change the Vi...etc). If someone could please shed some light on this I would really appreciate it.

I am basing my approach on the following NI example:

Meas Angular Position-Buffered-Cont-Ext Clk.vi

[Kyle_A.]

Hi rose8,

The example you are referencing requires an external clock to basically take samples of the angular position based on time.  For instance, you can rotate your angular encoder all you want, but it will not save which position you are at until a sample clock rising edge is seen.  When the sample clock rising edge is seen, then it places that position into a buffer, and continues to wait for the next sample clock rising edge to happen.  Every time the rising edge happens, the position of your angular measurement is recorded one point at a time, stored in a 1D or 2D array. 

The sample clock cannot be an on board clock that is already created.  So now, we look at what sources we can use for our external clock to sample the position of our encoder and save it in our memory buffer.  We can use an external source and bring it into the board, or we can create a clock using another counter on the board.  Since you are looking to do this, I'll assume you want to create a clock from there.

In software, you specify two counter tasks; one to measure your angular position and one to generate a pulse train.  The pulse train you generate will be the sample clock for the buffered angular position measurements you are taking.  Now, you can route this externally or internally, based on your application.  The easiest way is internally, because it doesn't require any additional wires to accomplish.

To route internally, all you have to do is for your DAQmx Timing VI, specify CtrXInternalOutput from your USB 6210 as the source, where X is the counter you generate your pulse train on.  To see this source as an available selection, right click your Resource Name and select I/O Name Filtering from the shortcut menu, and then be sure that Include Advanced Terminals is checked. 

In programming, you would want to start your angular position task first, and then start your clock generation from your second counter.  They will run in parallel and just be sure to clear both threads at the end of your program.  Hopefully this clears up some confusion for you.

[rose8]

Attached is the quick VI I made to demonstrate what I am trying to do. I am reading a signal from a ttl rotary encoder, converting that signal to a voltage and outputing that to a CAN micro controller to control the position of the rotating arm. I understand that there are better ways of doing this, but I am working with what hardware I was given. My concern is that when I sample without continuous sampling as shown in the provided vi my sample times are not spaced at any regular interval and they are slower than the micro controller is sampling (5ms). I am under the impression that using the continuous sampling using a buffer and external clock will help me solve my problem. Is this a correct assumption? Is there a different/better approach to take with what I have been given.

Notes:

operating system: XP

Card used to read encoder: USB 6210

Card used to output analog voltage: PCI-6115

Labview: 8.2.1

[rose8]

I forgot to include an example of the output that I am currently getting from the sensor. The left column is what I am assuming is the time vector and the right column is the voltage that I want to output (more sig figs than I really need). What implies to me that I have a problem is the fact that some of the time elements repeat however, the corresponding outputs are different.

2.031276    0.711389
2.031276    0.726944
2.046901    0.740833
2.046901    0.752500
2.062526    0.761389
2.062526    0.768333
2.078152    0.774444
2.093777    0.780278
2.093777    0.786944
2.109402    0.794722
2.109402    0.802222
2.125027    0.809722
2.125027    0.816667
2.140652    0.823333
2.140652    0.830000
2.156278    0.838056
2.156278    0.847778
2.171903    0.858333
2.171903    0.868889
2.187528    0.8805

[Kyle_A.]

It seems like since you are needing 200 Hz or faster sampling in control loop fashion, it makes things a little more interesting to write to the buffer at hardware time, but read the values from that buffer at software time. The way you are going about it now seems to be better than hardware timing the counts if you plan on immediately using that feedback to control the arm.  Buffered measurements are good for testing, where the data just needs to be acquired and saved at high speeds.

Are you sure the right column isnt your time column and the left column is your position?  I ran your code and my times were all separate based on what time in software they were acquired.  What are your labels to your columns?  Also, if you want faster software times, using the DAQmx API over the DAQ Assistant will improve the efficiency of your code and give you better timing results.

[rose8]

Kyle,

Thank you for the feedback on the correct approach to take. With that now clear I have changed my VI to use the DAQmx API instead of the daq assistant. I don't really see a significant change in the timing of the results. Is there anything I can do to affect the timing or am I simply limited by the hardware and the execution of my code?

I made a mistake as I typed previously the left column is time and the other columns are the measured data. Side note I can't figure out how to use the set attribute blocks to change the names of the signals in the header. However, that is trivial compared to why the x_value (time) can repeat itself over and over and yet the other values don't stay the same for supposedly equal instants in time. Can you explain this to me (Bold selections are good example of what I am referencing)? The increments do seem somewhat regular they vary either 15ms between or 30ms between. Please let me know what you think and if there is a way to fix this weird duplication of times.

X_Value    Untitled    Untitled 1    Comment
0.000000    0.040000    0.001111
0.031250    2.200000    0.061111
0.031250    2.690000    0.074722
0.062500    4.970000    0.138056
0.062500    5.550000    0.154167
0.078126    6.140000    0.170556
0.078126    6.800000    0.188889
0.078126    7.370000    0.204722
0.093751    7.950000    0.220833
0.093751    8.560000    0.237778
0.093751    9.120000    0.253333

[Kyle_A.]

I don't think there is any standard to how the Write to Measurement File Express VI is assigning time to the signal.  There is technically no timing on the signal period, it is two columns of data arbitrarily being written to file.  So I believe the times in the X_value column are arbitrary and meaningless. 

What you can do is expand your combine signals VI and wire in the iteration terminal on the while loop to see how each sample corresponds to each iteration of the loop.  You can also custom create your timestamp with the Elapsed Time Express VI so you can guarentee the timing better. 

Going back to the timing of the code, the way you have it now should help with the overhead a lot.  It would be best to have the Write to Measurement File VI outside the loop and build an array of data if that is possible.  You also want to be sure you are merging errors on your two threads because if your AO ever errors out, your while loop will not stop with the current code. 

[rose8]

---

@Kyle A. wrote:

I don't think there is any standard to how the Write to Measurement File Express VI is assigning time to the signal.  There is technically no timing on the signal period, it is two columns of data arbitrarily being written to file.  So I believe the times in the X_value column are arbitrary and meaningless. 

What you can do is expand your combine signals VI and wire in the iteration terminal on the while loop to see how each sample corresponds to each iteration of the loop.  You can also custom create your timestamp with the Elapsed Time Express VI so you can guarentee the timing better. 

Going back to the timing of the code, the way you have it now should help with the overhead a lot.  It would be best to have the Write to Measurement File VI outside the loop and build an array of data if that is possible.  You also want to be sure you are merging errors on your two threads because if your AO ever errors out, your while loop will not stop with the current code. 

---

Kyle,

I did what you suggested with the elapsed time VI and the timing was the exact same as I demonstrated previously.  I also checked back in the documentation of the Write to Measurement VI and there it say that the x_value is time:

• One column only—Creates only one column for the time data the channels generate. This option includes only one column of values from the x-axis. Select this option if you acquire signals at the same acquisition rate.

Any other ideas as to why there are duplicate time stamps?

Jess

[Kyle_A.]

Hi Jess,

Another practice we can try is to add execution timing to the while loop, with the Wait Until Next ms Multiple.vi.  You can ensure the loop execution happens every X amount of milliseconds, so if you see the duplicate times after this there may be a software corruption on your machine.  I am still unable to produce duplicate timestamps on my machine.  It may be helpful to add in the iteration count to your measurement file to also verify what iterations are happening when you receive your duplicate timestamps.