Multi-Client Network Communications Architecture

[BrentonLang]

Hi everyone,

I'm wanting to open up the floor for your opinions and past experiences with designing a network communications architecture.

- There will be one server, written in LabVIEW on a Windows based PC.

- There will be multiple remote clients programmed in LabVIEW on cRIOs.

- All devices will be connected via a wireless network, and all cRIO clients should have good throughput to the server.

- It should be designed for bidirectional data flow, however the clients will do most of the talking.

- Data sent will be, status packets, images, PDF documents, and other information.

- Clients will not be continuously sending data, such as a typical DAQ system, but more reporting on events.

I'm leaning towards the TCP socket option, but would like to consider higher-level forms of NI-propriety designs, such as Network Shared Variables or Network Streams, which I haven't had huge amounts of exposure to.

Thanks for your opinions.

Brenton

[Rolf Kalbermatter]

Hi everyone,

I'm wanting to open up the floor for your opinions and past experiences with designing a network communications architecture.

- There will be one server, written in LabVIEW on a Windows based PC.

- There will be multiple remote clients programmed in LabVIEW on cRIOs.

- All devices will be connected via a wireless network, and all cRIO clients should have good throughput to the server.

- It should be designed for bidirectional data flow, however the clients will do most of the talking.

- Data sent will be, status packets, images, PDF documents, and other information.

- Clients will not be continuously sending data, such as a typical DAQ system, but more reporting on events.

I'm leaning towards the TCP socket option, but would like to consider higher-level forms of NI-propriety designs, such as Network Shared Variables or Network Streams, which I haven't had huge amounts of exposure to.

I have implemented a system based on TCP communication in a similar way than the STM Reference Design from NI. Technically however the CRIO (CompactFieldpoint) is the server , and the PC(s) are the client. This has worked out quite well for isolated systems, meaning I haven't used it with a multitude of RT controllers on the same subnet. Instead what I have is typically one or two RT controller, that don't really talk to each other and one or more operator stations and touch panel monitors that communicate to the controller(s) over this link. The communication protocol allows of course data transfer of the underlying tag based system, similar to the CVT Reference Design, resetting and shutting down the controller, and also updating the CVT tag configuration. Since it only operates on isolated subnets I have not implemented any form of authentication into the protocol itself.

NSVs, or their bigger brother the Network Streams are interesting when quickly putting together a systems, but I like to have more control over how the system is configured and operating, and have even created a small Android client that can communicate directly through my protocol, something you simply can't do with proprietary closed source protocols.

[ShaunR]

You might want to take a look at Dispatcher in the CR which may give you most of what you want.

[BrentonLang]

NSVs, or their bigger brother the Network Streams are interesting when quickly putting together a systems, but I like to have more control over how the system is configured and operating, and have even created a small Android client that can communicate directly through my protocol, something you simply can't do with proprietary closed source protocols.

This is the main reason why I'm leaning towards a lower-level design. I'd like to have the flexibility to use third-party devices at a later stage. It would be nice, but not a requirement.

You might want to take a look at Dispatcher in the CR which may give you most of what you want.

This looks very interesting, I'll take a deeper look.

[viSci]

For large scale distributed systems, has anyone run into a limitation on the maximum number of allowable open tcpip ports on LVRT?

I am imagining a system that has a large number of cRIO servers connected to a single LVRT client.

[Shazlan]

Hi guys,

I've developed very few remote monitoring systems in the past. One of them was using a PXI RT and the rest are cRIO. The approach and architecture were based from some of the things I've read from ni.com and this forum. In the process, there were much difficulties and some extensive troubleshooting exercises that I need to do. The results, while the system work and meet the user's requirements, it didn't meet my own expectation. For instance, I was hoping that the system can be expanded (adding more cRIO or PXI) with much ease and little or no re-programming effort. Anyway, 2-3 years have passed and opportunities with similar requirements has emerged. So, I would like to get started to think about the architecture at an early stage (ie. now).

In my past systems, I've used NSV a lot - and it gave much much headache too. Some of the troubles I had were:

1. I can't decide whether to lump all SV in one library and host them in one system, or to separate them into various libraries and systems... neither do I know what's the best approach, as I've read too many 'suggestions' and 'advices',

2. Some of the SV are from custom control and the control is type-def. When running the VI in RT with these SV in development platform, everything works smoothly but when I compiled and deploy, the program didn't run. After extensive troubleshooting, I found out that this had something to do with these SV - because when I removed the type-def from the custom controls and recreate my SV, everything worked fine. I suspect this may have something to do with how I deploy but after I tried several approach, the problem still persist.

3. The best and most common of all is unstable connectivity - it work today but that doesn't guarantee it will work tomorrow. When the host PC changes, the same problems resurfaced again. I read somewhere that I need to read or interface with the .alias file but this work some times and other times, the same problem persist.

Attached is the most common architecture that I've used in the past. I would like to move away from NSV as much as possible. If the application is 1:1, there's no problem as I can easily use TCP/IP & Network Stream. However, my doubts and headache comes when the RT:Host communication is either 1:N, N:N or N:1. I've read in ni.com and found out that there are various new approach to this, such as STM, AMC (derivated from UDP), Web Services (or was it HTTP).

I really appreciate it if you guys share your thoughts and advices here, please?

Remote Mon Arch.pdf