LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Datasocket bug or limitation?

Hi fellas!

 

I am running into a problem while calling multiple DataSocket write operations, simultaneously, in parallel loops. 

 

The DataSocket Server Manager (DSM) settings are changed to allow 1000 connections, and there are datasocket items added in the Predefined Data Items too, with "Allow Multiple Writers" checked. The problem occurs when running the program in normal mode. When running the programs with execution highlighted, it shows no error, as the two datasocket write function calls get enough time to finish their operations.

 

Please have a look at the two attached files. The file names are very much intuitive - one is to write to the DS server and the other is to read from it. In the DS write VI, there are two parallel loops, and if you run the program without execution highlight, you will have an error message (probably from the second loop), and if you run it with execution highlighted, you will have no errors.

 

To understand the error, I would suggest - 

Run the MultipleDS-Write with execution highlighted.

Run the MultipleDS-Read with execution highlighted.

Observe the output in the "Read" VI Front Panel.

Turn off execution highlight in "Read" VI.

Turn off execution highlight in "Write" VI, and soon you'll have error.

 

I searched the forum for similar issues in the past, and there are several threads with such problem, but either the issue is left open (no indication from the thread starter about having found the solution) or the problem was in their settings - which I have already implemented.

 

Hence, I feel like either this is a bug or a limitation. What to do? I have already tried with Semaphores, and it works without any error, but in my program, I am avoiding the use of Semaphore, as it will clutter the Block Diagram, which already looks very much full.

 

Thanks ahead!

Vaibhav
Download All
0 Kudos
Message 1 of 18
(5,884 Views)

I think it is a bug, because the DataSocket Write function has 10 seconds to TimeOut. But it doesn't happen so. It immediately shows an error, instead of waiting for 10 seconds for the other DataSocket to finish the task.

 

I have also tried using different number of miliseconds in the "Wait" function in each of the parallel loops. But without success.

 

In previous threads on this issue, the Knowledge Base articles pointed do not give answer to my question.

 

Am I missing something?

Vaibhav
0 Kudos
Message 2 of 18
(5,859 Views)

Can you share what the error code was and post images of the writers?

 

I carefully avoid multiple writters to a single DS so I can't say I've tried it and it works.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 18
(5,848 Views)

Hi Ben!

 

How are you?

 

Thanks for the interest.

 

Well, the error code is 1108. It says "Pending Operation in Progress" to the write operation.

 

If you run the VI's in the first message, you will see the error very soon. I have attached the sample code in the first message.

 

Thanks!

Vaibhav
0 Kudos
Message 4 of 18
(5,842 Views)

@Vaibhav wrote:

Hi Ben!

 

How are you?

 

Thanks for the interest.

 

Well, the error code is 1108. It says "Pending Operation in Progress" to the write operation.

 

If you run the VI's in the first message, you will see the error very soon. I have attached the sample code in the first message.

 

Thanks!


For my normal customers I would fire up a PC with the the right version of LV but I only answer Q's here durring breaks so... if you post images ... Smiley Wink

 

While we are waiting for NI to get someone to look up the spec on attempted simultaneous writing to a single DS...

 

In my apps I would wrap teh DS ref in an AE with methods to open and write the DS and then use the AE for all access to that DS throughout the code. THe AE will automatically sequence your DS write operations without having to use semaphores explcitly.

 

Q:

What is the DS in your app being used for that it does not care about potential race conditions where two threads try to write different values?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 18
(5,825 Views)

Hi Ben,

 

My requirement is:

In a communication system's server, I have several parallel loops processing incoming messages from several types of users (for example Clients, Brokers etc.) and each of these loops would process information and send (reply or forward) messages to one or more of these users. 

Which means, a user of type Client may get some incoming messages from multiple loops simultaneously. This user (client) will only read data at the DS item dedicated to "Clients" but there are several loops writing information to this dedicated Client DS item - information intended for any user of type Client (even if I create a separate DS item for each user, there can be a case when two loops are writing exactly to the same user). So in any case, I need two or more DS write operations on a single DS item.

 

What I understand of DS is that one may write separate data to separate DS items (call them references/registers etc.) and the data don't get mixed among these different items on the same DS server. So, I have several DS items on this server, which are for several types of users. So all messages intended for Clients would be sent to a particular DS item, and so on. The Client users (whose user names may coincide with user names of other user types), would just read this particular DS item in their application (running separately on their computers). So it's like multiple writers, and multiple readers - many to many kind of situation. And as far as I understand, we cannot write to an item X and expect to read the same data from item Y. 

 

