Shared Variable Programmatic Open

[jordani]

I am frustrated by the behavior of the Open Variable Connection in Background function. It is advertised as if it is not blocking and attempts to open a connection in the background. I have performed some tests and found surprising behavior.

In my test code I have attempted to open 3 connections to unpublished shared variables. The typical execution time for this code is 10-15 seconds, which suggests 2 things:

1. Nothing is being done in a background thread.
2. The VIs are not reentrant.

 Upon further reflection, point 1 is also supported by the presence of a non-reference (the error terminal) at the output. Point 2 is frustrating because it means that nothing can be done to make the code execute in the background. Considering points 1 and 2, I can see no benefit to using this VI in place of the equivalent which features a timeout.

Can anybody tell me what I'm missing? Is this a bug? Does anybody have a technique that is known to work in LV2016 for opening connections to a PSP variable in the background?

[2Shanez]

Hey jordani,

Do you recieve any errors when you test this VI or have you attempted using any other variables?

Regards,

ShaneK

[jordani]

If the variables  are not published then I get an error. My point was that they VI doesn't  run in the background and it doesn't  appear to be reentrant. These two points seem to be exactly  opposite to what a user would expect from reading the help file.

[natasftw]

That test doesn't really tell you anything about re-entrancy.  You'd want to run tests that show the individual calls versus the parallel calls.  If opening one takes ~10-15 seconds, we'd still expect the parallel process to take ~10-15 seconds as well.

Granted, I'd expect something non-blocking to be faster than that.

[jordani]

I should have been a little more clear: if the three calls to open shared variables(which should run in parallel if VIs were reentrant) are reduced to one, the average time changes from 10-15 seconds to 3-5 seconds. In other words, it's close enough to dividing by 3 to make me very suspicious that the VI doesn't behave as advertised. Also, the time out behaviour is completely unsepecified in the documentation. No where does it suggest that the VIs will only try to connect for about 5 seconds.

[jordani]

I'm wondering if the lack of further responses indicates that the community is happy with having no method for connecting to shared variables asynchronously. I have a large connection of shared variables, and, if I loose the connection to one I'd like to be able to reconnect without delaying the read of the others. I have worked around this using queues (one for connecting variables and another for reading) but I still think that the asynchronous VI should work as advertised.

I'd really like to know if this is my mistake, something that needs to be corrected in the documentation, or, a bug.

[Ben]

---

@jordani wrote:

I'm wondering if the lack of further responses indicates that the community is happy with having no method for connecting to shared variables asynchronously....

I'd really like to know if this is my mistake, something that needs to be corrected in the documentation, or, a bug.

---

I can not speak for others but in my case,  I discovered years ago that if I integrate some fancy NI widgets into my applications and latter find out they are lacking in some way, I am at the mercy of NI to ack and fix the problem.

By writing my own functions for communications, I can always go back to the code and fix it.

So I do not use SV or the toher mechanisms excpet were I have no other option or am faced with geting an application working that was developed by my customer.

Just sharing waht I can.

Ben