Need help choosing a communicatin structure

[Henrik_E]

Hi all,

I am currently working with developing an automatic grading system for wood. For several reason we have chosen LabVIEW and the cRIO platform for data acquisition and machine control. The main application is however written in C#. There are several reasons for this but that's beside the point here. I just have to deal with it...

I am fairly new to LabVIEW development but I am experienced with C# and .NET programming.

The question I have is regarding the best way to interact between my exisiting C# application on the PC and the new LabVIEW application running on my cRIO chassi.

The data I need to transfer is simple messages like "new boad arrived", "board length is 3406 mm" and possible error messages. In addition to these messages a sampled analog signal containing 2048 samples need to be transferred up to 2 times per second. 

For the user experience I don't want the user to see a LabVIEW VI running in the taskbar of my PC.

I don't have Measurement Studio and I would like to solve this without getting it.

I have come up with two alternatives that I would like to hear your oppinion about:

1. My first alternative is to develop my own protocol of transferring data over TCP/IP. Simply make a VI that runs on the cRIO chassi and sends TCP/IP messages to my C# application. In my opinion is this a fairly straight forward approach. My concerns are that I need to put some effort in developing my own protocol and the scalability of the solution is not the best. What's your opinion?

2. My second alternative is to use a VI compiled as a DLL on my PC that reads network shared variables from the cRIO chassi. What do you think of this solution? Any special considerations to be aware of? How abot events from this DLL to trigger the C# application to read new data? Can it be done?

Are there any other alternatives that might be better?

Thank you

/ Henrik

[Broken_Arrow]

Hello Henrik,

You have a lot going on there, but let me just tackle one aspect of your post that perhaps you aren't aware of... You said:

For the user experience I don't want the user to see a LabVIEW VI running in the taskbar of my PC.

If you create an EXE, and make you own icons, the user will not be the least bit aware that it is (was) a LabVIEW job. In fact, if you stick to the System controls and indicators, there will be no hint of LabVIEW'ness.

[Henrik_E]

Hi Richard,

Thank you for your reply.

Perhaps I should clearify what I mean regarding the user experience. What I mean is that I don't want the uer to see two programs running. The entire system is running on an industial PC with a touch screen monitor and thus the user interface is limited. The C# application is already there since this new functionality is adding to an existing system that was written using C# and .NET

I (or my users) have no problem with the application looking and feeling like LabVIEW.

/ Henrik

[nathand]

I've used TCP frequently, and haven't done much with shared variables, so I may be biased, but I'd say the TCP option is a good, simple solution.  I took over responsibility for code that used datasocket for all its communication between an RT system and a PC and there were constantly minor annoyances; perhaps shared variables are better, but I find that TCP is easy enough that there's no need for an added layer on top of it.  Designing a protocol for what you want to do should be fairly straightforward; all you probably need to do is send a byte indicating the type of data that follows, another 4 bytes for the length of data, and then the data itself.  What are your concerns about scalability?  How do you see this expanding in ways that a TCP link won't handle?

[Henrik_E]

Thank  for your reply,

I'm more and more leaning towards the straight forward TCP/IP solution.

Anyone else have a better idea?