Leaderboard

We have used NS on a project recently with a cRIO and we found a few caveats that we were not expecting: The NS engine uses ~10% of each core on the cRIO (9067) as soon as a connection is established (we had three streams) There is also an impact on the host CPU, even if very little amount of data is transferred All NS are unidirectional and limited to one connection (based on your description, you are better off with TCP) The NS properly register that the end point is disconnected ONLY if the connection ends gracefully (completing executing on the Host for example.) If you disconnect the network cable, neither the Host nor the cRIO registered the problem automatically and the stream no longer worked when the cable was reconnected. You would need to build that yourself... Memory management in the NS is less than ideal. One of our NS was transferring arrays and we had set the depth of the NS to 100k elements. LV thought it was a good idea to go through each of the 100k in the buffer even is there was ever only 1 or 2 arrays in the buffer. The result was that both the cRIO and the PC were trying to allocate >1GB of memory space that it didn't really need. Sure, bad programming but you would hope for better reaction than what appeared, for the longest time, to be a memory leak. If your messages are long and you create a large buffer, expect to run into strange problems down the road for obscure reasons... I would suggest you go straight to the TCP method. It will require a little bit more work upfront but you will have more flexibility, less overhead on the CPU and the ability to handle multiple connections easily. NS is great at delivering a simple option to quickly get started with and streaming large amount of data in simple situation but doesn't offer much IMHO benefit over TCP when scaling up.

For most of my cRIO applications, I've been able to deploy all software onto the cRIO and control it through an RS-232 command/reply interface with commands general enough they can utilize most of the I/O for the system, but narrow enough that only intentional misuse would be able to do anything destructive with the signals. Thankfully, I'm mostly working with test equipment, and the systems which are controlling the tester through RS-232 are behind quite a bit of firewall. If I were in a different environment (Ethernet connection preferred, non-controlled engineer interacting with my interfaces), I would look into encrypting/decrypting command/response pairs, having the embedded software interface be less generalized, and each command only able to perform tasks which will not hurt the system or endanger anyone (with a much larger set of commands needed). Reducing the scope of "acceptable" commands (case-sensitive, defined command length, etc...) would also reduce someone attempting random commands' ability to tamper with the system. Depending on the application, I might use a cloud service. I would just assume that the controller of the cloud service had access to all information stored there, no matter the encryption level.

Network streams are built on top of TCP. It provides a simpler interface than TCP for streaming data point-to-point, at the cost of losing the ability to listen for multiple connections. It's nice to be able to dump an array of doubles in one end and get the same array out the other end, without having to search for data boundaries and reinterpret bytes. We are currently developing a system that controls and monitors a pilot plant, using CompactRIOs and CompactDAQs connected to a central PC server. There are a large number of I/O points, a number of which need kHz sample rates. The cRIOs and cDAQs use network streams to transfer the waveform data to the server for logging. Also, our customer wants to allow an arbitrary number of client PCs to view the logged data. The server accepts requests from a client via raw TCP, taking advantage of the TCP Listener function. Once a request is received, the server sends a unique ID to the client to establish a network stream for transferring the waveform data.