Parallel DAQ architecture

[Jay6]

    I need to integrate a lot of devices into one Labview control software. These devices are connected to a CRIO, and possibly via TCP/IP as well. All devices need to be able to communicate with one another through the software, and can't any other way. This means that at any unpredictable time, two or more devices could send in information that needs to be processed. I would imagine that a queued state machine would be a good strucutre to handle the inputs, but I'm unsure how to ensure that all inputs are recieved. Crucial information could be lost if a device sent in information while a different unput was being stored in the queue.

    My only idea as to how to attack this problem is to allocate multiple threads (each with its own core for true parallel) to handle input. However, the machine only has two cores. The chance of this problem actually happening is small, but it is too important to ignore. I'm dealing with high powered lasers and heaters, so if one thing goes wrong it won't be fun.

    I am a newcomer to Labview so I'm oblivious to most of it's features. Is there any truly safe way handle this problem?

[RavensFan]

I don't understand your application, but I don't understand why you think that something would be lost if something else is already putting data in a queue.  Data is a queue is not lost.

[Jay6]

Sorry that was unclear. If my process is currently writing data to a queue and more information is coming in at the same time, I won't be handling the new input because I'm busy storing the other information in the queue. Of course the amount of time it takes for information to be stored in a queue is very small, but if there are two inputs exactly simulatneously on one core, from what I know about Labview, it would only handle one.

[BTC_Admin]

By nature, "Queue" implies that all your inputs will be stored one after the other.  However, it sounds like you're worried about in-coming communication buffer getting overwritten. Queueing does not come into the play until AFTER you've received data and then you'd put them in a queue.

I had done some controls of high-powered diode lasers as well as some collamation related automation for a decade so I know how hazardous it would get if you don't have a very precise control. So before you use queueing, I would strongly suggest that you decide if an unexpected lag between serving of two queues would cause any issue in your system. Also, be careful when you use queue (for example if you would be implementing an E-stop, you'd have to ensure that your queue flushes/empties immediately.)

Perhaps you could list some device communications (such as, if they are connected to cRIO, how are you communicating with them). Also, if you could specify if you have control over TCP/IP communications of any devices (specifically - if you can use different TCP/IP ports on them - alternately one of those inexpensive WiFi routers could also be used to route communications to different ports coming into your LabVIEW application.)

Seems that you'd first have to elaborate a little more on your setup for us to understand what you're trying to accomplish...

-DP

[RavensFan]

It won't be lost.  The second enqueue will just wait until the first one completes, then it will enqueue the newer data.

I'm quite sure you won't have any problems because if you did, I'm sure I would have heard about such an issue long before now.

[BTC_Admin]

---

@Jay6 wrote:

Sorry that was unclear. If my process is currently writing data to a queue and more information is coming in at the same time, I won't be handling the new input because I'm busy storing the other information in the queue. Of course the amount of time it takes for information to be stored in a queue is very small, but if there are two inputs exactly simulatneously on one core, from what I know about Labview, it would only handle one.

---

In that case make sure that you have a large enough input buffer so that any pending incoming communication doesn't get lost before you service it...  For example, when you configure a TCP/IP or a VISA communication, you can specify input/output buffer size.

-DP