issue while simultaneously running DAQ and IMAQ tasks

[mmarques]

Hello everyone,

I'm running a LabVIEW 2012 x86_64 VI which is controlling acquisition and signal generation from two different cards (an old NI PCI-6071E DAQ card, and a NI PCIe-1429 CameraLink card connected to a Basler Sprint line camera).
The program is generating two different triangular signals and outputting them through the two DAQ analog outputs, and also producing a TTL signal through one of its counters (CTR0). Furthermore, I'm also acquiring a signal through the DAQ (using one of its analog inputs), whose acquisition is being triggered by the generated TTL signal using the Pause Trigger environment.

All I have previously described is working perfectly and has been implemented successfully. The problem begins when I add the line camera (on the CameraLink card, the NI PCIe-1429) which, as I stressed previously, it is connected through a different card and a different bus. (the line camera frame acquisition is also being triggered by the generated TTL signal, but I can also use an external function generator for testing purposes)

I have devised the code (see attached image, code-printout_annotated.jpg) so that in one event (frame) it configures all the relevant parameters (eg. triggering & device initialisation) and in the other it enters a series of parallel loops which control the different parts of the operation (line camera acquisition, DAQ output, DAQ input, and what would be the “main” loop where I would integrate all the acquired data).

The big problem here is that, when I run this code, the DAQ-related operations all run fine, but the line camera part acquires one frame and then freezes. I can see the problem is not on the “main” loop (which basically receives the whole IMAQ image through a local variable and computes a line average of it), but in fact it is a IMAQ Acquisition sub-VI which freezes. And the problem is not related to the triggering of the camera using the TTL signal, since when I use an external function generator to do so I can get the line camera running at the desired frame rate, provided I prevent the DAQ operations from running. If I stop it and run a simpler version of the code which contains only the line camera code, it will acquire all the frames at the desired frame rate (controlled by the TTL signal frequency).

I was able to narrow down the problem to the analog output part of the code. In fact, if I disable the DAQ Write sub-VI only for the AO channels (I kept the TTL on, which uses one of the DAQ counters) the program will behave as expected, and I am able to control the camera frame rate by simply adjusting the frequency of the TTL signal on the front panel, as intended.
Furthermore, I was able to keep the DAQ Write sub-VI active by putting a DAQ Start Task in the shaded region (with the exclamation mark), inside a case structure which is activated by a First Call? condition (hence, it should only run once!). But what I actually get in the output signal is a series of “packets” alternating with a flat (zero) signal, and the time base is all wrong (see the other attached figure, signal-comparison.jpg). It appears the system is restarting the task all the time, even though it was supposed to start it only once and I have regeneration enabled.

To make matters worse, a previous revision of my code is able to simultaneously perform all of these tasks, but in that one all the DAQ-related operations are performed in a single loop (including the reading from the analog input), and I really didn't want that, as I need to set different sampling rates for the analog input and outputs. Could that be the culprit?

Thank you for your time, and I appreciate any help you can provide me.

Best regards,
-- 
Manuel Jorge Marques
--------------------------------------------------
Post-graduate research student
Applied Optics Group, School of Physical Sciences
University of Kent (Canterbury campus), CT2 7NH

[AndyNash]

Hi Manuel,

Firstly I have a few questions:

1. Do you get any error codes when your code freezes?
2. Does the loop perform one loop then stop or does the whole program freeze?
3. Can you show what is under the “Enabled” case where you highlighted the problem?
4. Which Basler Sprint camera are you using?
5. What line rate are you trying to achieve with the camera?
6. Can you upload both your current code and the previous code that you had working to see the differences?

To upload your code right click on build specifications in your project, then new “Zip file” to include all the components.

Best regards,

[Kevin_Price]

Manuel,

I suspect I can explain at least part of your AO trouble based on the DAQmx task state model. 

(Lucky timing -- I'm fresh off reading a thread that brought it up, so I was primed to be thinking

about it and notice).  Actually, that link is just a general overview.  More pertinent info can be

found here.

Since you don't explicitly start your AO task before entering the main AO loop, each time you

call DAQmx Write with the auto-start = True input the task will indeed attempt to auto-start.

However, due to the state model, I think it's going to want to revert back to a prior UN-started

state after the write.  That transition may in turn cause an error because the task may be

trying to transition before the written data is generated.  There will be other potential errors in

subsequent iterations as you keep writing to a task that is configured for continuous

regeneration.  You aren't catching or handling any such errors though, so the task refnum

could become invalid on subsequent iterations.

As to why the DAQmx Start inside the loop was helping you -- I'm not sure if that implies

a successful state reversion back to UN-started, or whether the possible uncaught errors

might leave the old task refnum in a state that allows it to be re-started.  Either way, it's

just a work around and not a complete fix.

Here's a starting point on what to do next:  Do a DAQmx Write with Autostart==False

before the loop.  I'd recommend writing enough samples to fill the buffer.  (Maybe you

should size the buffer according to the # samples you need to define the repeated

waveform).  Follow that with an explicit DAQmx Start.  Change the task refnum and

error tunnels on the loop border into shift registers.  Catch and handle any errors in the

loop where you attempt to update the AO waveform with your call to DAQmx Write.

I'm not near hardware to test now, but I'm not sure you board will allow you to write new

data to a continuous AO generation task.  Even if it does, you should do some more

research because you may not want to write an entire buffer full all at once.

Hope that helps move you along some.

-Kevin P

[mmarques]

Thank you! I will try this as soon as I get back to the lab, after the Christmas holidays...

I did try putting the start task VI outside the loop and putting the write VI inside without auto-start, and if I recall correctly it did output the signal properly, however it froze the IMAQ acquisition, nevertheless...

I think your tip might correct my problem with sometimes getting the program complaining of some values which were not written (it usually happens after I stop it), but I fail to see why this should affect the IMAQ acquisition - shouldn't this be independent systems?

[mmarques]

Hello AndyNash,

Thank you for your reply. In response to your questions:

1. Nope, I get no error codes whatsoever - the code behaves normally (ie, I can still change the parameters related to the DAQ, such as setting the amplitude or the frequency of the triangular signal, and they reflect on what I see on the output signal; it is only the acquisition part that freezes, and resumes without any errors as soon as I disable the AO part of the code.)

2. Like I said, it runs normally. If I use the debug (highlight execution) mode I see it gets stuck in one of the IMAQdx sub-VIs (green arrow over the subVI icon, and it stays there...). All the remaining loops run perfectly...

3. In that "Enabled" case I have a Start Task VI inside a case structure, which activates this VI on the very first run using a "First Call?" variable. If I enable this I get all loops running but a lousy signal on my output...

4. My line camera is a Basler Sprint spl-140km (12-bit, 140 kHz, 4096 pixels), if I'm not mistaken (I'm away from the lab, I cannot double-check that until early next year...).

5. The line rate will be dictated by the frequency of the TTL signal - I'm generating it with frequencies ranging between 50 and 100 Hz, and I can see on MAX that the camera is perfectly capable of dealing with such line (and frame) rates.

6. I will make it available ASAP, I need to first check with my supervisor if I can upload it here.

Thank you for your help!

Best regards,

MM

[AndyNash]

Hi Manuel,

Have you had any luck resolving this issue?

• You say it gets stuck in one of the IMAQdx sub-VIs, which VI does it get stuck on?
• I recommend removing the working sections of the code, to try and isolate the issue to a specific area of code. If you could then upload this piece of code that recreates the issue.
• There are a number of useful examples within NI Example Finder for IMAQdx. It would be worth adapting one of these to include a simple DAQ loop, to see if you can run them simultaneously that way.

Kind regards,