From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

synchronize ttl output, analog acquisition and sequence of .net calls within a timed loop

Rishi,

 

In terms of synchronizing the tasks, the best way to do that would be to enforce execution order by using appropriate error wire routing. I would also recommend moving your AI DAQ task into the previous frame of the flat sequence structure and moving everything up to your "DAQmx Start,vi" into the previous frame as well. This will ensure that your DAQ tasks are both set up before you call your .NET code and the counter output task will start as close as possible to the .NET call. 

 

Let me know if this change affects anything. 

Rob B
FlexRIO Product Manager
Message 11 of 14
(403 Views)

Okay, here is a solution that does (almost) what I desired: synchronization between an analog acquisition, digital out and a .NET call. I ended up needing to change my digital output and analog input to operate on a pulse-by-pulse basis and put these in the same timed-loop that runs the .NET call with the loop timing determined by the control loop from task vi.

 

It definitely runs synchronously, BUT there are still some minor issues that need to be resolved:

 

First, there is a slow phase shift between the acquisition and the digital output task. My only guess is that this has something to do with buffering of the digital output port, but I have no idea how this arises or where to change things to eliminate it.

 

Second, SPEED and skipped loop iterations. My application cannot tolerate missing an expected iteration of the loop. Further, I need this thing to run as fast as possible. In my previous (unsynchronized) version, I had no problem executing the .NET call with a period of 50 ms. In the current version, the timed-loop skips iterations of the frame if the period is less than 150 ms. This also depends on the sampling rate, though I am unsure as to why this dependence exists.

 

Finally, for some reason, whether or not there are any skipped frames, my loop finishes executing before the digital output task is ready to stop and causes a -200292 error on the last or last+1 iteration of the loop. 

 

Thanks for reading this. I hope you have some input, if not, oh well. At least this is one more post that might help some other perplexed user figure some application out....

 

0 Kudos
Message 12 of 14
(393 Views)

anyone with any ideas on how to speed up this loop?

0 Kudos
Message 13 of 14
(374 Views)

Rishi,

 

It sounds like it may be better to use a real-time operating system if your tolerances on loop time are fine and you need a more deterministic approach. Of course adding the DAQmx Read and DAQmx Write functions inside of the loop will slow it down a bit; removing the numeric and graph indicators from the loop will help as well, as having them in the loop forces a redraw each iteration (this will definitely slow down the code). 

 

Timed loops perform as exepcted on real-time targets, without real-time it is up to Windows to schedule processor time for each thread, meaning non-deterministic timing. 

Rob B
FlexRIO Product Manager
Message 14 of 14
(365 Views)