Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization issue after restarting task

Good morning,

 

I am using a PCIe-6353 and have a synchronized output of an AO modulating between two values and a CO. I think the image below describes it pretty well. I now need to update the AO values once in a while without stopping the CO-2. To do that, I added another CO whose sole purpose is to synchronize the AO with the CO-2 if it was updated.

 

So I basically start the task and everything works as expected. However, if I update the AO values (i.e. stopping the tasks, writing new values and restarting it) the synchronizaton with CO-2 does not work properly anymore. I set up a CO-1 as digital trigger edge. Could anybody help me figure out why it does not work? in a day or two I will have access to an oscilloscope. At the moment I just see that my DAQ is off after updating the values the way shown below.

 

Thanks!

 

image.png

Flumen_1-1634556309816.pngFlumen_2-1634556316753.png

 

 

 

 

0 Kudos
Message 1 of 9
(1,626 Views)

Actual code would be more useful than screenshots, but here are things I can notice:

 

1. All the tasks are continuous.  During the "Update AO" case, AO is briefly stopped, reconfigured, and restarted while the other tasks continue.  Any correlation you need between AO sample # and CO-2 pulse # will get lost.  Maybe also correlation to CO-1 trigger # if your reconfig makes you miss a trigger.

 

2. You can help yourself out by making a faster "Update AO" case.  You only need the Stop, Write, and Start calls, not the other ones.  (And you *might* make these go even faster if your "Init" case calls "DAQmx Control Task" with a commit action.  Search here and you'll find more about the DAQmx Task State Model.)

 

3. In fact, you could help yourself even more by omitting the Stop and Start.  Simply writing a full buffer worth of new data while the task continues to run should be sufficient.  DAQmx will manage things for you.  However, you *might* find that a 2-sample buffer isn't big enough to make this work reliably -- though it'll probably be fine if CO-2 is actually generating 10 Hz sample clock pulses.

 

4. I assume your pulse parameters for CO-1 pass behind the icon into the top terminals for Low Ticks and High Ticks.  Both of your counter tasks use default idle low polarity, thus both of them use Initial Delay for the 1st time spent in idle state rather than Low Ticks.  You should probably send that Low Ticks wire into the Initial Delay terminal too.

 

 

-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 2 of 9
(1,591 Views)

Thanks for your quick response. 

 

1) The correlation between the no. of pulses does not matter here. All I care about is that the AO starts again, as defined, on the next CO-1. If one or even two CO-1 pulses are missed does not really matter either, it just needs to be synchronized. That is also why I just copied the DAQmx VIs from the init case and redefine everything.

However, I do not understand why the synchronization gets lost.

 

2)  I see that I can simplify that and will look up your suggestion. This will speed up the AO update case but I still do not see why this should effect thy synchronization between CO-1 and AO.

 

3) That sounds very interesting. I will test this asap. I can always write more of the same values and just increase the frequency to get the same result if this is required. I thought that by doing this one would lose the synchronization. If DAQmx takes care of that and writes ALL the old values before starting the new ones, it would be the best and simplest solution.

 

4) Sorry but I do not really get what you mean here.

I assume that once I start CO-1, that the high ticks are sent first, then followed by the low ticks. There should be no initial delay as the default is zero. Or what am I missing here?

 

Thanks!

 

 

0 Kudos
Message 3 of 9
(1,587 Views)

1. I don't see a reason why AO shouldn't re-establish sync relative to some pulse from CO-1 that should be triggering it (and to CO-2 that acts as its sample clock).  What happens specifically that you refer to as "losing sync"?

 

2. If it's ok to miss a trigger or two from CO-1, this isn't so important.

 

3. DAQmx will be working in the background to keep transferring data from your task buffer (presently holding 2 samples) down to the DAQ board via DMA.  By default, AO tasks are in "regeneration" mode, so it circles around the task buffer, repeatedly delivering the buffer contents.

    When you write new contents to the buffer, DAQmx does its best to manage that.  It'll start writing from where it previously left off, and it will try (with a very good chance of success) to delay that writing when necessary to keep from "lapping" the pointer that tracks the next sample to be delivered via DMA.

    There are corner cases that can lead to task errors, and I don't know all the ins and outs of what they are.  I think they tend to correlate to high sample rates and either small overall buffers or small fractional-buffer-size writes.

 

