LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

one serial port in 2 threads

We know that one serial port is OCCUPIED by one instance before released.What is INSTANCE? Not include a thread?Like the example below,will there be error in one of the 2 loop?

Thanks .
2.png

0 Kudos
Message 1 of 8
(1,849 Views)

Hi avater,

 

what's the reason to open a single port twice?

Why not open just once before the loops?

 

(Using a shared resource like a serial port in parallel is screaming for problems. Create your own handler routine which handles the serial port and use queues etc. for communication between the handler and your other loops.)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 2 of 8
(1,812 Views)

@avater wrote:

We know that one serial port is OCCUPIED by one instance before released.What is INSTANCE? Not include a thread?Like the example below,will there be error in one of the 2 loop?


Yes one of them will return an error since it is already opened by the other. Which one of the two it will be will be random.

Even if you would take the initialization outside of the loops and try to communicate from both loops with the same device you would indeed cause lots of trouble since device communication is usually bidirectional and you may end up reading answers from the device to commands that the other loop sent to it, messing up the entire communciation between each loop with the device.

The way to implement device communication with a single device from multiple locations in your app is by creating a service or deamon for your device, which is basically one single engine (can be a loop on your diagram or a loop inside a subVI that keeps running until it receives the shutdown command) and implement a message based command-response interface to this service by using queues for the commands and notifiers for possible responses that you want to send back to the command sender. Look for discussions about Producer-Consumer templates to get more information about possible examples and implementations.

Sounds complicated? Not really but it is some work for sure, but that is what programming is about in the end. 

Rolf Kalbermatter
My Blog
Message 3 of 8
(1,781 Views)

Thanks very much for your comment.

I know  the serial port,and completely agree your way to play it.

The thing is that 2 while-loop mean 2 threads,but how can a single resource be operated without error in 2 threads.

I SUPPOSED one of the while-loop will result an error ,actually not.

0 Kudos
Message 4 of 8
(1,758 Views)

Sorry the example is not clear enough.

Maybe we can just discuss the good way to OPERATE serial port in 2 threads,not just OPEN.

0 Kudos
Message 5 of 8
(1,756 Views)

Hi avater,

 

operate that single COM port in just a single loop - as has been suggested by Rolf and me with programming a handler/service/daemon…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 6 of 8
(1,751 Views)

An option is to move all communication to an Action Engine (AE) and use that in both loops. That way each loop will be forced to wait until the device is free (as i suspect it's a "Send command and then recieve result" type of communication).

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 7 of 8
(1,729 Views)

Your code won't throw an error out on the indicator.  The error will be how your code behaves when add the code to read and write to the serial port.  Suppose one loops sends a command "Read A", the other sends a command "Read B".  And then after that both have a Read function to read the response.  It would be a pure race condition as to which loop writes its command first, and which read function gets the Read response.  Loop A might wind up reading the response intended for B and vice versa.

 

Keeping the serial communication in its own loop and using a producer consumer architecture to send it commands from both loops is a good concept.  The action engine concept is also good as long as you keep all the read/write functions together within a specific action so that the action engine doesn't return until it has received the response for the command it had sent.  The action engine then blocks the other loop from using it until the action for that first loop has been fully completed because action engines are non-reentrant subVI's.

Message 8 of 8
(1,717 Views)