Strange Variance of Duration for Pulse Generation

[Konrado]

Based on the example vi "Gen Dig Pulse Train-Finite-Dig Start.vi" I've created a setup as shown in the picture. The rising edge to initiate the pulse is given by a 100 Hz signal from a function generator attached to Ctr1.

How come there's such a great variance in the time measured to create the signal?

Is that normal?

I wanted to synchronize a Lamp with a Spectrometer and a 20ms variance is much too much.

PS: I'm using a PCI-6602 with a BNC-2121 connector block

[Alexander_Sobolev]

It takes a lot of time to reserve resources and free them after the task is cleared. You do not need to repeat the same operations multiple times. Plenty of operations with different jitter.

Solution 1: I it works for 100 Hz.

Commit all resources before the task starts. When you stop the task, it returns to the same state before start. It is much faster - because of fewer operations.

Solution 2: really fast, completely hardware based generation loop:

use retriggerable generation: see Gen Dig Pulse Train-Finite-Retriggerable.vi from examples.

1 more note about your solution: if something goes wrong (you specify wrong device, etc), it will be tricky to press stop button when modal error message blocks main interface.

[Konrado]

Thank you for the tips, I've built a vi following Solution 1 as you can see it in Blockdiagram1. 🙂

After i've commited the resources i can trigger multiple scans (# of avaraged scans > 1) without the need to set everything from scratch.

But there are still some points to work on:

1. as in Frontpanel1 can be seen, the variance ist still there. (Frequency Generator with 50 Hz TTL signal connected to PFI34, which simulates a light barrier for rpm measurement of the rotating system and triggering (lamp, spectrometer))

2. the chosen setup doesn't fit the needs of our triggering: I always want to scan the exact same position of a rotational system with the following two options which can be adjusted manually:
- number of Pulses of the Lamp into one integration time of the spectrometer
- number of averaged scans (repetitions of the measurement with same integration time and Lamp Pulses to average the spectrum).
To match the desired position of the rotational system with the flash lamp, one has to set the right initial delay. The generated pulse train (number of Pulses of Lamp) has the same period as the period of rotation to match the exactly same position of the rotational system.
That works great for the first time, the "# of averaged scans" loops is executed. But from the second execution of the loop on, a strange characteristic DAQmx destroys our synchronization. Instead of the initial delay to get to the right position of the rotating system, the low time of the pulse train is used, which leads to useless measurements.
This problem is already discussed on the ni homepage
("Creating a Delayed, Retriggerable and Finite Pulse Generator", http://digital.ni.com/public.nsf/allkb/204538A044431C9B86257377004EB952 )
and I've built a vi similar to the one proposed in that article. That's the first solution which seemed to satisfy the needs, but unfortunately it often produces false triggering (approximately every 7th generated continuous pulse train is not in the right phase - checked with a digital multimeter).
Has anybody an idea where this may come from? Or is there another, more reliable solution?

3. The time to take one measurement was surprisingly long with about 100 ms. If the system rotates with a frequency of 50 Hz, the expected time for the triggering would be two times the period of the generated pulse train of the lamp = 2*(0,01+0,01) = 40 ms plus (worst case) an additional period of rotation to wait for the rising edge of the light barrier, what equals 60 ms. The triggering of the spec should be negligible, as no pulse train is generated and the period is substantially shorter.
I've created a test-vi to measure the duration of the initialization of the tasks and the actual pulse generation, as can be seen in vi1.jpg and e2.jpg.
The time to initialize the task is almost negligible short with 1 ms. So the time to execute the pulse generation lasts 100 ms - where do the additional 40 ms come from? - Is there a way to speed up the pulse generation?

vi1: (only 3 attachments allowed, so i had to insert it as an image 😉

[Alexander_Sobolev]

Answering the points

1) Your period is very close to frequency generator period: it is 10 ms initial delay + 5* 10 ms high time + 5* 0.1 ms low time = 60.5 ms + delay to start/finish. Sync pulses go with 20 ms. Your programmatic synchronization error is above 1 ms. You do not trigger from the right pulse and have these spikes (in the beginning and at 50-th iteration). Period variation between spikes is around 1 ms, as it should be.

2) "it often produces false triggering". We use almost the same scheme on the same PCI 6602 to generate sequence of 1000 pulses (at 10 MHz) with the rate of 9 kHz. The synchronization error with external signal is not more than  25 ns. Though we do not use pause trigger, but finite retriggerable acquisition, triggered by the delayed pulse (second counter in the example).

False triggering means bad settings.

3) It is not initialize, it is filling the settings cluster. The work with hardware starts with Daqmx start or commit VIs, and you include them in "execute" time.

[Konrado]

First i want to thank you for your answer. I got some more questions relating to the answers:

