Buffered trigger pattern using NI PCIe-6321

[joe25]

Dear NI-Users,

once again, I need some help with my triggering.

Some background:
I have a device rotating, whereby the frequency is measured using a counter. Furthermore, I need to aquire data based on this rotation (TTL, other counter). The timing is defined by a relative value (e.g. percent) of the rotation. E.g. 0.5, then the delay/low time would be 5ms for a frequency of 100 Hz. There are multible measurements per delay as well as multiple delays (measurement positions).
However, this is a defined number: e.g. 4 positions, 10 measurments each. What is important: the rotation is not constant but may vary and the delay can be bigger than one because the DAQ hardware (CCD spectrometer) is not as fast as the device is rotating (a value of 1.5 would skip one rotation).

What I do at the moment:
I use the PCI-6602 card and measure the frequency of my source (ctr0). Then I have a retriggered counter to create pulses for the DAQ hardware (ctr1, there is one more trigger based on this but that's not so important) using signal of ctr0 as a starting edge. Then I update the LowTime in a loop on demand.

The "problem":
Much more pulses are generated as needed because I have to measure position 1 and change the measurement position (-> low time). Between each change I have to wait to be sure that each position is measured correctly. This costs a lot of time and way more important, stresses the hardware. Moreover, it's almost impossible to synchronize it with another measurement because is not clear which pulse was used for the measurement.

What I want to do:
Because I have new hardware allowing buffered operation (PCIe-6321 ), I thought about defining a new and complete trigger scheme (e.g. 10 x delay1, 10 x delay2, ...) for the measurement. Is this possible or am I on the wrong road? It is important that it is retriggered because of the exact timing necessity and the delay should be therefore relative, too. If the last requirement cannot be fulfilled it might be fine, too (the rotation is almost constant so that the delay will only vary slightly).

Thank you very much for your help!
Johannes

[joe25]

Hi, may I bring this topic up?

Thanks a lot, Johannes

[RupiDo]

Hi Johannes,

right now I don't know exactly your aim of the application. Please confirm or correct the following statements:

1. The rotational speed is measured with Ctr0 of PCI-6602 as a trigger signal

2. A retriggerable  pulse generation is done, based on rising edge of trigger signal of point1.

3. In your post it's written: " I need to aquire data based on this rotation (TTL, other counter)". In next paragraph it's written: " Then I have a retriggered counter to create pulses for the DAQ hardware. Do you generate or acuqire pulses?

4. The timing of the generated/acquired pulses is relative to the rotational speed.

5. Could you explain the delay time? I guess it`s the low time of the generated/acquired pulses, which hava a frequency of example 50% of the rotational speed.

In general with the PCIe-6321 you had made a good choice. Because you can define several AI clocks (3), moreover the DIO tasks have their own clock.

Kind regards,

RupiDo

NI Germany

[joe25]

Hi RupiDo,

thank you for your reply. Let me answer your questions.

1. Yes, the signal (TTL) is given by a light barrier measuring the rotor frequency

2. Correct.

3. I generate pulses to aquire data using my spectrometer. So, precisely spoken it is data generation using the NI hardware.

4. Correct. The measurement positions are fixed positions on the rotor. So for the rotating case, these are relative "time" positions. Is that clear?

5. The delay is the time between the light barrier signal (ctr0) and the measurement positions (so this is the lowtime as well as initial delay).

For a constant rotor speed and multiple measurements of one position, the frequency of the generated pulses would be equal to the frequency of the rotor. If the rotor is too fast (the detector too slow) then the frequency of TTL generation would be half (and so on) the rotor speed. But keep in mind that it has to be matched with the rotor.

Hope that this answers your question. Please tell me, if you need some more information.

Kind regards,

Johannes

[RupiDo]

Hi Johannes,

thanks for your info.

1. Some rising edges of rotational speed trigger pulses are missed

If the rotational speed is 10 Hz and e.g. 2 pulses are detected for each revolution a TTL frequency of 20 Hz is measured.

So if a rising edge occurs a pulse train with a certain amount of pulses will be generated. If the rotational speed is to fast, some rising edges are missed, due the task generates still the certain amount of pulses for the previous rising edge trigger singna.

Please confirm or correct this statement.

2. Trigger on nth sample

Please keep in mind, with the CO_pulse Ticks you are able to trigger each nth sample of a trigger signal.

Check this link for triggering each nth sample

Generate a Pulse and Start Trigger Every N Incoming Pulses

http://zone.ni.com/devzone/cda/epd/p/id/3137

Kind regards,

rupido

[joe25]

Hi Rupido,

I've created a little cartoon to clarify my task.

No every speed trigger pulses is caught. So the measured frequency is very accurate and confident.

For the simple case (lets assume this first) one pulse is generated per revolution. E.g. pulse 1 (position 1), pulse 2 (position 1), pulse 3 (position 2), pulse 4 (position 2)

This pattern would measure position 1 and 2 twice during 4 rotations.

The problem/limitation is the maximum frequency the data aquisition hardware can be triggered. This is ~ 200 Hz, however the rotation can be 50 Hz up to 1000 Hz.

So for measurments at rotations above 200 Hz, x revolutions have to be skipped. This can either be achieved setting a higher delay (delay position + x*(revolution time)) or defining a second counter as shown in your link. However, the last solution requires a second counter and I have only four with my PCIe-6321. For the actual solution the increased delay works quite fine.

The key question is now how to define the counter that more than one delay can be measured in a row. For a single position this is no problem for me, at least if I assume a constant delay (actually it is a function of the rotation speed).

Thanks a lot.

Johannes

[RupiDo]

Hi Johannes,

thanks for your efforts. I recommend to call our service hotline: 089/741313-0.

So we can talk about the configuration of counter.

Thanks,

rupido

NI Germany