Best Method for Reconnectable Host Communication?

[Jordan Kuehn]

Here's hopefully a simple question:

What is the best method for communicating with an RT target with a Host controller (windows) that may reconnect at any time? Network variables, Remote Panel, Web Services, tcp, udp?

I've used network variables and networks streams plenty, but network variables just don't seem reliable enough and network streams hang when connection is lost. Remote Panel and Web Services seem attractive due to the fact that everything is hosted on the target. I don't need deterministic control on the host interface, just a decent UI.

Thoughts?

Edited March 22, 2011 by jkuehn

[viSci]

I use NSV's all the time and they are reliable when used correctly. If RT hosted NSV's drop off the network then you will receive definite error messages to that effect on any static or dynamic NSV R/W node.

Once the RT controller comes back on line NSV's automatically reconnect and become viable. Also any HMI controls or indicators can be easily set to blink or display a red PSP status if the binding NSV goes offline.

[bgapske]

Here's hopefully a simple question:

What is the best method for communicating with an RT target with a Host controller (windows) that may reconnect at any time? Network variables, Remote Panel, Web Services, tcp, udp?

I've used network variables and networks streams plenty, but network variables just don't seem reliable enough and network streams hang when connection is lost. Remote Panel and Web Services seem attractive due to the fact that everything is hosted on the target. I don't need deterministic control on the host interface, just a decent UI.

Thoughts?

A couple of my recent projects involve a number of RT targets and a central Host (or another RT target)

I tend to prefer basic TCP for a couple reasons. Mostly because my RT targets have been pretty taxed when it comes to computing resources, and with TCP you can get high throughput with little overhead. (and you don't have to install the services that support shared variables,remote panels, web services, etc if you don't use them)

One of my systems works similar to an example in the NI Simple Messaging Reference Library. I have the RT target acting as the “server” and listening for connections from the host. When the connection goes down, the RT target stops trying to use it and waits for the host to reconnect. I’ve had no issues with this to date. I can leave my targets running and connect to them whenever I want with the host application.

The other reason I prefer TCP is that one of my systems (which I inherited) makes heavy use of NSV and remote panels and I’ve had a horrible time debugging it. This could very well (and probably does) have more to do with the way the code was written rather than NSVs or Remote Panels themselves, but the experience has left a negative impression with me. Warranted or not.

The downside of TCP of course is that you may have to write more code.

I do like that you can view the values of NSVs in the System Manager.

[JamesMc86]

Here's hopefully a simple question:

What is the best method for communicating with an RT target with a Host controller (windows) that may reconnect at any time? Network variables, Remote Panel, Web Services, tcp, udp?

I've used network variables and networks streams plenty, but network variables just don't seem reliable enough and network streams hang when connection is lost. Remote Panel and Web Services seem attractive due to the fact that everything is hosted on the target. I don't need deterministic control on the host interface, just a decent UI.

Thoughts?

Have you considered web services with the new UI builder? Check out ni.com/uibuilder. I used to find that web services still needed quite some work around them but for me for basic display of data and control this works really nicely and means that your client needs nothing other than a browser with silverlight.

Other than that I tend to go with basic TCP to transfer a lot of data and have a loop to act as the server that will wait on a connection externally and act accordingly when the client is present.

Cheers,

James Mac

[Neville D]

I've used network variables and networks streams plenty, but network variables just don't seem reliable enough and network streams hang when connection is lost.

In my experience, they are quite reliable; most bugs have been traced to code other developers have written, rather than any issue with the shared variables themselves. Couple of points:

1 "Important" (regularly updated, critical) shared variables are read using the DataSocket API, where I connect to the SV engine on the RT target, and then monitor the status of my connection. If it goes down, I reconnect, kind of like a TCP loop. The read values are then Q'ed. Prior to implementing the reads in this way, I would get SV's go down when the RT target was being rebooted, and they wouldn't "reconnect" without restarting the HMI (PC) application.

2 Once connection is re-established, the other static Shared variables seem to connect without a problem. Runtime for built executables (between reboots) can be 8 or 9 days.

3 The Shared Variables are hosted on the RT target and number about 70 or so; some are complex clusters, others are SGL's, DBL's, and even an IMAQ image flattened as a string. Some values are buffered, others are not.

Here are some screenshots:

Neville.

[Abdullah R]

In my experience, they are quite reliable; most bugs have been traced to code other developers have written, rather than any issue with the shared variables themselves. Couple of points:

1 "Important" (regularly updated, critical) shared variables are read using the DataSocket API, where I connect to the SV engine on the RT target, and then monitor the status of my connection. If it goes down, I reconnect, kind of like a TCP loop. The read values are then Q'ed. Prior to implementing the reads in this way, I would get SV's go down when the RT target was being rebooted, and they wouldn't "reconnect" without restarting the HMI (PC) application.

2 Once connection is re-established, the other static Shared variables seem to connect without a problem. Runtime for built executables (between reboots) can be 8 or 9 days.

3 The Shared Variables are hosted on the RT target and number about 70 or so; some are complex clusters, others are SGL's, DBL's, and even an IMAQ image flattened as a string. Some values are buffered, others are not.

Here are some screenshots:

Neville.

Neville

Great post.

Is it possible for you to share what you are doing in "Analyze Datasocket" VI?

Paracha

[Neville D]

Neville

Great post.

Is it possible for you to share what you are doing in "Analyze Datasocket" VI?

Paracha

Paracha,

that VI's operation is not relevant to the Datasocket communication illustrated. Its just some housekeeping on the data acquired.

N.