LabVIEW
performance limitation while communicating with multiple DUTs
Hey David, thanks for the response.
The reason that I mentioned that my code was maybe not optimized is because I am able to achieve a higher sample rate using the for loop with parallelism.
ok, It's a pretty ugly looking VI but I have attached a png image of my communications VI. The other 2 subVIs that are a part of this VI are both reentrant as well and are straight forward in terms of code.The cases that are not shown simply report different kinds of errors.
I'm beginning to think that this issue might be due to my hardware limitation. I'm just trying to imagine 10 units, each trying to send and receive information. All that information gets bundle onto the PC bus, trying to reach its host virtual COM port and all this being done at a baud rate of 19200 bps. Maybe its just not possible.
I might have 10 seperate COM ports for simultaneous communication but do i still have the same limitations as with one COM port because I only have one physical rs232 com port connection on my computer?
I'm just trying to think out loud, hope this is making some sense.
Thanks again,
Serge
Yup, ugly. 
But don't take it personally. Lots of my code is similarly ugly - and I see what you're trying to do there, with having to read header info to know how long the balance of the response is - I've dealt with lots of messaging architectures that are similarly structured. I can probably help you there later, if you can give me some other details of the protocol.
But for right now - first thing that comes to mind - are you ABSOLUTELY CERTAIN that your little "delay" VI is reentrant? Because that, if not reentrant, would absolutely bring your parallelism to a crawl, since it's called ad nauseum by all those loops pending on I/O. Double-, triple-check that it's set up reentrant.
Better yet, try this experiment: delete the whole pack of them (restoring the error thru wire as you go). Inside each while loop where you deleted one, drop a 'Wait (ms)' node (off the Timing palette). Popup on the input and wire an integer '1' to each. (Note, placing the Wait node in any open area inside the loop is fine - they have no data dependency on the rest of the while loop processing, nor do they need it.) You've just restored the behavior you sought, in a guaranteed non-blocking way. Run the resultant and report back here.
Good luck!
Dave
Haha I understand your doubt. I did try replacing the delay VIs with a wait function but the behavior was the same.
I'll keep digging, hopefully I can find something!
Let me know your thoughts.
thanks,
Serge
