Pass an argument from C program to Labview

[BenSpd]

Hello,

I have been searching for an answer to a problem I am trying to solve.  I have a C program that currently works with some older code that must stay in place.  I am trying to find a "simple" addition to this code that will include a dll or some other form of passing the command line argument of this program to labview.  I have not found any direct connection from C to Labview and the dll variables that I can share with C or with Labview are re-initialized with every call of the dll so the value is lost in between.  I apologize if this is too vague.  I'm trying to use VC++ 6 and LabView 2009.  Thanks in advance.

[smercurio_fc]

I can't say that I completely understand what you're trying to do. What do you mean by passing a command line argument to LabVIEW? Are you talking about calling LabVIEW from the DLL? I'm not sure because you're also talking about what sounds like wanting to keep the values of variables "saved" with each DLL call. That would indicate that you'd need to have static variables in your DLL. Do you have these?

[BenSpd]

What I am trying to do is having a Labview program running and waiting for an update to a variable that is received into a separate C program.  I have to get that variable from the C program to my Labview program.  I'm trying to use the dll as a middle step.  Labview should just watch for the change in the value, or another run indicator if the value is the same as last, and perform it's process when it gets that instruction.  I've been trying several examples such as #pragma data_seg and multiple exports.  I don't have any static variables, but I understand that dll variables are initialized at each call of the dll? is that correct?

thank you for your reply!

[nathand]

I'm still unclear on your situation; correct me if I've misunderstood.  You have a C program, including source code, to which you want to make a slight modification to allow it to pass data to LabVIEW.  You also have a LabVIEW program that runs concurrently with your C program, and it needs to receive data periodically from the C program.  You are trying to find a simple way to pass the data.  Is this correct?

If I've described your situation accurately, consider the following: build a LabVIEW DLL that you can call from your C program.  Have that LabVIEW DLL use VI server to open a connection to the long-running LabVIEW application.  Through VI server you can easily pass data and trigger something to happen.  You could have a functional global variable that gets its data from the DLL and is polled by the LabVIEW application, or you could get more sophisticated and use a notifier to signal that new data is available and it should start a new run.

Also, I don't understand your statement about DLL variables being reinitialized at each call - were you trying to use variables in the DLL for inter-process communication by setting a variable in one application and reading it in the other?  You can save data between calls to a DLL within a single application, but not across multiple applications.

[BenSpd]

That is what I am trying to do.  I apologize again for my vague explanation.  I need a way to get the info given to the C program to my LabView application.  I had not realized that a LabView dll could be set up to act differently than a C++ dll.  I also do not have any experience with VI server operations.  Once the LabView program I am trying to get the C program information to has finished, will I be able to send the result back to my C program?  Can the VI server and dll accomplish this?

You are also correct about the path I was trying to take with the dll variables.  I had run into the problem of each calling program getting it's own copy of the set of dll variables and not being able to "see" the changes made to the variables of the same name, but different memory location being used by the C program.

Thank you again for your reply!

[nathand]

---

@BenSpd wrote:

That is what I am trying to do.  I apologize again for my vague explanation.  I need a way to get the info given to the C program to my LabView application.  I had not realized that a LabView dll could be set up to act differently than a C++ dll.  I also do not have any experience with VI server operations.  Once the LabView program I am trying to get the C program information to has finished, will I be able to send the result back to my C program?  Can the VI server and dll accomplish this?

---

It's not really a difference between a DLL built in LabVIEW versus a DLL built in another language, except that writing it in LabVIEW gives you access to all the nifty LabVIEW features like VI Server that make it easy to talk to another LabVIEW application.  What you'll do is put a VI that can hold data (a functional global variable) in your LabVIEW application.  Your DLL will open a reference to the VI inside the application and run it, loading it with data.  Then your application will call it and read the data back out.  As a variation on this, your application can store an event or notifier reference inside the functional global so that your DLL could then trigger the event or send a notification, causing your LabVIEW application to respond.  For sending data back to the C program you can do the reverse - your LabVIEW application writes to the functional global and the DLL reads from it.

Another easy way to implement inter-process communication is through TCP or UDP (for use on the same computer, I like UDP because it's simple and fast).  The LabVIEW application waits for data on a UDP port.  The C program sends some data, then waits for a response.

The simplest form of inter-process communication I've seen is writing files.  One application scans a directory repeatedly for a file with a certain name.  When it sees it, it reads the data, then deletes the file.  It's not efficient for fast data transfer but you if need to transfer data infrequently it can work, and it's easy to implement in both C and LabVIEW.  On the other end of the complexity scale you could use Windows shared memory if you need to share a lot of data between programs as fast as possible, or you feel like you need a good challenge.  I started looking into this once and quickly decided it would not be worth my effort.

[BenSpd]

Thank you again for your reply.  I am trying to implement a very simple example of the process as I understand your explanation of it.  At this point I have a simple C program to pass a variable, and a simple VI that I used to build the dll that will only accept a value and place it in a global variable.  I am attaching my code and a screen shot of the basics I am trying to implement to get your suggestion working.

The idea of writing files and checking for them, deleting them, and writing new ones had come to me, but this would cause the hard drive to run nearly continuously.  The idea is reserved as a last resort for now, but may become reality if I am unable to implement this process.

[BenSpd]

I have already spotted one problem.  I used a regular global variable instead of a functional global variable. 

[Jervin Justin]

You could also potentially use TCP communication to send data from the C program to the LabVIEW VI.

Read the following article here:

LabVIEW Add-on Dev Center » Inter-Application Communication » TCP

LabVIEW Add-on Dev Center » Inter-Application Communication » Inter-Application Communication using ...

For more on other methods of interprocess communication (passing data between LabVIEW and another process):

LabVIEW Add-on Dev Center » Inter-Application Communication

http://decibel.ni.com/content/docs/DOC-9136

Inter-Application Communication

Inter-Application Communication

[F._Schubert]

The challenge I see is, how to monitor if both instances (the C-program that writes and the LV-program that reads from the global/FGV) are running. The safest solution I'd say is to use TCP. But this depends on your requirements (should C run when LV is not present, other combinations). With VI-server this is possible as well (the dll launches the main LV app in a seperate instance?). If you use FGVs/AEs, you can use VI server in a next step, so this would be a design that allows for good scaling when new specs are introduced (networking, ....).

Felix