Best approach for a cross language application

[minnellac]

I am working on a project where we are planning to write the data acquisition code in LabVIEW, but the rest of the application is being written in C# by some developers that are unfamiliar with LabVIEW. I am looking for suggestions for the best architecture for this kind of application.

Traditionally, in my LabVIEW applications that require UI, data aquisition, logging, and analysis, I generate a tiered producer consumer architecture. I usually build a queued event driven producer/consumer, and then create additional consumer loops to handle data as it propogates out of the acquisition loop. In this project, I am basically looking to only create the acquisition loop in LabVIEW, with the rest of the "loops" being generated by the C# guys using .NET 4.0 CLR.

The original plan was to make my loop as I usually would in LabVIEW and build it as a .NET interop. I hadn't really sorted it out yet, but the plan was to basically get configure and start commands from the C# gui (not sure how to replace the queue here), and use some event to get the analysis parts of the program to trigger at appropriate times based on data availability. It's come to my attention that LabVIEW generated .NET interops can not run in 4.0 CLR applications though, so I'm looking for alternatives.

Basically, I'd like to hear about similar applications and what has worked and not worked. I'm particularly interested in good approaches for interprocess communication between LabVIEW and a .NET app, and also any thoughts on triggering actions in the .NET app from the LabVIEW portion (can this be done without the .NET code polling something?).

Thanks!

Chris

[tst]

I have no experience with this, but here are some thoughts:

1. Build your part as a DLL. They will start it running with one function you provide and will pass along commands using other functions.
2. Use a web service for the IPC part. They will probably still need to poll, but I assume there's lots of code for handling web services in .NET.
3. Maybe they can pass you a reference to a .NET event which you can then trigger? I've done the same process in reverse (i.e. I pass a LabVIEW event reference to C++ code which then uses that to generate events in LV).

[minnellac]

Thanks for the input Tst. I am thinking along the lines of #1. Given the quantity of data I will be moving around, I'm not sure that the web service stuff would be efficient. I don't know that much about it though. Either way, it seems like we might be able to pass a reference to the bulk data around by pointer with the first approach. #3 is more along the lines of what I was thinking at first. In the past, I've only done this in reverse (the same as you), but it seemed feasible; now that I know I can't create a .NET Interop from LabVIEW, I thought that option was lost to me. Is there a way to trigger a .NET event that they have registered from within a C dll?

It is very reassuring to me that your thinking is paralleling mine. If I make my application into a dll, I can use a pretty normal architecture (for me) and create c functions that place commands into my normal queues. I guess the parent process would have to poll something to check for the readiness of my data queue, but that isn't so bad.

Chris

[HJPhilippi]

Hi Chris,

---

C. Minnella wrote:I'm particularly interested in good approaches for interprocess communication between LabVIEW and a .NET app, and also any thoughts on triggering actions in the .NET app from the LabVIEW portion (can this be done without the .NET code polling something?).

---

whenever it comes to communication between windows applications, I don't stop recommending the highly underrated Microsoft Message Queue (MSMQ) infrastructure and in my opinion, it actually screams to be used in your scenario:

1. Let LabVIEW collect the data and place it into a designated data queue.

2. Let C# exe attach to queue and do the data retrieval/evaluation/storage/whatever by OnMessageReceived events.

3. Let C# send control messages to a second queue, that is read by LV.

MSMQ is increadibly easy to use, yet very powerfull and has so many aspects and benefits for interprocess communication, especially between different machines in a LAN - a real pity that it's so little known. Just have a look at the following thread, especially at the tiny LabVIEW example I've placed there: http://forums.ni.com/t5/LabVIEW/MSMQ-with-Labview/m-p/154334

This could be done better on the LabVIEW side (event based rather than polling), but as you just want to send some configuration and control commands, it's okay like this.

Unfortunately, there are not too many good resources about MSMQ on the web that explain the coding basics well.The MSDN magazine has some great articles if you're somewhat experienced (like http://msdn.microsoft.com/en-us/magazine/cc163920.aspx ). What I found really helpful and gives a great introduction is this book: http://amzn.com/1590593464

Give MSMQ try and have fun with it!

Cheers,

Hans