4. Nope.  Pulses are defined to start with idle state time followed by pulse time.  With your default idle state of low, you'll get low state first and high state second.   Further, the very first pulse will use 'initial delay' as its initial low state time.

    The default value of 'initial delay' says it's 0, but in reality it will be silently coerced to be at least 2 cycles of the timebase feeding the counter's Source pin.  By default, this will be the board's max timebase (100 MHz), so the delay is only 20 nanosec which will look like 0 in most apps.  [Extraordinarily slow pulses may use a slower timebase to avoid counter rollover between pulses.  But we're talking about something on the order of 43 seconds for either of idle time or pulse time.]

 

 

-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 4 of 9
(1,575 Views)

AO and CO-2 has a timing relationship initially because they are both started by the same CO-1 edge. However when AO is stopped and restarted, since CO-2 is already off and running continuously, AO's timing relationship with CO-2 is lost. It only has a timing relationship with CO-1 on the restart. If CO-2's period is a perfect divisor of CO-1's period, then upon restart AO might still have a indirect timing relationship with CO-2, but otherwise its only timing relationship is with CO-1 on the restart.

 

If we want to preserve the timing relationship between AO and CO-2, then one alternative is do what Kevin suggested to not stop AO and just overwrite the regeneration buffer with new data. Another alternative is to use CO-2 as the sample clock for AO, we would have to write repeated data into the AO generation so its the output waveform would still be 10Hz.

0 Kudos
Message 5 of 9
(1,566 Views)

Hi Kevin,

 

1) I am triggering an external camera to capture a modulating signal. After the init case it works, after update it is out of sync. I can check using an oscilloscope today or tomorrow to see if the issue is not somewhere else.

 

3) I could not get this to work right away. I get an error if I try to write new data while the task is running - but I also have not had time to look into it further and check out the link you sent

 

4) Good to know, thanks. I don't believe it explains the behaviour though because I am using the digital trigger edge - if high or low is first does not really matter. But I will see this also clearer once I can measure on the oscilloscope. 

0 Kudos
Message 6 of 9
(1,539 Views)

Hi Jerry_X,

 

I believe CO-1, CO-2 and AO should be in sync even after updating the values. CO-1 is defined as a multiple (e.g. every 5th pulse, 0.2 frequency) of CO-2, so they should be always in sync when using the same clock and same DAQ board, I believe. I am using ticks instead of frequency to make sure the board can put this out exactly as defined. 

Restarting the AO task using CO-1 as trigger should thus also synchronize AO and CO-2. Don't you agree?

 

If I made a mistake in the definition of the ticks, you would be correct, I think. I will double check!

0 Kudos
Message 7 of 9
(1,538 Views)

It's still not clear what you mean *exactly* by losing sync, but I have a theory.

 

Right now every CO-2 pulse is used as a sample clock by the AO task.  You state that you have 5 CO-2 pulses for every 1 CO-1 pulse, which acts as a trigger for AO as well as CO-2.

 

Your AO task has 2 sample values defined.  You're just gonna toggle between them with every CO-2 pulse.  But here's where the plan may be flawed b/c AO repeats every 2 CO-2 pulses while CO-1 repeats every 5.  And these will only line up half the time.

 

Is *that* the kind of "sync" problem you see?   Syncing AO *signal levels* to CO-1?

 

 

-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 8 of 9
(1,525 Views)

Hi Kevin,

 

Your thoughts are correct. The frequency of the main trigger needs to be half of the AO frequency so that the applied voltage is always the same when the AO is triggered. 

 

I finally got my hands on an oscilloscope today to check the output and synchronization of the different tasks - and found the issue. It is quite unfortunate but happens once in a while, I guess.

The wire of high time was connected correctly to CO-1 (the main CO synchronizing all other tasks), but the low time wire was connected to the 'delay'. This was not obvious from the block diagram and looked like everything was connected correctly.

 

So what happens is that the CO-1 frequency is much higher than intended as it uses the same no. of low ticks that are defined as high ticks it seems. Thus, the first trigger works fine as the frequency does not matter here. But when the AO is stopped and restarted, it is triggered with the next CO-1, which is not at the correct time. So synchronization is lost.

 

Thank you for the help and sorry for the incovienience due to such an unnecessary mistake.

0 Kudos
Message 9 of 9
(1,506 Views)