Control LabVIEW from different application

[daij]

I made an application that generates user requested amount of outputs and also takes parameters and IO controls from the user. It seems to me LabVIEW is a perfect tool for the user to do the screen layout. My question is once the layout is done, can I programmatically open the vi file and associate any of my outputs to the screen objects (for example an edit box or a channel of a graph etc.) and feed those screen objects with my data at run time? In other words, is there any APIs for LabVIEW so that I can go in to a vi file and interrogate its components’ properties and then getting or feeding values to/from those components during run time? Can it generate events when a user clicked on a button etc..?

Thanks in advance

Jian

[yenknip]

Do you mean you want to use LabVIEW as a WYSIWYG (what you see is what you get) User Interface designing tool, and export the panel layout to another programming language?

Or do you mean you want to import data from elsewhere, onto the user interface panel, then use LabVIEW to process the data further?

[daij]

Hi Ed,

I want the user to use LabVIEW to design the layout of the screen and save it to a vi file. In my application, I'll look into the vi file and find out its components (edit boxes, buttons, graphs etc.) I'll ask the user to associate my output to those components. For example, my speed output can be associate with trace1 of graph1, temperature goes to text box2, etc. After this association is completed, I'll run the vi file (just like you run a LabView application) and update those components (trace1 graph1, text box2 etc) with my data via some API call. For example: viObj.TextBox2.SetText(currentTemp) or viObj.graph1.trace1.AddDataPoint(currentSpeed). etc.

This is just one way to implement it. You might have different way. But the point is to be able to control the LabVIEW application from an outside application. Getting/Setting property of an object inside a LabView Application, calling methods of that object etc...

Jian

[yenknip]

What programming language are you using for the main software?

There is certainly no inbuilt APIs for what you are asking, although you may be able to create a portable XML file or something with LabVIEW scripting. If you are not familiar with LabVIEW then this will take a fair bit of learning and experimenting. The LabVIEW code for parsing the designed VI would need to be under the full licence, in order to use the scripting nodes, however the panel designs could be done in evaluation copies.

I did a similar thing to what you are asking in a C++ application a number of years ago, whereby the user designed their panel in a wxWidgets WYSIWIG. In the main application, I could simply #include the panel and populate and display it.

[yenknip]

Actually, having re-read your reply can I check we are on the same page:

The user aquires some data

The user creates their VI interface panel

The user defines what data is going where

The user runs their VI

LabVIEW then continues and processes the data further?

Getting data from elsewhere into VI controls is no problem at all. 

Allowing the user to design a panel completely from scratch will take quite a bit more. It would be possible for the user to create their VI, and import it into a 'SubVI' window, or run it dynamically, in a parsing LabVIEW application. Scripting nodes would be able to interact with the child panel and a large amount of runtime manipulation is *possible* although not strictly supported.

The leading question is how familiar are you with LabVIEW?

[daij]

You summarized pretty good. But the sequence is like this:

User knows what data (from my application) he wants to show

The user creates their VI interface panel

The user defines what data (from my application) is going where

The user runs their VI

Loop: my application acquires user specified data and update objects inside VI continuously

No further LabVIEW data process.

I’m C/C++/C# guy. Not that familiar with LabVIEW. But if you think what I want to do is possible, please give me a pointer and let me read up on it. You mentioned “run it dynamically, in a parsing LabVIEW application”, is this parsing application my application? Another question is what the performance penalty is when I update graph from “parsing application”.

Thanks,

Jian

[yenknip]

If it is just for displaying data in a way that the user can customise, I would reccommend you just stay with what you are familiar with. I mentioned a few posts ago that I know for a fact that you can #include a GUI panel resource into a C++ runtime application.

If you do want to run the viewer in LabVIEW, then unless each user is a skilled LabVIEW developer, you will need to run their uncoded VI through an intermediate or parsing LV application which will act as a bridge. This will need to be written in LabVIEW because a VI is saved in a format native to LabVIEW.

I might be able to make a demo on Monday, but for now an abstract description if anybody else wants a quick crack at it;

You could create an opc server (or another data sharing technique) on your data aquisition application, the LabVIEW bridge application will then be able to pull data in. 

The bridge application can dynamically get a list of controls from the user panel, and users will be able to tell the bridge what data to pull from the opc server and where to put it.

There will need to be data sanitising; checking imported data types are suitable for where the user wants to put them.

After finishing any configuration, the bridge app will continue to pull in data changes and drop it into the uncoded User Interface panel using the VI server nodes.

Jian, for now you can read up on LabVIEW introduction courses (link, link), and then search for info on the VI Server

[daij]

Thanks for the links. I'll study that. What do you mean by: "#include a GUI panel resource into a C++ runtime application"? Can you point me to the documents for that?

[yenknip]

Hi Jian,

Sorry I haven't replied yet; I've been inundated with jobs at work. 2 lunchtimes of fiddling suggests that this project will be a little involved, and will certainly add unnecessary overhead to the project as a whole. I'm going to stick with what I said about keeping it in one language; C++ or learning LabVIEW.

Perhaps you create a generic panel, and allow users to show/hide, enable/disable elements, and select suitable elements for data structures?

You would probably get better help about importing an uncompiled resource at runtime in a language specific help forum - I haven't really touched C++ for some years now.

If you do have the time to learn a new programming language, then many of the LabVIEW enthusiasts would gladly drag you to the land of multi coloured wires. From your description, it suggests that your other application is just dealing with data aquisition, and this is where LabVIEW excels. It is very quick to draw up a program to grab data.

[daij · Accepted solution]

Hi Ed,

I've found a solution to my problem. I'm going to use LabWindows and it provides everything I need. The only downside is that eventually the end-users have to use LabWindows, rather than LabVIEW, to generate their custom panel. I prefer LabVIEW since most businesses already have it. Good for NI...I'll see how much commission I'll get from NI's extra LabWindows sale. 🙂

Thank you for all your help!

Jian