Remote Call by Reference Performance

[viSci]

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

[viSci]

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

[Neville D]

I don't have any answers to your questions, but in general I find VI Server calls to remote targets a bit flaky.

Sometimes they seem to be ignored by the target, generating errors. Especially if you have a bunch of them sequentially.

Example: I want to open a remote panel of the top-level VI on an RT target.

Trying to query top-level remote VI's name works most of the time (about 75%). At other times it will generate an error (that doesn't mean anything).

Anyway, I agree, all your questions are very relevant. Hope there are some answers out there..

Neville.

[Neville D]

I don't have any answers to your questions, but in general I find VI Server calls to remote targets a bit flaky.

Sometimes they seem to be ignored by the target, generating errors. Especially if you have a bunch of them sequentially.

Example: I want to open a remote panel of the top-level VI on an RT target.

Trying to query top-level remote VI's name works most of the time (about 75%). At other times it will generate an error (that doesn't mean anything).

Anyway, I agree, all your questions are very relevant. Hope there are some answers out there..

Neville.

[LAVA 1.0 Content]

I agree with Neville that these are interesting questions.

My experience with using VI served VI on RT systems was limited to invoking methods of an Action Engine running on the RT machine.

Aside from an issue with a queues created by the AE being killed when the comm failed to the VI server (RT killed queue when remote connection was closed) they gave quick responses ( no benchmarks to share). Another issue I had to implement was due to too much data coming in too fast (after comm restored the history was transfered as a read from the AE) and the central PC was experiencing an update flood. This was fixed by changing the AE to only transfer a limited number of updates rather than everything at once.

Back in the day of LV6 RT...

Using VI server to touch an AE "was the way to go".

Ben

[LAVA 1.0 Content]

I agree with Neville that these are interesting questions.

My experience with using VI served VI on RT systems was limited to invoking methods of an Action Engine running on the RT machine.

Aside from an issue with a queues created by the AE being killed when the comm failed to the VI server (RT killed queue when remote connection was closed) they gave quick responses ( no benchmarks to share). Another issue I had to implement was due to too much data coming in too fast (after comm restored the history was transfered as a read from the AE) and the central PC was experiencing an update flood. This was fixed by changing the AE to only transfer a limited number of updates rather than everything at once.

Back in the day of LV6 RT...

Using VI server to touch an AE "was the way to go".

Ben

[viSci]

I am using a NSV with buffering to send commands from the host PC to one of 2 cRIO's. The cRIO then uses VI Server to make a Remote Call by Reference to a Return Notifier Proxy on the PC that completes the transaction. In my stress testing I have yet to miss a transaction with a roundtrip time of ~50-75ms. It appears that the NSV transaction is very fast with the bulk of the

time taken by the Remote Call. BTW, I am caching the Remote Call and NSV Datasocket references.

[viSci]

I am using a NSV with buffering to send commands from the host PC to one of 2 cRIO's. The cRIO then uses VI Server to make a Remote Call by Reference to a Return Notifier Proxy which completes the transaction. In my stress testing I have yet to miss a transaction with a roundtrip time of ~50-75ms. It appears that the NSV transaction is very fast with the bulk of the

time taken by the Remote Call. BTW, I am caching the Remote Call and NSV Datasocket references.

[Rolf Kalbermatter]

QUOTE (sachsm @ Jan 14 2009, 07:44 PM)

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

I did look at the VI Server remote protocol some time ago (around LabVIEW 7) to the point were I had an almost working LabVIEW VI library communicating to a VI server and that is what I found:

1) All input terminal data is packed into a single packet. Same about the output terminal data that is sent back.

2) Some header, with data length information about the packet and a packet type identifier and then the data mostly packed using the LabVIEW flattened stream format.

3) No real idea. I would guess that the VI server was at least back then running in the UI thread. It may not be anymore but that has all kinds of implications with data handling towards the rest of a VI diagram.

4) client requests some action using a single packet where all necessary data is included and server answers with another packet with all relevant data in. So it is basically one packet per VI server transaction in each direction, with VI server transactions being Open VI Reference, Read/Write Attributes, Execute Method, Call By Reference, and Close Reference.

So I think the VI Server protocol is about as efficient as it can be. The only problem I had with using VI server on embedded systems was with an old Fieldpoint Network Module recently. Had hoped to take a shortcut by simply enabling the VI server protocol on it and just execute VIs remotely to interact with the controller from the host program. However that did kill the performance of the FP controller so much that even if I did not actively interact with the VI server my main control program on there was starting to lag badly. Solution was to implement some extra methods in the already existing TCP/IP server that I had programmed in that application for reading and writing data points from and to the tag engine on it. After that and disabling VI Server the application on the controller behaved fine.

And before you ask: No the VI Library I have worked on is not available for review.

Rolf Kalbermatter

[Rolf Kalbermatter]

QUOTE (sachsm @ Jan 14 2009, 07:44 PM)

I am trying to optimize my cRIO -> PC remote call performance.

Does anyone know what is going on under the hood when a remote call is executed.

Here are some things I am wondering about:

1. How is connector data bundled up and converted to a TCP/IP payload

2. What is the structure of the VI Server Protocol

3. What is the threading model of the VI Server

4. What would a transaction timeline look like

TIA

I did look at the VI Server remote protocol some time ago (around LabVIEW 7) to the point were I had an almost working LabVIEW VI library communicating to a VI server and that is what I found:

1) All input terminal data is packed into a single packet. Same about the output terminal data that is sent back.

2) Some header, with data length information about the packet and a packet type identifier and then the data mostly packed using the LabVIEW flattened stream format.

3) No real idea. I would guess that the VI server was at least back then running in the UI thread. It may not be anymore but that has all kinds of implications with data handling towards the rest of a VI diagram.

4) client requests some action using a single packet where all necessary data is included and server answers with another packet with all relevant data in. So it is basically one packet per VI server transaction in each direction, with VI server transactions being Open VI Reference, Read/Write Attributes, Execute Method, Call By Reference, and Close Reference.

So I think the VI Server protocol is about as efficient as it can be. The only problem I had with using VI server on embedded systems was with an old Fieldpoint Network Module recently. Had hoped to take a shortcut by simply enabling the VI server protocol on it and just execute VIs remotely to interact with the controller from the host program. However that did kill the performance of the FP controller so much that even if I did not actively interact with the VI server my main control program on there was starting to lag badly. Solution was to implement some extra methods in the already existing TCP/IP server that I had programmed in that application for reading and writing data points from and to the tag engine on it. After that and disabling VI Server the application on the controller behaved fine.

And before you ask: No the VI Library I have worked on is not available for review.

Rolf Kalbermatter