I've worked in labVIEW but new to RT systems. Right now, I'm working on an PXIe 8840 based RT system. I'm trying to send RS422 serial messages through PXIe 8431/8 every 5ms in two ports simultaneously. Below is the screenshot of what was made.
For me, both loops need to be executed in parallel. Even though i gave same priority (different processor was chosen through manual mode), there is a difference. Sometimes one loop gets stuck while other being executed. CAn anyone please help !!!!
Tried "Synchronize Timed Structure Starts.vi" with no success.
Thanks & Regards
What happens when a loop gets stuck? Do you get an error message?
Can you show more of your code? It is hard to see how these loops interact with each other. I see wires being branched going in, but where are they coming from and where are the other branches going to?
What is your baud rate? 5 msec seems kind of quick for serial communication. And does it truly need to be synchronized? Serial comms were never meant for time critical synchronization. By their very nature, the data is already a little bit old by the time you receive it.
No matter how much we (and by "we", I mean "I" -- can't blame my more patient Forum colleagues) rail against "Pictures Instead of Code", people continue to post Pictures Instead of Code, preventing us from seeing the "Entire Picture", being able to "edit" the code, clean it up, and demonstrate a possible "solution". Oh, well ...
So if you have two Serial Streams that need to both run every 5 ms, why not have a single Loop and let the Principle of Data Flow (the "central principle/premise of LabVIEW") take care of this for you? I'd demonstrate, but you failed to post the code ...
Thank you RavensFan & Bob_Schor for your response
sorry about the picture. Now I've attached the code herewith.
In our case we need the 5ms serial communication to be happened in all ports simultaneously. Initially I tried with single loop but that seems to be adding some overhead and not all four bytes sent within a time frame of 5ms. I have two boards and each require 2 bytes of data every 5 ms. So, split it into two (attached vi is with single timed loop).
I'm not sure whether this is a buffer issue. Thanks in advance for your help.
Thanks & Regards
Sigh. Do you understand the Principle of Data Flow, upon which LabVIEW is built and which is responsible for a lot of its power?
A corollary of Data Flow is that functions that do not have common inputs or outputs will run in parallel (for all intents and purposes), something that is extremely useful when dealing with hardware functions (like VISA) which often have "wait until done" functionality.
You have two VISA resources that you want use to write some data, and you have reason to think that you can write the data to one of the resources in 5 ms. Instead of wiring the two VISA write sequences serially, which basically says "Do one write, wait until it's done, then do the second, which will take twice as long as doing one", you should split the Error Line, put the first VISA sequence on one Error Line, and the second VISA sequence on the second Error Line, using Merge Errors to bring the two Error Lines back together when the VISA Write sequences complete. Now the code says "Start both VISA Write as close to the same time as possible, let the Hardware "wait" on each of them until it has data to process, take them in "first-come, first-served" order, do the (relatively quick) task of reading and processing the data, then exit. Doing these two tasks in this manner should take basically about as much time as doing only one of them, since most of the time should be in "waiting for VISA to return from the Write command".
Give that a try and see if that helps. Also, because of Data Flow, you can get rid of the Sequence Frames by using the Error Line (and other wires) to serialize things. The one place you will need a Frame is to "trap" a Timing function, as these don't have Error In/Error Out to "sit" on the Error Line and become serialized (it's a Feature, not a Bug). Having no Sequence Frames will allow you to shrink your Block Diagram -- a Small Block Diagram is a more-easily-understood Block Diagram.