A C#.NET program on a PC communicating to a myRIO

[Peter_B]

Hi there,

I would like a C#.NET program running on a PC to communicate with a myRIO.over its USB cable ?

Am I limited to using Network shared variables, TCP/IP and UDP ?

Where do I find the C#.NET API for this  ?

What would be the worst case latency (over the fastest comms option available - UDP ?)  if I wanted the C#.NET program to send a command to the myRIO to output a digital signal ?

[even-And · Accepted solution]

Hey Peter_B

Shared variables, TCP/IP and UDP, and network streams are your best options for communicating between the PC and myRIO

The .NET API can be found here

More information about basic network protocols can be found here

What exactly are you doing with this myRIO? MyRIOs are generally used for student projects

[Peter_B]

Thanks even-And,

I have the myRIO handy and it is for a rapid prototype.  I can move it across to a CompactRIO platform as required once the prototype is done.

Also I will be controlling some solenoid coil currents and this myRIO accessory is ready made for me to do that

http://store.digilentinc.com/motor-adapter-for-ni-myrio/

.

[Peter_B]

In summary can you tell me if Network Streams are definitely supported in that API found here ? 

I'd like to avoid Shared Variable for various reasons (bad experience with them in our company from prior efforts - rightly or wrongly).

I will be sending messages and commands, so guaranteed delivery is important, thus UDP is out.

This leaves TCP/IP or Network Streams or  Simple TCP Messaging (STM)

LabVIEW supports all three and I would prefer to user Network Streams for ease of use, but what is available in the .NET land ?  Are Network Streams definitely supported in that API found here ?    This post suggests they are not available.

I know TCP/IP is in the NI-VISA .NET API, only downside is a bit more programming for host and clients to get them established (as per the "Ease of Use" classification here).  But I will use them if there is no API for Network Streams.

Finally STM reference design is here for .NET land but the lack of popularity for .NET is not that attractive to me.

[even-And]

It looks like Network Streams are specific to LabVIEW, sorry about misleading you in my earlier post Peter_B. But clicking around the .NET examples it looks our options in the .NET library are NetworkVariables and DataSockets. By the way Network Variables sound similar to Shared Variables so avoid those.

I did find a NetworkStream that's built into .NET. I honestly don't have experience with this in regards to myRIO 

[Peter_B]

Thanks again.

>I did find a NetworkStream that's built into .NET. I honestly don't have experience with this in regards to myRIO 

Unfortunately that is just a co-incidence that the names are the same.

So I will probably go with TCP/IP.

[Peter_B]

---

Finally STM reference design is here for .NET land but the lack of popularity for .NET is not that attractive to me.

---

Interestingly, the crio developer's guide recommends to use STM for message or command based data between the crio (myrio) and a 3rd party PC application. (ref. table 4.3 in chapter 4 of the crio dev guide).  plus p. 68 has "STM is a networking protocol that NI systems engineers designed based on TCP/IP. It is recommended for sending commands or messages across the network if you are communicating to a third-party API or require a standard protocol. It makes data manipulation more manageable through the use of formatted packets, and improves throughput by minimizing the transmission of repetitive data. "

I don't look forward to "Dealing With Orphaned Sockets When Using TCP/IP " (p.71), I presume Network Shared Variables or Network Streams handles those disconnections automatically.  

[even-And]

Yea I agree. It sounds like TCP/IP might be the best option moving forward

[Peter_B]

A twist on my approach.  I've since decided to try using Network streams rather than TCP/IP.

this has less config. overhead than TCP/IP but most importantly it handles lost and re-established connections more nicely (it automatically reconnects), whereas with TCP/IP I would have to code a heartbeat plus reconnect code if the heartbeat is not detected.   From what I've read, I think there are a number of TCP/IP misbehaviours due to temporarily lost connections that are not detected.

So the only hurdle to using Network Streams is that NI don't offer a 3rd party API.    One of the local NI Application Engineers (Erich) coded up a basic/skeleton API for me that can be compiled into a .NET interop assembly for the C# code to call.  

This requires the API to be installed onto the host/server PC along with the LV RTE.

I have been testing out and coding more of the API library functions just using native LabVIEW for both the client and server and it is working fine.  Next week I will have our C# programmer  call up the .NET assembly on the server and see how well it goes.  Presuming no significant roadblocks this will now be my preferred method.

[even-And]

Thanks for the update. Sounds like you have a great path moving forward! Hopefully calling the .NET assembly on the server goes well