Adding an encodeur to existing application

[CHAJ]

Hi,

I'm back with a new topic. I would like to add an encoder to my previous application using the same time base. My goal is to Compare the speed of the two encodeur. (crank/cam)

Of course encodeur counter IN is the external clock for the analogic aquisition.

What do you think about?

I'm using multifiction PCI6251 card right now.

[Kevin_Price]

The code you posted looks like a very slight modification of what I posted for you in an earlier thread a couple years ago.   Heed the warning I gave in that post about the subtle difference between X-series (63xx) and M-series (62xx) boards when it comes to period measurement.  Your code isn't quite exactly right for either one.

Difficulties arise when you try to sync up another counter task set for period measurement because its measurements will *not* be in sync with the ones you're getting now from your first counter and AI task.  It will have measurement timing that comes from its own encoder's varying speed, and that *won't* be the same as the first counter.

You will have to do further careful post-processing to correlate all your data.  The configuration of the 2nd counter can look largely similar to the 1st.  It should use the same signal for its "Arm Start trigger" to insure the same t=0 point for all 3 tasks.  But after that, you'll need to separately accumulate all the interval times for both tasks.  The correct "timestamp" to associate with each period sample corresponds to the cumulative sum of *all* the periods from the start of the task until the sample in question.

    Note: this is one of the very few situations where your present M-series device is a better choice than the newer X-series, as referenced in the thread I linked.  The first sample from an M-series period measurement task gives you the time from the task being armed until the first edge arrives.  With an Arm Start trigger configured, that'll be the time from the trigger being asserted until the period signal first asserts.  Then the second sample measures the first *full* interval.

    On an X-series device, that initial partial interval is discarded so you never know how long it was from arming until the first edge.  All you get to retrieve is the duration of all the complete intervals.  This also means that an AI task sampling off the same signal will produce 1 more sample than the counter period task.

    I'll look for some time over the weekend to do a further mod of the code.

-Kevin P

[Kevin_Price]

It isn't fully polished and complete, and I wasn't able to test it on anything, but this should at least give you a real good head start.

Of note:  I've merely accumulated the periods and the timestamps for when those samples were captured.  They'll be different for each counter task.  There's still work to do to further correlate them.  They *will* be referenced to the same t=0 point, but you'll need to do some interpolation to estimate values at the same instants.

Also, I left everything out there in the raw on "One Big Diagram."  I thought it would be helpful to have everything visible at once until you understand it, then there'll be a lot of opportunity to neaten it up with subvi's.

-Kevin P

[CHAJ]

Hi Kevin,

Nice to see you again! I going to built the hardware and will let you now, as soon as I get result.

Best Regards,Julien

[CHAJ]

Hi everybody,

Sorry to not having the opportunity to test before. Kevin the code is not providing exactly what I expect.

I would like acquisition of 10 rev (10x360) or 3600 samples of counter A

Material Description:

• Counter A 360 slits/per rev + 1 long slit for trigger (Counter A & AI starts)

• Counter B 4096 slits/per rev

• AI external clock -->counter A

Expected result (almost with no torsion in the transmission shaft):

[Kevin_Price]

Can you describe things in more detail?   What have you already done to probe for errors or other debug / troubleshooting steps?

Are you using some version of the example I posted back in msg #3?  What changes have you made?  Can you post the latest code with typical values for controls and indicators saved as defaults?  

Most of the general behavior of the 2 graphs look about right -- a similar slope for both counters (indicating similar constant speeds), with many more sample points for the higher-res encoder.  The main thing that jumps out are the initial multiple counter B samples at the same x-axis time.  (I also suspect your time scale should be seconds rather than msec).

-Kevin P

[CHAJ]

Hi,

I modified the code in order to get some values.

AI is a signal wich happened once a time per rev of each counter. (counter A 360 slits/rev)

Best regards,

Julien

[Kevin_Price]

I made just a very few small mods, highlighted with turquoise comments.  The important ones are:

1. Reverted to my original method for reading Ctr B.  (Requesting # samples = -1, which means "all available" b/c we won't know exactly how many to expect every iteration)

2. Reverted to my original method for accumulating AI data.  Your method wasn't working b/c your outer shift register was initialized as any empty array and trying to replace non-existing elements in an empty array leaves you with the same empty array.

-Kevin P

[CHAJ]

Hi Kevin,

Tested, but can't really understand why error occurs at sample #1000 for 3600 requested (10 rev of encoder A).

The errors text is in the code.

Many thanks,

Julien

[Kevin_Price]

Oops, I missed another change you made back in the task config region.  You changed Ctr A to Finite sampling instead of Continuous like the other two tasks.  Set it back to Continuous and you won't get that error any more.  (Compare with my original example back in msg #3.)

    The reason you get 1000 samples is because you didn't wire in a value to the 'samples per channel' terminal in your call to DAQmx Timing.   When left unwired in Finite sampling mode, 1000 is the default value.

    It works very differently for Continuous sampling.  When left unwired in Continuous mode, the default behavior is for DAQmx to auto-size a buffer for you according to your sample rate.  In your specific case where sampling comes from an external signal whose timing DAQmx can't known, DAQmx will use whatever value you wire as the claimed sample rate.  It also uses it to set the dt value of your AI waveforms, so eventually you'll probably want to plot AI data vs. Ctr A times on an XY Graph in order to have a correct time scale.

-Kevin P