Programatic NPSV - Why does Open and Verify Connection take so long

[Timmar]

Dear, NPSV officionado's

During a fault condition, Open and Verify Connection.vi taks a lot longer than the prescribed timeout.

Can anyone suggest a workaround or a reason wht this is happening

Context:

LV13SP1

NPSV hosted on a PXI8108 on the local network.

NPSV being read on a high end PC

Fault is simulated by software resetting or powering down the PXI-8108 controller

Problem doesn't occur if distributed system manager is used to start/stop the shared variable process (timeout <25 mSec).

I have something in the order of 100 NPSV's that all work fine when times are good. 

My application "Freezes" the moment I drop the host controller. each re-connect attempt takes upward of 3.5 seconds.

I had assumed that the 100 mSec timeout would give me a maximum of 10 seconds Hang time while application figures out the variables are broken.

@3.5 seconds, it is 6 minutes before the software emerges from it's read routine.

My workaround is to check each variable read and stop trying if one fails, retrying sometime later allowing the rest of the application to get on with it's business..

It would be nice for the modules to work as advertised.

[mikeporter]

It sounds like you may be using the wrong communications technique. What does the overall structure of your application look like?

Mike...

[Timmar]

This observed behaviour is in a simple test .VI.

Sure, my application may not be structured correctly to handle a 3.5 second read lag, it was designed around the expectation that the VI would exit after the prescribed timeout, in my case 100 ms.

PS.  I don't think that this familiy of VI's runs re-entrant,

In previous tests, I put 10 of these vi's in parallel, the timeout is 35 seconds, not the (un)expected 3.5.

[mikeporter]

I'm afraid you might have heard me backwards. My point is that you overall architecture might be just fine. You just need a communications technique that is adequate -- and shared variables don't seem to be.

Luckily there are many other techniques to choose from. However, if you were serious about 100 shared variables the change may not be exactly pain-free -- though good modularization can help a lot. For example, a hardware abstraction layer that hides the exact method of communications from the calling code can be very helpful.

Which gets us back to my question concerning how all the pieces of your system fit together. It will help select an appropriate communication technique.

Mike...

[Timmar]

I read and understood your archtectural point, but it goes nowhere to explain the undocumented behavior of the Labview .VI or how to avoid it.

To me it is a bug, and a difficult one because of the specific conditions that occur to reproduce it.

It is part of the Labview software and as such should either work, be repaired, documented or removed, regardless of my architectural choices..

I have already band-aided around it so that it doesn't cause a problems.

Abstracting it isn't going to help, it is going to "lag" in an unexpected way no matter where I code it.

As to other communications methods, I require a 1 to many relationship that isn't pre-determined and can be seen using a tool like distibuted system manager.

To my knowlege, network streams doesn't provide this and is not available for Modbus.

The shared variable count is high because there are multiple asynchronus systems on the host device,