Data Acquisition over Crank angle with two trigger signals

[SebiMIT]

Hi,

I am trying to aquire data over time and degree crank angle of an engine. The device I am using is PXI-6251 and LabView 7.1 (it is running on an old system).

I have two digital trigger inputs. One that happens every 720 degrees (or 2 revolutions) (PFI1) and one that happens every 1 degree of crank angle (PFI5). I am using the DAQ assistant to configure the measruement device. I am collecting N samples of data (set to 719) and triggering with a start trigger every 720 degrees and an external sample clock, which is given by the trigger signal every degree of crank angle.

Now there are three problems I have with this approach:

1. The DAQ assistant is placed inside of a while loop and the loop time is approximately double that of two revolutions, therefore I assume every other cycle to be recorded and not every cycle. I want to change that to every cycle being recorded instead.
2. The time channel in the measurement file does not make sense. The delta_t is given by the specified frequency in the DAQ Assistant, although data is being aquired according to a much slower external sample clock. I would like to have the real time displayed as the x_channel.
3. In addition to the time as the x_channel, I would like to have the angle degree in the measurement file. 

I am not sure how to achieve this and have been reading into DAQmx for the last couple days, but have not found any solution.

Attached I have screenshots of the DAQ Assistant, for easier understanding of my configuration. Any help is greatly appreciated.

Sebastian

[SebiMIT]

This is the VI generated by the DAQ Assistant.

[mikeporter]

I can't look at the VI right now, so I'll talk about some logical errors you are making.

First, don't use the waveform datatype. The timing information in the waveform assumes there is timing information -- and there is not. You are clocking externally with a signal coming from the end of the crankshaft. The problem is that the crankshaft does not run at a constant rate. You didn't say what the crankshaft is in, but the torsional forces from the cylinders means that from one degree of rotation to the next, the shaft will be constantly slowing down and speeding up.

Second, why are you only collecting 719 samples? You get 720 right?

Third, if it is not already, you need to be sure that the once every two rotations clock is referenced to some known datum, like TDC of cylinder 1. Do that, and the angle will be the same as the sample number.

Fourth, if you want real time you will need to measure it by connecting the once per degree signal to an interval counter. That data will give you a reference to real time and (given a little math) allow you to observe how much the RPM is varying by calculating the instantaneous RPM.

As I recall, you take the reciprocal of the frequency of the clock driving the interval counter and multiply that by the number of counts for each interval. This will give you the time the shaft needed to turn each degree of rotation.

Multiply those values by 360. This will be how long it would have taken the shaft to compete one revolution at that rotational speed.

The reciprocal of that number gives you the instantaneous crank speeds in Revolutions per Second, and dividing by 60 gives you instantaneous speed in RPM.

Mike...

[SebiMIT]

Hi,

I don't need the speed information. I am already calculating that in a FPGA, which I use for controlling the engine. And yes the one trigger is the intake TDC of the cylinder (it is a one cylinder engine) and therefore it occurs every 720 degrees.

The only thing I need the DAQ to do is capture my measurement signals like cylinder pressure and display/save it over time and crankangle. Therefore the measurement should always be triggered by the TDC and then record 720 samples according to the second external trigger given every crankangle. And then as soon as the TDC signal arrives again do the same thing all over again. 

[Kevin_Price]

I agree with all 4 of mikporter's comments and will just expand a bit.

I looked briefly at the DAQ Assistant code and would say you can probably keep about 2/3 of it.  Here's some changes I would make:

1. set this up as a continuous acquisition.  At present, I'm pretty sure you're going to alternate between recording for 720 degrees then missing the next 720, record again then miss again, etc.   Or maybe you chose to acquire 719 to try to avoid this problem?

   If you do a continuous acquisition, you won't need to keep stopping the task and retriggering another run.  You just trigger once off TDC.  From that point, you can simply choose to read 720 samples at a time from the task.  Each chunk will represent 1 engine cycle and there will be no gaps of missing data between chunks.

2. The 'rate' input to the task is a convenient fiction when using an external variable clock signal.  Similarly, the t0 and dt fields of a waveform output are also fiction.  Ignore them, override them, or simply read the data out as 2D array.

3. You'll need a counter task to measure the real interval timing of the external clock pulses.  It'll need to use an "Arm Start" Trigger (found in the DAQmx Trigger property node) rather than a standard "Start" Trigger.  I'd set up for continuous period measurement.  One little gotcha however.  

   NI changed the behavior of the counters on the X-series boards compared to prior generations in a way that adds an inconvenient wrinkle.   On X-series boards, the 1st period is measured at the 2nd signal edge (at the end of the first complete interval).   This makes an off-by-one problem between your counter buffer and your AI buffer.   Older boards would give a 1st period measurement at the 1st edge.  That value was generally meaningless, but it helped to keep task buffers in sync.

-Kevin P

[SebiMIT]

Thanks for the input. The problem with that approach  is, if I change the engine speed I cannot use the continous recording and I need to retrigger. Is that right?

[mikeporter]

You should be triggering from your once every two rotations input already. The code shouldn't care about engine speed.

Mike...

[SebiMIT]

Sorry, if I described what I meant in a bad way. If I set the recording to continous, it only uses one TDC trigger and then in the following records one signal every crankangle (triggered by the other trigger). If I stop the engine now and then restart it, without stopping the code, the readings are totally off. 

What I want to do is retrigger the recording of 720 samples every TDC to make sure the reference is set and that there is no drif over long recording times. I have the problem, that the encoder, which gives me the crank angle pulses, flexes with higher speed a little bit, therefore the TDC signal needs to be retriggered. 

[mikeporter]

Yes, you need to configure the code to wait for the external trigger, then acquire 720 data points and then go back to waiting for another trigger.

Mike...

[SebiMIT]

I am doing that right now with the code I am using, the problem is it skippes every other cycle. I have it in a simple loop. The loop time is double of that of a cycle. So gets the TDC trigger starts recording the 720 samples, but it doesnt have enought time to "rearm" the next TDC trigger and therefore skips one. Then the next one it sees again and records. 

I think the DAQ card might be too old and not support retriggering, and therfore is too slow. But is there a way around it? (Maybe something like this: ClickMe)