Is race condition with serial port (RS232)

[Vasilich2004]

Hi All,

Typical serial port action consists of 2 steps - write and read. In typical race condition example VI has 2 loops and each loop makes serial port action. I assume application will have case like "Loop1 write -> Loop 2 write -> Loop2 read and get Loop1 answer". Am I correct?

Of course, there are some application types when this race condition will not happen. For example, serial port write and read steps are combined in one vi which is not reentrant.

Also if I am correct I don't know any instrument driver which use semaphore to avoid race condition.

Thanks, Andrey.

[RavensFan]

Functions can run in any order as long as all of their inputs are available.  So if you have different serial reads and writes in different loops, of course they could run in whatever order.

This is a basic principle of dataflow.  Just because it is a serial port doesn't make its functions any different than any other LabVIEW functions.

You should centralize all serial port communication for a given port in a single loop or subVI.  Then use queues to send data back and forth to that loop.

[tst]

---

Vasilich2004 wrote:
Am I correct?

---

Yes.

There are, of course, different solutions to the problem. RF pointed out one. You brought up another - place the W/R actions in a single VI and always use that VI for communication.

[crossrulz]

It really depends on your instrument for which way is better for avoiding your race condition.  Since it sounds like it is a command-response for getting data, I would use the non-reentrant VI approach to do the write and read process.

[Vasilich2004]

To RavensFan:

=============

You should centralize all serial port communication for a given port in a single loop or subVI.  Then use queues to send data back and forth to that loop.

============

When system would be a little complicated - centralization is bad idea. 

[Vasilich2004]

To tst:

========

You brought up another - place the W/R actions in a single VI and always use that VI for communication

========

Not my solution. That is more or less usual approach in all NI third party drivers.

I use 2 semaphores:

- one for simple action (write-read)

- second for long complicated action

[Vasilich2004]

To crossutz:

===========

... I would use the non-reentrant VI approach to do the write and read process.

==========

and in case of 10 or 100 pieces of the same devices in system performance will drop ... 😉

[Vasilich2004]

Actually, can somebody explain me how to add answer of somebody when I reply?

I am tired to make copy-paste

[Hooovahh]

I don't think there is a multi-quote option, but once you hit reply, hit the Quote button on the upper right of the text box to plop down what they said, like this.

---

@Vasilich2004 wrote:

When system would be a little complicated - centralization is bad idea. 

---

I would vote for centralization, it might make things more complicated, but you get code that is more manageable, extensible, modular, and probably more reusable.

[crossrulz]

---

@Vasilich2004 wrote:

To crossutz:

===========

... I would use the non-reentrant VI approach to do the write and read process.

==========

and in case of 10 or 100 pieces of the same devices in system performance will drop ... 😉

---

Over RS-232, I doubt we are dealing with that many instruments.  And I made that comment based on the understanding that this is the only instrument being used.  It is simple and works well.  Yes, it does lack scalability, but it is simple for newbies to create.