Get external clock properties

[CHAJ]

Many thanks Kevin,

I modified the sample VI , I found with one while loop instead of 2. Is it still correct?

If yes, I can implement easily. (I think...) 🙂

With best regards,

Julien

[Kevin_Price]

The vi you posted was a pretty good start, but not quite all the way right.  I made several (mostly small) mods and added some comments in place to explain a bit.

One other thing of note: you seem to be using an X-series board which has a slightly different behavior for period measurement than prior generations of boards.  Not just different, but in this case, definitely WORSE.

With prior generations, the 1st period measurement would occur on the 1st edge.  It was *often* but not *always* meaningless.  For example, when the period task was arm-start triggered, the 1st period measurement would tell the time from trigger to 1st edge, which can be meaningful.

That's your situation.  But with the newer X-series, the first measurement value you get only tells you the time from 1st edge to 2nd edge.  You have no way of knowing how much time there was from the trigger until the 1st edge. 

This is an issue you'll have to deal with when you try to correlate the time information from the period measurement task to the sample #'s from the AI task.

Note also that you'll need to adapt the attached code to *accumulate* the data from the tasks.  Presently, each loop iteration overwrites the data from the previous iteration.

-Kevin P

-Kevin P

With X-series, the 1st period measurement occurs on the 2nd edge and gives you the full period of time from 1st edge to 2nd.

[CHAJ]

Hello Kevin,

Many thanks for your effort but still got some issues. I'm still using the USB 6361 BNC

Let me describe: on 99% of case the counter wont read samples. no error code juste nothing appears on the screen, and [] on probe.

Luckily, it start once and i did a data capture. I did a rough analysis on the data. I can say that, it's 110 degree/data late.

I joined the file from data capture and adapted VI. On the xlsx file in orange you have the offset.

BR,

Julien

[CHAJ]

Here, the data aquisition is done with the "same" or "adapted" code to the whole program.

the offset is 80 deg. This is a random value depending from start. (could be 27 or 65!)

Orange gragh is the rpm from "period measurement" and blue is RPM read into the derivative from valve lift form AI input.

the graph pattern is ok. of course when velocity from valve is "0" no RPM.

BR julien

[Kevin_Price]

Sorry, I just don't understand what you're trying to tell me.  The posted code neither accumulates nor saves data, so I have literally *no idea* what other code and processing is involved on the way to producing the attached spreadsheet files.

The DAQmx config looks correct to me for making sure both tasks trigger and start at the same time.  What you do with the data after that is entirely unclear.

What "offset" varies from run to run?  How do you calculate it?  What are you doing to match up distinct timing info from the 2 tasks?   The AI task samples at a constant rate while the Counter period samples at a variable rate that isn't inherently related to the AI task -- it could be much higher, much lower, whatever.

-Kevin P

[CHAJ]

Dear Kevin,

I simply use the right click on the graph and “export data through excel”.

On the AI task I have the valve lift ai0 and speed ai1. With 3600 samples I have 10 rev. With my PFI12 I have 360° per rev. the encoder disc is directly linked on to the camshaft.

I have one trigger per rev on PFI 13. (see drawing in attached document)

Thanks to a bit of calculation, I can see the camshaft RPM  into the valve speed.

With the period count I can calculate the RPM between each degree.

Each time the pattern of the acyclism is correct but not phased between AI task and counter.

I still want to solve a “simple” problem. What is the time between each measurement/sample one the orange or blue curve, with PFI 12 as external counter

BR,

Julien

[CHAJ · Accepted solution]

Dear Kevin,

It works!

I switched the number of sample from "all available " to AI sample number.

It's exactly what i was looking for.

Many thanks for your great Help.

[Kevin_Price · Accepted solution]

Glad you got it!   Sorry for my mistake - I somehow lost track of the fact that the same signal PFI12 would cause both tasks to end up sampling in sync, thus making it *appropriate* to read the same # samples from both tasks.

(It's more typical for an AI to run from a constant clock while period measurement would be variable.  Then it *would* be important to read "all available" and do some post-processing to correlate the sample times.)

Meanwhile, you might still have an "off-by-1" issue in the datasets, due to the issue I linked to in msg #12.  On your X-series device, the first period measurement sample represents the interval from the 1st to 2nd active edge on PFI 12, and that measurement is taken at the time of the 2nd edge.

   That will correspond to your 2nd AI sample.  But if you calculate your RPM from your AI data by doing a backward finite difference, such that your first calculated result also comes at the time of the 2nd edge, then you've got one of those fortunate situations where 2 negatives make a positive.  Both things shift your data by 1 sample interval, but potentially, both in the same direction to keep things in sync.

-Kevin P

[CHAJ]

Hi Kevin, and readers,

I would like to add another counter device same as the first one.

This in order to compare the speed between to shafts in the same system.

What set up do you recommend as the current VI is working well?

I still want to use the clock of the first counter for sample clock.

Any Ideas?

With best regards,

Julien

[Kevin_Price]

Just create another period measurement task for that other counter, and configure it in exactly the same way as the first period measurement task.  Including the use of Implicit Timing and specifying the AI sample clock as CI.Period.Terminal.

-Kevin P