I hope I made my requirement clear. 

In my server application, there are 12 process (while) loops (3 for each of the 4 types of users), and 1 event handling while loop. For example, I can make serial process for 3 loops of a certain user type (among themselves), but they must run in parallel with other loops of other user types.

 

I have attached a screenshot of the program and error message. 

 

Vaibhav
0 Kudos
Message 6 of 18
(5,815 Views)

I am confused.

 

You want to write different strings from different threads to the same DS. evn if you did not get the error message and the writes happened, how do the readers of that single DS get both values when the two threads are figthing with each other over what shouldb be in that DS.

 

It still sounds like my brother is standing at teh top of the steps turning the lights on while I am at the botom trying to turn them off.

 

So still confused (but never you mind that! )

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 18
(5,807 Views)

LOL!

 

No, it's more like, your brother and his friend are turning on green and yellow lights respectively. Downstairs, you and your friend are turning off green and yellow lights respectively. But you don't turn off yellow light and your friend doesn't turn off green light. That's the desired behaviour.

 

Posting an image of the application process diagram - in symbolic while loops, which show exact behaviour (as desired/expected).

I hope it will make things clear now. 

MultiDS-Diagram.png

Vaibhav
0 Kudos
Message 8 of 18
(5,796 Views)

@Vaibhav wrote:

LOL!

 

No, it's more like, your brother and his friend are turning on green and yellow lights respectively. Downstairs, you and your friend are turning off green and yellow lights respectively. But you don't turn off yellow light and your friend doesn't turn off green light. That's the desired behaviour.

 

Posting an image of the application process diagram - in symbolic while loops, which show exact behaviour (as desired/expected).

I hope it will make things clear now. 

MultiDS-Diagram.png


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OK I don't give up easy.

 

Lets just talk about the yellow light for the time being and pretend that is is handled by "...msgB" DS.

 

It still seems that there is a very good chance (assuming the error is prevented) that when both of the loops in Program 1 write different values to "...msgB" DS that Program 2 will probably miss one of those values. And that is the part that confuses me since if it does not matter of the top loop tromps on the value from the bottom loop then why bother writting it?

 

AS I said earlier, wrapping this up in an AE will eliminate the error code.

 

Take care,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 9 of 18
(5,790 Views)

@Ben wrote:

OK I don't give up easy.

 

Lets just talk about the yellow light for the time being and pretend that is is handled by "...msgB" DS.

 

It still seems that there is a very good chance (assuming the error is prevented) that when both of the loops in Program 1 write different values to "...msgB" DS that Program 2 will probably miss one of those values. And that is the part that confuses me since if it does not matter of the top loop tromps on the value from the bottom loop then why bother writting it?

 

AS I said earlier, wrapping this up in an AE will eliminate the error code.

 

Take care,

 

Ben


I like that attitude. So do I. That's why fighting with this system since long.

 

Ok, got your confusion now. In my green light, yellow light description, to match it more with the case, I can say, your brother and his friend, both are turning on green and yellow lights. But you and your friend just work with either of the lights.

 

Ok, responding to your questions - 

1) No, the program 3 will not miss any message written in that DS item "msgB".

The reader loop (in program 3) will continue, each time waiting for the number of seconds as mentioned in the TimeOut of DSReader (default 10 secs), to wait for a new value, and if by the end of this time, no new message has arrived, it will simply timeout, AND give that old value again to the output. Whenever a NEW message is written on that DS item "msgB" , the reader in program 3 will give some output message, without TimeOut ("TimeOut?" output value "False"), meaning a new message has arrived. To make things fast, I keep timeout value of 1 second, and the loop wait 100 ms. Means, each 100 ms, the loop runs, and in each iteration it will wait for 1 second for the datasocket to give some value. If the writer in program 1 has written some value, the reader won't wait for 1 second and immediately will give the value out. If the writer writes so many values, the reader will work without interruption (except that 100 ms of the loop wait timer), but nothing will be missed.

 

2) Yes, that I forgot to ask you. What is AE?

Vaibhav
0 Kudos
Message 10 of 18
(5,780 Views)