jeffwass

Okay, I'm already using those methods, I actually implemented a GOOPish kind of LV2 that maintains an array of 'object' references, which can take a variety of commands. I also use the producer/consumer type model, but with TWO consumer queues, one where FP commands pop onto the main acquisition-processing queue, and another queue in which any subroutine can pop commands to update the main GUI display. That works pretty well so far for things like the list of instruments, a tree for list of routines with some config data, but haven't gotten the actual acquired-data visualization stuff worked out yet.

This is the way I'd like to do it, I don't like working with the subpanels. THe thing is the data types, amount of data, etc, will be variable and depends on the subroutine running. So sometimes I'd want to display an XY graph, sometimes strings, sometimes an array of floats, etc. But what would be a decent architectural way of moving data to the FP of ther other VI? Since the datatypes are always changing, maybe it is desirable to use the subpanels ,though. But when you say move the data to the UI, what are the best ways for doing this? I figured I could send some references to the acquisition program, and send raw data to the UI that way, not sure if this is the best way. BTW - does anybody else think that the LabVIEW manuals tend to be pretty bad for describing functionality? Ie, I don't have any idea what the Data Sockets do or how to use them, and I also find their descriptions of thigns that could be useful like the TDM and INI files to be pretty bad too.

The thing is I'd like to be able to display the raw data at any level of a bunch of nested routines. How do you typically do this? I wanted everything to be available from the main window, previously I'd have to go and find the subVI executing and open that to look at the graph on it's front panel, for example. So when I've got several nested routines, this gets annoying, so I figured a tab control can display the data for the various routines. And since the subroutines, especially the type of data (graph or scalar, or even 2-D intensity graph), so I figured I can put the appropriate indicators onto a tab control.

Ahh, I never use those, I guess it was ingrained in my learning that they're bad, so I've just opted for LV2 (or USR) globals instead.

IMHO, I like Unitialized-Shift-Register Globals, because it accurately describes what the structure is. However, this terminology is a bit long, so I'd suggest using USR Global. That's no longer than LV2 Global, and more accurately describes the concept (when the user knows what USR is). I don't like calling them 'old globals' because it implies there's something newer and better. And while the global variable routines are certainly newer, from what I understand they're to be avoided as much as possible. This terminology also accuretly refers to such a global, whether it's intelligent, functional, or not. BTW - does anybody use such one USR (or LV2) global VI for several global variables, by using a variant as the shift-registered data, and with commands like "GetValue" and "SetValue", where the name of the appropriate global parameter is used as a variant attribute name, and the data is the variant attribute variant itself? I've found this to be quite powerful, and then only need one (or a handful) of globals for a large hierarchy of VI's.

For LabVIEW 2 globals, if that's what you're referring to, I just use them as regular VI's, with VI extension, etc. However, I use the filename like InstrGlobal.vi or something similar. Perhaps, in retrospect, it would be better to put the Global as the first part of the name, so all global routines in the hierarchy would be grouped together when browsing. I also have some kind of pic of a globe on the VI icon, so it's obvious when looking at the BD it's a global.

Ahhh, okay. I'll play around with that a bit, haven't done much GUI-based scripting like this yet. BTW, do you think my idea of displays in a tab control on the master VI sounds like a reasonable thing? The routine VI would basically have a reference to the appropriate display indicator on one page of the tab control on the main VI, and then update it. It looks like datasockets might have been designed to do this sort of thing, but I haven't found any good documentation on datasockets.

I was actually just about to ask this question in general, and after coming to LAVA User Group today, I found you happened to asked a nice segway question yesterday. So here's my question - does anybody know how to ADD controls to a tab page programmatically? I can see how to READ the controls on any page of the tabs, but I'd like to put them in programmatically. I'm working on a large-scale data acquisition program, and depending on what kind of routine I'm running, I'd like to put that in a page on a tab control. But the routines aren't known a priori. Ie - I might have sweep one kind of variable (eg, a magnetic field). Then at each field point sweep another variable, say a heater. So it's a nested loop structure. Then at each of those points I'd measure my device, say take an I-V curve. So I want one tab to show the data from the first sweep, another tab to show data from the nested sweep, and another tab to show the I-V curve data. So I'd like that each time I add a new routine, a new tab is added to the main VI's front panel showing the appropriate data for that routine. However, I cannot find out how to add the controls to the page, or even how to add number of tabs, programmatically. My old method involved having a separate main VI for every type of routine, but this quickly proved itself to be a mess and difficult to maintain. Especially for all the different equipment combinations in the lab. Additionally, there were getting to be too many controls for the front panel, so I just bit the bullet and designed a Test Executive suite. I'm using LabVIEW 7.1, if that matters. Does LabVIEW 8 offer any more advantages along these lines?

Come on, don't be Mean to the guy

Hi, I currently have LabVIEW 7.1 installed in my lab, but I'd really like to move over to LabVIEW 8. What are the implications of downloading and running the LV8 download that is being linked in this thread? Ie, do I need to purchase new licenses, or can I re-use my old ones, etc? Thanks.

Ah yes, exactly what I was looking for, thanks.

Does anybody know of a decent way to get rid of a loop (eg While or For) but keeping the G components and wires within the loop in the place they are? It's quite often I want to do this, and while I can cut and then paste, it messes things up, especially if the contents are within another larger loop, which it resizes and blocks other things, etc. It's nice that one can draw a loop around some G constructs keeping them intact, and I often would like to do the reverse.

Does anybody know how to add new controls to a tab pane? I am working on a test-executive, and I'd like to have LabVIEW choose which graph to display, depending on what kind of data the user is taking. Ie, either chart or 2-D color graph, etc. Also anybody know how to add/delete tab panes dynamically? There don't seem to be these options w/ the properties/methods of the tab. thanks.

Hi Anton, what it sounds like you are looking for is a way to script LabVIEW. You should look at LuaVIEW, which allows one to create Lua scripts that can be accessed from LabVIEW. In other words, you can edit variables from the Lua script within a LabVIEW vi, you can call LabVIEW vi's from within the Lua script, and you can even edit a script as a string within a LabVIEW vi and then execute it! Dynamic scripting allows you to do some pretty powerful things. Unfortunately LuaVIEW would be more complicated than a simple formula-node and has a learning curve, but it's capability is far greater. The Lua language is a pretty cool and simple high-level language that is amazingly powerful in light of it's simplicity. It's a functional programming language, which basically means that functions are like variables, so you can use them in your data structures. It's primary use is to add scripting capability to other software packages, for example its currently the workhorse in the gaming industry to program the 'intelligence' of computer-controlled characters.

Jim, I was under the impression that LabVIEW PDA will run on any device with PalmOS 3.5 or higher, as NI's PDA Page seems to indicate.