Help (please) understanding VI Server versions inter- compatibility

[tbd]

Greetings,

      Our test application uses VI server to populate FP data on a "remote" test-station, where another application is running.  Now we want to develop a second application to configure the same test-station.  I've been told that VI-server is version-dependent - that if we recompile one of our applications under a newer version of LabVIEW, the newer code may not work with older code where VI Server is involved.

I've been asked to confirm that version compatibility concern is warranted and, if so, investigate whether there might be a work-around allowing newer code/version to interface with older code (perhaps through manipulation of a lower "layer" of VI Server...) 

Thanks/Cheers! 

[tst]

I have little experience with this, but my understanding is that the VI server connection basically works, but if there are properties/methods which don't match, you will get an error when trying to run them.

The easiest thing to do would probably be to build an example application and test it.

[Ben]

Yes, test it for yourself. I had similar concern but was suprised that my LV 7.0 app was able to interact with embedded LV 6.1 RT apps without an issue. I think Rolf said something like "major versions such as when the storage fromat for data changes" would force an upgrade.

So try it and please let us know what you find.

Ben

[tbd]

Thanks guys.

      If we can't plan on backwards-compatibility of future versions of VI Server (2010,2011, etc)  then we may avoid using it.

I'd be surprised (but interested) if NI exposed a lower VI Server "layer" (like a TCPIP API) to resort to if a future version of VI Server stops working with deployed applications.

Thanks/Cheers!

[rolfk]

There was once a VI server version incompatibility when going from version 5 .x to version 6.0 in that either a newer client could not connect to an older server or vice versa. Interestingly enough it was only in one direction and this was actually mentioned in the Upgrade Notes. I believe it had something to do with additional semi-optional authentification data being transmitted during the connection establishment (Open Application Refnum).

As far as I know there has been no such incompatibility since in the VI server protocol. Of course if you access properties or methods from a newer version that were not available in an older version it will fail. Another potential problem is when you try to access "private" properties or methods. Their network protocol format (if they allow remote invocation) may change at any time and you will understandably not see any mentioning of that in the Upgrade Notes.

Message Edited by rolfk on 04-22-2010 09:35 PM

[rolfk]

---

tbd wrote:

I'd be surprised (but interested) if NI exposed a lower VI Server "layer" (like a TCPIP API) to resort to if a future version of VI Server stops working with deployed applications.

Thanks/Cheers!

---

This is likely not going to happen. I have played around with this when LabVIEW 6.1 was actual by using Wireshark (then called differently) and even created some VI library that could in fact connect to a LabVIEW IDE through TCP/IP and do some simple things like query attributes. It's very tedious work, and I have long ago abandoned the work on that since it seemed way to much work to me to get everything right and my initial curiosity was already satisfied after I had proven that it could be done.

[tbd]

Hi Rolf,

      That's a great idea! - to use Ethereal I mean Wireshark to figure-out the VI-server protocol.  I'll mention it to my supervisor.  Our VI Server use is mostly pushing variables into an FP and I'm wondering if Datasocket might be a more robust alternative.  Problem is, the data still needs to get packed and I don't know whether Datasocket might use the same (possibly version-sensitive) typedefing  as VI Server to move data(?)

Thanks/Cheers!

Message Edited by tbd on 04-22-2010 03:56 PM

[rolfk]

---

tbd wrote:

Hi Rolf,

      That's a great idea! - to use Ethereal I mean Wireshark to figure-out the VI-server protocol.  I'll mention it to my supervisor.  Our VI Server use is mostly pushing variables into an FP and I'm wondering if Datasocket might be a more robust alternative.  Problem is, the data still needs to get packed and I don't know whether Datasocket might use the same (possibly version-sensitive) typedefing  as VI Server to move data(?)

---

Honestly I wouldn't say it is a great idea. Unless you think spending way to much time for figuring out something like this a great idea. 

The protocol is highly binary and involved. It helps if you know how flattened LabVIEW data looks exactly but that is by no means enough to figure out everything.

Datasocket uses a very different protocol that I haven't looked at as closely. It is supposedly a small subset of a protocol that was NI internally called logos and came from the Lookout application they had aquired at some time. I do think the shared variable protocol is also somehow derived from that logos protocol although I do not know if it is compatible in any way.