Is race condition with serial port (RS232)

[billko]

---

@Vasilich2004 wrote:

Take list of paper, draw 2 structures :  server/application - serial ports and switch - computers. Looks the same?

Write functionality which was suggested for server/application. Find how it is solved in switch.

Is it possible to repeat in server/application? Probably, yes. How much effort?

---

I have a suggestion:

Try posting your question in your native lagnuage.  I'm sure someone here will be able to help.  I haven't a clue what you are trying to ask.

[tst]

I don't think there's an actual question any more. There was one in the original post, but that was answered. I think now it's just a matter of broken communications, so let's see if I can clear it up:

If there's a single resource in a system that needs to be accessed by more than one user, then access to it should be controlled so that there are no collisions.

If there are multiple resources of the same type in the system, then access to each of them should be controlled somehow. This can be done through a central location or in a distributed fashion and each solution has advantages and disadvantages.

[Yamaeda]

---

@Vasilich2004 wrote:

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

---

If you expect an answer, you must make a write+read-vi as to not lose data. This VI must be non-reentrant. If you have many simultaneous instances this could slow things down, yes. The solution is two-fold:

1. 1 serial port should never several reader/writers, gather up the function in some consumer loop.

2. Object orientated instrument drivers, then the non-reentrancy is per object, no semaphores needed.

/Y

[Vasilich2004]

I attached reetrant vi. I hope it will look enough to see logic.

1. Каждый уровень в программе должен защищаться сам, а не где-то на следующем уровне. В противном случае каждый следующий уровень будет разрастаться все больше и больше без информации почему защита должна быть сделана. Это прокатывает в простых программах, но как только программа становится больше ее сложность возрастает в геометрической последоватьности.

2. У примера с сетью такая же архитектура как у предложенного кем-то сервером для последовательных портов (если кто-то начнет верещать что у сети hardware, а сервер это software, тогда разговарить не о чем).

Свитч при включении узнает все устройства в сети автоматически. Также новое устройство появлясь оповещает о себе. Так что свитч все устройства знает автоматически и ему не нужны никакие настройки.

А вот серверу или следующему уровню надо предоствавлять информацию. И это приводит к следующему - все настроили и все работает. сервер использует порты 1, 5 и 9. И тут сломался UBS-COM port adapter и все порты ставли другими. В моем случае поменял номер порта у устройства и это очевидно. А вот в случает сервера уже совсем неочевидно, а если последний раз настраивали систему пару лет назад, то гимора кто-то поимеет.

Есть еще проблемы с таким классным сервером. одним словом - такой сервер это пятое колесо у телеги, если не хуже.

i think we wasted more time than it should be. If somebody still don't see logic - let just stay on different positions 😉

[crossrulz]

Your VI is more complicated than it needs to be.

1. You could save a lot of your converting to binary arrays and back to numerics and visa versa with simple Unflatten From String and Flatten To String.

2. There is no real need for the While loop since you could just use a VISA Read with 6 bytes to read.  Let the timeout of the VISA Read handle it.  You already have the resource locked with the Semaphore, so where's the harm.  So with that, no need for the loop, the Bytes At Port, and the case structure.

3. You actually don't need a Semaphore.  You can use the VISA Lock and the VISA Unlock to do the job for you.  One less thing to carry around.

I have no real issue with the setup you are trying to do here.  But it really does depend on your application.  At the top of my head, I can think of two different applications that took each approach.  I had a test system, based on TestStand, that used an Action Engine to control the instruments and any thread could get the data they needed using the AE as the blocking node to prevent race conditions.  The other application reads streaming data from an instrument.  That application has centralized communications because I needed to constantly read those ports and that centralized module can receive commands from other parts of the application to do whatever is needed.  I have to admit that the later project is the program that I am most proud of, architecturally speaking.

[Vasilich2004]

I use few languages and, usually, have limited time to make system.

1. I don't think Unflatten From String and Flatten To String would be critical compare to Serial port speed.

2. VISA possibilities is good but something didn't work and pure code was easy for me. (NI driver MUST have different approach.) I modify this code for next device.

3. In next time I will try to remember to look VISA Lock-Unlock. Thanks!

There is ONLY reason when higher layer (=server which is basically incorrect word for this case or centralised part) takes care about syncronization - there are 2 or more devices which depend of each other. Let takes stupid example, DAC and ADC. DAC sets voltage which is out ADC range. So ADC range should be changed and then DAC will be set. (please, will not talk that ADC wouldn't be broken - I don't talk about real example and I try to show connection which would be easy to solve with extra object).

About your proud architecture. First of all, that is good itself!

Also I suggest to look on my previous topic (now don't see how to get list of my topics here) where you (?) reminded about LabVIEW event. In such approach 1, 2, 3, ..., n clients subscribe and there is not need for the server (or extra layer).

[Vasilich2004]

I checked VISA Lock Async VI function. The fuction doesn't lock Write and Read, like semaphore.

[mfaltin]

Hi Vasilich,

Have you looked through the VISA Locking example VI from National Instruments?

It can be found by navigating to Help-> Find Examples-> Hardware Input and Output-> VISA-> VISA Locking.vi

Mitchell Faltin

Applications Engineer

National Instruments

www.ni.com/support

[Vasilich2004]

I looked example. It doesn't avoid race condition of wrire-read.

Moreover, it looks strange - why does application need to open serial post twice?

[Jorr-El]

Hi Vasilich2004,

The example that Mitchell pointed out demonstrates a simple case of two VISA sessions accessing the same resource. VISA Resource 1 refers to the first session, which then locks the resource. It completes its Write/Read operation, and then waits until the user presses the "Release Lock" button on the front panel, after which it will unlock the resource.

This allows the second session to open the resource, lock it for its own use, write and read, and then unlock it. It opens the serial port twice because it's demonstrating how the lock and unlock works to prevent race conditions by only allowing one session to access the resource at a time, locking the resource until the session is finished with the communication.

Here is a document that explains a bit more about VISA locking, and has links that describe more about how locks can be shared:

http://zone.ni.com/reference/en-XX/help/370131S-01/ni-visa/visalocks/