09-24-2015 04:34 AM
Hi All.
My current setup is using a PCIe FPGA that communicates with a C# application using a custom C# wrapper. I’m using 2 R/W controls, each 32-bit integers to send various information such as commands back and forth between the FPGA and my C# application. In addition, I’m using 2 DMA channels to stream data from the FPGA. The data is 32-bit intergers.
We are now making some changes in the design, which means we will be using a RIO controller. This means the FPGA will communicate with the RTOS, and RTOS will then send the information using TCP/IP (local network) to the C# application.
Question:
I’m now looking for different options in which protocol to use for the TCP/IP communication. My hope is, that something nice and easy is already made. I would like to avoid sending strings, and the network streams are pretty nice, but since I’m communicating with a non-LabVIEW program, I cannot use Network Streams. I’m looking for a solution that can easily be ported to Linux if needed. Is normal TCP/IP communication my only choice?
Thanks.
09-24-2015 05:51 AM
Unless you use some of LabVIEW wrapper for a messaging library, you're probably best to develop some sort of string based protocol for sending/receiving the data. Something like JSON would keep it compatible with other languages, for example.
09-24-2015 06:11 AM
Thanks for your reply.
The idea is, that we will not create a custom LabVIEW wrapper this time. So we want a TCP/IP solution that C# natively supports. I will look more into JSON.
Any other ideas, or more information on JSON?
09-24-2015 06:40 AM
Well TCP just boils down to sending bytes of data and it's up to you to decide how to package that data - binary or ASCII. For ASCII string based protocols...obviously you can do all sorts of things like Flatten To String, Typecast (to string) but these produce data that isn't easily understood/converted by other languages.
If you're wanting to send complex/clusters of data - Flatten to XML would work but the LabVIEW XML format is very heavily bloated. Flatten to JSON (LV2013 onwards) is a fairly compact and easily human-readable format and is widely supported. You can just send basic strings as well.
You could also package your data into a binary protocol - but unless you need the efficiency it's probably best to stick with strings.
One thing you'll need to do is figure out how to determine the start/end of each message - one way to do this is to have a start & end identifier around each message or another common technique is to prepend the data length as an integer to the string you send.