High/Low speed measurement of same signal using both PCI-6259 M-DAQ and Compact Fieldpoint simultaneously

[Hosehead]

This question covers a couple areas so I hope it's OK to post it on this board. 

For the hardware side, is there any problem with connecting the same signal (voltage) to the AI channels of a PCI-6259 and a cFP AI-118?  Will there be any feedback or signal degradation or distortion or whatever, assuming common ground and aside from ground loop considerations?

For the software side, I want to sample this channel on the MHz level via the 6259 for logging, and on the kHz level via the cFP module for controlling a PID loop.  I've discarded the idea of parallel loops for the reason that the way I understand it my slow PID loop will hold up the fast logging loop.  I also considered but rejected a single loop with a case structure where the PID loop only runs every 200 ms or something, because during the time the PID loop is running I won't be able to log any data.  Will two VI's running at the same time solve this problem (one for high speed logging using the 6259 as the hardware, the other for slower PID control using the cFP as the hardware)?  How does the computer handle running two VI's simultaneously, does it give each an allocation of processor space or does it run them in turns the way it would do parallel loops within a single VI?

Thanks for any help.

[Jarrod_B.]

Hello Hosehead,

As long as you are not creating any ground loops by connecting two different grounds together, there should be no problem with connecting the same voltage signal to both your PCI-6259 and your cFP-AI-118. 

In terms of the software side of things, you can certainly use parallel loops to run two processes at different rates.  Each loop runs independently of the other unless there is a dataflow dependency between the two.  If you do need to share data between loops, the producer/consumer architecture will allow you to do this without creating a dependency between the two loops. 

Hope this information helps!

Best regards,

[Hosehead]

Hi Jarrod,

Thanks for the reply.  I'm glad to hear about the hardware possibility.

For the parallel loops, I have to ask, are you sure?  I guess I should be more specific.  The way I understand parallel loops, partly due to the "Using LabVIEW to Create Multithreaded Applications for Maximum Performance and Reliability" publication on this website, is that they won't ever run at the same exact time.  There's a run queue and the loop at the top of the queue runs, then the next one, and so on.  You can mess with priorities and other things to change the order in which they run but still can't force two to run at exactly the same time. 

For example, say I have one loop that all it does is read and log data to a file, so it can run very fast, say < 1ms.  Then I have another loop that has many calculations and is slow, say 200 ms.  So that means whenever the slow loop runs, I'm going to be waiting 200 ms for it to finish before my fast loop runs again.  If I put a Wait in the slow loop of 250 ms, then the effect would be to run the slow loop once (200ms), run the fast loop as many times as it can in 50ms, then run the slow loop again, and so on.  My logged data would end up with 50ms chunks of data separated by 200 ms.

This the way I understand it, so if I'm wrong please let me know.  I'd love to hear that this is not true.

-Hosehead

[Hosehead]

Oh yeah, and if I am right about this, if I divide my two loops into two VIs that run simultaneously, will that make any difference (will they run truly in parallel or will there still be a run queue)?  Or any other solution?

[Jarrod_B.]

Hi Hosehead,

Let's take a look at an excerpt from the tutorial you mentioned:

__________________________________________________
Basic Execution System
The following description applies to single-threaded and multithreaded execution systems.

The basic execution system maintains a queue of active tasks. For example, if you have three loops running in parallel, at any given time one task is running and the other two are waiting in the queue. Assuming all tasks have the same priority, one of the tasks runs for a certain amount of time. That task moves to the end of the queue, and the next task runs. When a task completes, the execution system removes it from the queue.

The execution system runs the first element of the queue by calling the generated code of the VI. At some point, the generated code of that VI checks with the execution system to see if the execution system assigns another task to run. If not, the code for the VI continues to run.

Synchronous/Blocking Nodes
A few nodes or items on the block diagram are synchronous, meaning they do not multitask with other nodes. In a multithreaded application, they run to completion, and the thread in which they run is monopolized by that task until the task completes.

Code Interface Nodes (CINs), DLL calls, and computation functions run synchronously. Most analysis VIs and data acquisition VIs contain CINs and therefore run synchronously.

Almost all other nodes are asynchronous. For example, structures, I/O functions, timing functions, and subVIs run asynchronously.
__________________________________________________

So, the while loop is an asynchronous, or non-blocking node.  This means that it does multitask with other nodes instead of monopolizing the thread until it finishes executing.  The multitasking between two while loops has nothing to do with individual iterations running to completion.  The code inside of each while loop runs for a certain amount of time (not necessarily to completion) before the processor switches to another task.  This is known as multitasking, and it gives the effect of simultaneous execution.  The key words in that tutorial excerpt are "for a certain amount of time."  One iteration of a loop is not required to finish before another loop can execute.

Take a look at the attached example.  If what you were saying was true, the bottom loop would never execute and its numeric indicator would not update properly because the top outer loop is running code in its first iteration without yielding.  This is not the case.  Hopefully this helps clear things up.

Best regards,

[Hosehead]

Hi Jarrod,

This is good news.  I guess I assumed the "certain amount of time" part referred to the loop execution time.  Your example code helps to see what's really going on especially if I put a 50ms delay in the top loop.

One last question - from the tutorial document it says that "computation functions run synchronously".  So...how does this fit in to all this, if I have some computation functions within one or both of the loops?

Thanks,
Hosehead

[Jarrod_B.]

Hello Hosehead,

Any function that is trully synchronous, or blocking, will monopolize the thread that it is in until it is finished.  You do not have to worry about this starving a second loop though, because two parallel loops will run in two separate threads.  So even if a certain function starves one thread, the other should continue to execute. 

I would recommend that you try a parallel loop architecture, then if you have any problems, you may want to start a new discussion forum post on that issue. 

Best regards,

[Hosehead]

I see.  Thanks very much for your help.

Hosehead