1)  "You do not trigger from the right pulse and have these spikes (in the beginning and at 50-th iteration)." - Does that mean that the peaks are normal variance arount the expected value?

2) "False triggering means bad settings." - do you have an idea of common mistakes / or documents with help for troubleshooting?

3) By "commit resources" you can save ~20 ms between similar pulses, am i right?

expected value Blockdiagramm1: 60,5 ms
measured value Blockdiagramm1: ~80 ms
---------------------------------------------------------------> ~20 ms too much

expected value e2: 60 ms
measured value e2: ~100 ms
---------------------------------------------------------------> ~40 ms too much

Thanks for your time,

Konrado

[Alexander_Sobolev]

expected value Blockdiagramm1: 60,5 ms
measured value Blockdiagramm1: ~80 ms

You trigger from pulse 0. You finish 60+ ms later - missing pulses 1, 2, 3. You can not trigger from pulse 3 and need to wait for the pulse #4. It gives your 80 ms.

With the same timing the same thing will happen if you make it completely hardware based (eliminate all software ~1 ms jitter to restart task). May be this is happening in your second case.

One more thing: your pulse period is not exactly 20 ms, and you specify lamp period to be exactly 20 ms. It will give you 4% phase shift for the fifth pulse.

What I would advise for your task:

First, measure your pulses period variation: Maximum Jitter = J below. Measure period T of the pulses continuously.

Run lamp shutter continuously with the preset shift relative to main pulse: single pulse, retriggerable, low time is your delay (from 0+ to period-J), high time - as low as required by the lamp hardware to trigger (1 us). Start it before measuring. Stop the task only it the very end: when you have completed all your measurements.

Spectrometer command. It should determine timing. I suppose the spectrometer acquisiotion is initiated with the rising edge. So you can generate single retriggerable pulses with low time to determine delay (0+ to period-J). High time can specify the number of pulses N to average: N*T. Update T continuously with the property node without restarting the task.

[Konrado]

Dear Alexander, thank you very much for your help and your trigger example!

But to me there is one problem with the continuous lamb retriggering:
The lamb-delay as well as its low time can change depending on the sample we would like to measure.
In principle the measurement pattern would go like this (here 3 measurements to avarage, 4 sample positions):
(d1-d1-d1-d2-d2-d2-d3-d3-d3-d4-d4-d4)x and so on... (x is ~ 250)
There can be up to 8 different sample positions and therefore up to 8 delayes (d1 to d8 with 10 % to 95 % of the period of rotation which is constant neglecting the jitter).

Of course, most times we are working with only on sample, but there is this forementioned possibility!

Unfortunately there is no way to change thispattern mentioned above, because a mechanic device has to be moved after each cycle and during each cycle all samples have to be measured.

Is there any way to "update" the low time of the lamb trigger without reintializing the whole task again.

Thank you very much for your input!

[Alexander_Sobolev]

Yes, you can update low  time while the task is running.

It is the daqmx channel property node: counter output -> pulse - time

[Kevin_Price]

Just a couple quick notes:

- your pulse is defined as a low time / high time pair.  It *used* to be true many versions of DAQmx ago that one of those two properties (I *think* high time) could be updated by itself, but the other required you to write both.  It was as though one property was treated as a master and both values were updated only when the master was written.

   The point is, if you only need to update the low time, you *might* find that you have to also write the constant high time with it.

- the change to pulse properties can only be software-timed on the 6602.  You cannot re-change properties until a pulse has been generated using the previous properties, else you'll get an error.  I recall doing a "thought experiment" that I never verified in hw, but it always seemed like you'd have to expect a minimum of two pulses of the old settings to be generated before the new settings could kick in.  Since you aren't allowed to write the new values in the midst of the 1st pulse, you'll have to wait and write them during the 2nd, then they won't take effect until the 3rd.

  If you need a specific quantity of pulses at each of those different delay settings, you'd better look into an X-series board which supports buffered pulse outputs.

-Kevin P

[Alexander_Sobolev]

> You cannot re-change properties until a pulse has been generated using the previous properties, else you'll get an error.

I think we can: We usually have 1 kHz laser pulses and need to position 50 us window so that laser pulse was in its middle. So we generate 975 us low time trigger pulse, marking window start. It is idle for 24 us. Sometimes we need to move the window to the middle: to 500 us. Changing with property node have never given an error. I doubt that we always hit that 24 us gap when the pulse is waiting for retrigger.

Though we did not check the actual moment when a new setting is applied, here is an experience:

After the change we set up and initiate analog buffer acquisition (It takes below 100 ms I think). We have not seen a problem with laser repetition rate up to 10 Hz (have not checked above). So I suppose it is applied to the next pulse after the property node.