02-03-2016 05:04 AM
Hi
1) I would like to have better understanding about network-published shared variable and indicator which is bind to the shared variable. In this regard I create a vi consist of a shared variable and an indicator which is bind to the shared variable with access type read/write. The block diagram of the vi is as follows:
Since the SVE updates variables every 10ms or after the transmit buffer is filled to capacity (8KB) as mentioned in http://www.ni.com/white-paper/4679/en/, I expect “X Sh 2” has the new value after 15ms wait but the result is different:
However after 25ms wait this parameter is updated:
Why this take more time than I expected?
2) Also I want to see the difference between writing value to the shared variable and writing value to the indicator which is bind to the shared variable. In this regard, I changed the vi to the following form:
The result is as follows:
The result shows that “X Loc 1” and “X Loc 3” are updated but “X Loc 2” is not! Why?
Regards
Solved! Go to Solution.
02-03-2016 05:14 AM
Here is my come.
02-03-2016 05:23 AM
@msad66 wrote:2) Also I want to see the difference between writing value to the shared variable and writing value to the indicator which is bind to the shared variable. In this regard, I changed the vi to the following form:
The result is as follows:
The result shows that “X Loc 1” and “X Loc 3” are updated but “X Loc 2” is not! Why?
Regards
This one looks like a race condition. You wrote to X. After a short time, X self-updated itself with the shared variable which still had the old value, and then later self-updated with the shared variable again just this time the variable was actually updated.
Is the shared variable being hosted on this machine? Is there a lot of network traffic which might be causing the SVE to be slow in updating?
02-03-2016 05:48 AM
1) Is the shared variable being hosted on this machine?
2) Is there a lot of network traffic which might be causing the SVE to be slow in updating?
Thanks for your quick replay.
1) Yes.
2) No. The attached code just have one shared variable.
According to your answer (If it is a race condition), using local variable of indicator which is bind to network-published shared variable is wrong since it causes race condition every time it is used. Do you agree?
02-03-2016 05:52 AM
@msad66 wrote:According to your answer (If it is a race condition), using local variable of indicator which is bind to network-published shared variable is wrong since it causes race condition every time it is used. Do you agree?
That's what the evidence points to. Regardless, I would use the shared variable directly anyways. That way you know for sure you are getting the value that was last broadcasted.
02-03-2016 06:07 AM
Thanks.
Ok. I will do the same.
What about my first question?
Do you have any clue why it takes more than 10ms to update the value?
I think it takes exactly 20ms to do so.
Why?
09-25-2019 06:23 AM
Hello guys,
I am currently working on a project that i need to use network shared variable. I am trying to send the incoming data stream to my PC using network-published shared variable to cRIO. When i debug the block diagram with probe i see that the data is being buffered network-published shared variable. I also checked that on NI distributed system manager. However, I can't get any data on reader side. I created a simple while loop in cRIO and tried to get the stream data and observe it but i failed. I can upload the VIs if you'd like. Hence, Do you have any idea about what causes this problem? Thanks in advance.
09-25-2019 06:48 AM
@samil_07 wrote:
I am currently working on a project that i need to use network shared variable.
Right there is your first mistake. Network Published Shared Variables are never a good choice (except for when trying to pass the CLED). This is especially true since you are trying to stream data. Replace the NPSV with a Network Stream or straight up TCP/IP. In this case, I would make the cRIO the "listener" and have your PC open the connection to the cRIO. The cRIO can then stream the data to the PC very easily.