Analogue input and timestamped digital change detection

[Kingsley Reavell]

I have an application in engine testing where I need to log a both digital and analogue data and I need both time and an engine location counter. I have a DAQCard AI-16XE-50 which I could use, but I'm happy to buy a new card if necessary (probably an M-series). I would very much prefer a single card solution as we want to recommend this system to our customers, and do not want to have to support the cost and complexity of a multicard installation.

The requirement is this:

I want to log 4 analogue inputs (from a gas analyser) at around 5 kS/s each. I have a pulse coming from a shaft encoder every degree of engine rotation (1 - 120kHz). I would like to count these pulses (giving engine position) and then store this engine position with each analogue sample.

In addition, I have 10 digital signals (valves open/closed) changes in which I wish to log accurate to 1 microsecond. Each valve only opens once per engine rotation, and I would prefer to log just the time and engine postion at which they changed state in a file. I could alternatively log the valve pattern and clock time at every degree pulse, but this would make a very large file.

I think I can achieve this two ways if I buy an M series card:
Option 1. I'll use the degree signal to trigger DI of my valve states: I think I can do this with the triggered/correlated DIO capability of an M-series card, but not with my E-series?

Analogue channels will be scanned at about 5 kS/s. Counter 1 input will come from the degree pulse, with the analogue startscan signal going to gate/enable. Using the 'count buffered edges' ability I can store the engine location every time I take an analogue scan.

I'll run counter 2 on the internal timebase and take the degree pulse to the gate/enable and thus log the time for each degree pulse.

In labview, I will test for changes in the digital inputs between samples, and store to file only those when there is a change.

I think this solution should work, but I'm worried the datarate is high for labview (I have to test the digital inputs at 120kHz).

Option 2. I can reduce the data rate if I create externally a pulse every time any of my digital inputs change. I will use this pulse to directly trigger acquisition of the DIs and OR it (probably externally) with the startscan signal into counter 1 to record the engine position at both analogue samples and valve position changes.

I'll also use this change signal to trigger the storing of the state of counter 2 to record the time when the valves changed.

This option reduces the DI data rate, although it requires a bit of labview to untangle the mixed engine position stores. It also needs a bit of external hardware.


Can anybody comment on whether either of these solutions should work? I'm thinking a PCI-6220 might do this, although if possible a USB one would be more convenient, if the data transfer's fast enough.

thanks

Kingsley Reavell

[Kevin_Price]

An M-series board can already do the digital change detection you want -- no need for external hardware.  The lower-cost M-series boards provide only an 8-bit port for hardware-timed DIO, so you'll need to bump up to one of the ones with a 32-bit hw-timed port.

When you perform a change-detection based acquisition on your DIO, there's an internal signal with a name like "ChangeDetect Pulse" which can be used as a sampling clock for other tasks.

The problem I see is your desire to sample position on each analog sample & on each digital change, while also timestamping each degree pulse (presumably for speed variation measurements?).  That would sorta imply using 3 counters but the M-series boards provide only 2.  The simplest-looking workaround would be an external circuit to OR the analog startscan pulse with the digital change detect pulse (assuming it can be routed out to an external pin -- it probably can).  But I think you'll end up with some timing issues there where the two pulses might overlap such that two overlapping input pulses only lead to 1 extra-long output sampling pulse.  That'll cause your data to get out of sync.

Let's break this down:

1. To store correlated valve state and engine position, you'll do change detection on 10 digital inputs.  On each transition, you'll sample your 10 valve states.  You'll also have a counter task counting encoder pulses that'll be sampled on each change detect pulse.  This gives you correlation between valves and position.

2. You can then set up a constant-rate analog task.  You'd also have another counter task counting encoder pulses that'll be sampled on each analog sample clock.  This gives you correlation between your gas sensors and position.  It will also give you some engine speed information.  The position difference over a constant sample interval would be the average engine speed for that interval.

3. (alternative to #2)  If it's more important to timestamp individual encoder edges to give you more precision in your speed measurement, then you can set up your second counter as your described.  You would then need to use the encoder pulses to drive your analog sampling.  The simplest is to sample on each encoder edge.  It should also be possible to divide the encoder pulsetrain down by any integer >= 4; this would give you fewer analog samples than position timestamps.  This type of scheme will give you analog samples at specific engine positions rather than at specific time intervals.

4. For any scheme, you'll need to plan on sync'ing the acquisition start times, probably to some specific 1-per-rev signal like one of the valves.  The analog and digital tasks would call this a Digital Start Trigger using the standard DAQmx Trigger vi.  The counter input task needs to configure that signal as a digital "Arm Start" trigger, which is only available through the DAQmx Trigger property node.

It looks like there are a few tradeoffs to make in order to do this with a single board, but it seems you can probably get there in the end.  It appears to me that the 6224 is the cheapest plugin board with >8 bits hw-timed DIO, but you should talk to your NI rep to be sure.

-Kevin P.

[Kingsley Reavell]

Thanks for your advice. It's sounding pretty encouraging. I think the fact that the degree pulses can be slower or faster than the desired analogue sampling might rule out a few implementations.

I'll take a few days to digest it and will have a chat with our rep, but I think it's just boiling down to which M series card I need now.

thanks

Kingsley