LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TDMS time channel (irregular time interval)

Hi,

 

I'm currently using a PCI 6251, externally clocked with a rotary type shaft encoder to acquire Incylinder Pressure data from an internal combustion engine. The engine rotates to a maximum of 3500RPM, and the shaft encoder generates 3600ppr. Thus, the frequency of acquisition is 210kHz. As a VI I'm currently using the one attached.

 

Now the issue is that I want to log the instantaneous time with every datapoint of Incylinder Pressure. Since sampling is external, the rate of sampling is not really a constant, it fluctuates by +-100RPM, thus the time interval is not a constant as well.

 

How should I go about to include the time in seconds, for each datapoint in the TDMS file ? In the VI I'm attaching I tried to use the "get waveform time array", but it seems that it is valid only for a constant dt.

 

Thanks in Advance

0 Kudos
Message 1 of 6
(3,202 Views)

Hi BCar,

 

In order for you to receive the best support, in the future you should post questions like this in the Multifunction DAQ Forums. 

 

Nevertheless, you are correct in thinking that the waveform datatype expects a constant dt value, which won't work in this case. One option that may work for your situation would be to do something like the following:

  1. Connect the encoder in parallel to one of the digital inputs on your device. 
  2. In a separate loop in your code, configure a task to read one counter pulse at a time.
  3. Each time a pulse is counted, get a timestamp and add it to an array
  4. Each timestamp in the array should correspond to an analog data point as long as the tasks are synchronized. Thus, you could write this as a separate column to the TDMS file.

For a small example of this, see this forum post.

 

Since there is time involved in the transfer of the data from the device to the execution of your code, this won't be quite accurate to the moment that the data was sampled. However, since it sounds like you are looking for an accuracy of seconds, this would likely be fine.

 

Regards,

Regards,

Michael Whitten
Senior RF Applications Engineer
0 Kudos
Message 2 of 6
(3,145 Views)

A better way to get a full set of precise timestamps would go like this:

 

1. Configure a counter task for period measurement.  Use DAQmx Timing to make it a buffered measurement.

   This measurement will give you the time interval between each encoder pulse.  A cumulative sum of these intervals will be your overall time array.

2. Configure your AI task for a Start Trigger.  Configure the counter task to use the same signal as an Arm Start Trigger -- you'll need to use a DAQmx Trigger property node to do this.  This step syncs the tasks so that reading #N from AI is taken at the end of interval #N of the counter task.

   Small note: the very first counter interval tells you the time from the arm-start trigger until the 1st encoder edge.  It isn't a full interval, but that's ok, it's what you actually want.  (NI does not return this value on X-series devices, an ill-considered design decision IMHO.) 

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 6
(3,137 Views)

Hi,

 

Thanks for your comment. I thought about your idea and attached is the modified code. I'm not sure what you meant by synchronisation of tasks. Is this what you had in mind ?

 

Thanks,

0 Kudos
Message 4 of 6
(3,124 Views)

Hi Kevin,

 

Thanks for your comment. I tried also to implement your idea in my code. Attached is the modified code. I've never used arm trigger before. Can you please explain in simple terms whats its function exactly ? And did I implement it correctly in the coding ?

 

Thanks,

Carl

0 Kudos
Message 5 of 6
(3,123 Views)

I don't have time to fully rework your code, can only drop a few hints that hopefully move you closer.

 

1. search for other help/examples on the Arm Start trigger.  You need to define other properties too, like Trigger Type.

2. carry your error clusters around so you can know when they happen

3. your TDMS file reference causes dataflow sequencing between the Analog and Counter loops such that the Analog loop must terminate before the Counter loop can start.  I doubt that'll be the right approach, but don't have time to try to fully digest the code to comment more definitively.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 6
(3,085 Views)