jeffwass

I've started working on my Test Executive as Michael called it, and I'm following a model similar to yours. Instead of using GOOP (I probably will want to use OpenGOOP in the future, but its documentation is too confusing for me now), I add two extra routines for the drivers - Construct and Destruct, to handle constructor and destructor functions. The instrument drivers open the driver VI by reference, and pass a function enum, as well as a main cluster, which contain refs to all the relevent information of the system. All items are strictly-typed (LabVIEW docs say I cannot pass strictly-typedef'd controls to a VI by reference, but it worked in 7.1). Regarding typedefs, my overall cluster is getting pretty complicated, and each time I put it on the front panel it takes up a huge space. For now I've gotten around this by hiding it on the front panel, but I'd like to make a "normal-sized" reference-like picture for it on the front panel, but I can't find any decent documentation on editing control appearances. Does anybody have a decent link to this? Another question regarding sending information. You mention three states, such as running idle, opening popus, etc. Do you run the risk of race conditions as you update information on the whole system state, or do you have specific read/write routines to access the overall system parameters? As I said previously, I have a strict typedef cluster, which contains a link to the main VI reference, the main VI's menubar (I searched through all the invoke and property methods I could find, and couldn't figure out how to get a ref to another VI's menubar), and so far a cluster with all the menu/driver/instrument information. I'm in the early stages, so I don't have actual data or files yet, but they will be added soon (data will be through indexing to a LV2 global). What I've been doing now is passing this overall cluster into and out of each function I call, kind of like error in/out. DOes this seem like a stupid thing to do? The vi's can get kind of annoying dealing with this, but I think it can help prevent race conditions, or maybe I'll need to either add non-reentrant subVI's to read/write from the cluster and/or use semaphores. My main isn't queue-driven, I basically have an event structure that captures all relevent front-panel events and process them. As I'm only in the starting stages, I don't know if this approach will be too limiting later on. Do you suggest using queued state machines? Or does the event structure help make it easier to work without those? IIRC, the event structure has queueing built into it? Of course the benefit of your approach is batching looks the same as user interactions. And I'm also not sure how the event structure will handle routines that will take a long time to run, Ie, if the main VI can respond to other events or not. I've made further progress on using HDF. The basic synopsis so far - it's a real pain in the arse to use so far, NI provides a few of the most-common lowest-level calls, and made a few slightly higher-level calls. NI also provided high-level methods for saving LabVIEW waveforms, which might be quite user friendly, but I don't have the need for them now. There are so many low-level calls of the HDF5 library, though, it can be pretty daunting. Two annoying things to deal with are the continuous usage of 64-bit integers (which they provide some VI's to convert either 32-or-less ints, floats, doubles, or 2 32-bit ints into), as well as the large number of typedef's in the HDF5 header file (which they provide another DLL to get a few of these values back). So while creating and writing data into simple HDF5 file can be done with only a handful of lines of C code, the corresponding LabVIEW Vi gets pretty complicated pretty quickly, with all the repeated calls to the 64-bit integer and typedef libraries. I've thought the NI approach isn't the easiest, and pretty soon I'll start making my own set of libraries built on top of the NI-provided libraries. I'd consider re-doing the whole thing, but dealing with re-creating the DLL's is too time-consuming for me now.

That sounds pretty cool, I didn't really think to make a common driver plugin like that. That makes sense, especially in light of the SCPI syntax for many new GPIB devices. So for the CONFIG action, the main vi calls the driver plugin's specific popup routine? I was also thinking of keeping the state of the instrument, or perhaps different files for saving various commonly-used states. I also want a 'log' state where the relevent device operating parameters would be sent to a datafile associated with that particular data set from the main, such that 5 months down the line I can see exactly how the instruments were configured that day. Maybe even set it up such that the instrument states can all be fully recalled to duplicate specific datasets. So does the driver popup come over the main vi? And how do you capture the events to send the config command to the plugin, from an event loop or similar in main? I assume you build the menus dynamically. I'm pretty new to these topics, so I'm not sure how to best implement them in a large setting. Namely having subVI's stop or pause in the middle of their operation, from a control on the main VI. For example, due to changing a parameter or quitting the main vi. Yeah, that does sound pretty useful. Would it be that much harder to implement without GOOP, just using initializing and shut-down routines? I don't know GOOP yet (I do know OOP through Java), but between dynamic VI calls, VI server, event loops, using HDF files, and maybe Lua scripting through LabVIEW, I feel like I'm drowning in LabVIEW overload before getting involved with GOOP. So I'll try to go OOP-less at first. That sounds useful, I've read about those LV 2 globals and at first they just seemed bizarre to me, almost counter-intuitive. But I guess it works pretty well. So the way you implement that, then, is to have all your data stored through the uninitialized shift register, indexed in some manner, and when you want to extract it, you send a pointer to the proper index of the LV2 global to whichever subVI wants that data? That seems pretty sensible to me. Is there anything special you do for scripting the batch commands in that window? Ie, if you want to sweep magnetic field and record data, or another time you want to sweep pressure (if you can) and at each pressure sweep the magnetic field, can your program dynamically accomodate these two different data-taking methods? I want to implement things dynamically like that, and it gets really annoying to re-wire all the time. So I've been looking at LuaVIEW lately, which lets one call LabVIEW VI's from within a Lua script (Lua is a very elegant and small scripting language). What makes it great is that you can call the Lua script from LabVIEW, so you can have a text window on the main VI with a user-controlled script describing the batch operations, for example. Thanks for the response, it was pretty useful.

I'm sure most people working on large applications have developed several methods for controlling many subVI's, and probably someone has had a similar application to mine. It seems there are several ways to do this, but before starting to implement it I'd like to know which option(s) other users think would be best. I am acquiring data from a subset of the various instruments in our lab. For example, I'll often measure the I-V curve of a device, which involves using a current source and a nanovoltmeter. What makes this a challenge is that in our lab we have several different models of current sources, nanovoltemeters, and even some units that do both functions. Which instrument(s) I use depends on the type of sample I'll measure, as well as which instruments are currently free. Originally I had a whole slew of VI's written for the various combinations of equipment, but this is from before I learned the ways to dynamically control VI's (of which I'm still a novice, BTW). Similarly, these VI's have been used as subVI's in larger data acquisition programs, which I would re-wire each time to use the right equipment. Now I want to be able to select which current source and voltmeter I'll use from the master program, and have it dynamically choose the proper subroutines. To make things even more confusing, there are a variety of parameters to be adjusted on the equipment, such as analog filtering, digital filtering, range, triggering, buffering, etc. This has proven to be too many controls to put on the front panel, even for the subVI's to take the I-V data. And it varies too, for example some units don't have filters, some only have analog filters, etc. What I've considered was to dynamically add menu items on the main control panel, depending upon which instrumentation I would be using for that run. Each menu item would correspond to the exact piece of equipment I was using. I was then hoping to either add sub-menus for the various options that can be adjusted on that particular piece of equipment, or to have the menu item create a popup which would control the settings on that particular piece of equipment. I envision having some cluster on the main VI denote which instruments are being used, and correspondingly each instrument would have it's own specific cluster describing all of its settings. So - has anybody done anything like this before and can either suggest this way or a better way to control the instruments? I'm also not too sure how to capture the menu item events. I was thinking of using an event structure on the main VI to call a dedicated menu item processor VI, and I would register with that processor VI which subVI's to call depending on which piece of equipment is being used, etc. As far as I know this should all be possible, but I don't have much experience with this. Would using the VI server be a way to go? And/or would it be advisable to use globals to access things, or should I avoid them? Namely, when I change which equipment I'm using and the settings of that equipment, what is the best way to allow the other subVI's to access that information (presumably through the clusters)?

Update : As I said earlier, I had problems adding the NI Soft Front Panel libraries into the LabVIEW instrument pallette. Instead of dealing with these palletes, I've been looking at the NI-provided HDF5 wrapper libraries included in the library. These are pretty much a slew of LabVIEW VI's that call the corresponding HDF5 function within the HDF5 precompiled shared library. I've only done some basic things so far, but these wrappers seem to work okay. Hopefully they'll be all I need to fully save complicated data in the HDF5 format. If anybody's interested, I'll provide some samples of writing various data to an HDF5 file when I am able to do so. Eventually I might re-do these wrappers from scratch, such that they could be used with the openG project. But that would be a long way off, and I'd only do that if I was pretty sure NI had no plans to make HDF5 functions included in a future LabVIEW release.

I haven't played with it yet, but there is a Lua plugin for Eclipse, which could be useful for LuaVIEW, which allows one to call LabVIEW modules externally.

That one actually worked, but it seems more focused on demonstrating how to access 64-bit files and structures. But it does include a working example at doing doing some HDF-related functions. That one actually didn't work for me, it came with a Windows .exe file, which just unzips a bunch of files (an llb along with several mnu files and three DLL's). I followed the instructions to install the "Soft Front Panel", involving unpacking into a subdirectory under "instr.lib" in the LabVIEW directory, and copying the DLL's to the Windows system directory. Ultimately, it didn't work at all. It was supposed to create a Soft Front Panel pallette, which it did, but none of the sub-links worked at all. I tried playing around with various methods of getting this to work, but wasn't able to. (Digression here -- ) I must admit I'm new to manipulating the user-defined pallettes. But I've successfully created and used those corresponding to the LuaVIEW and labpython scripting projects. It seems really weird that the NI people can't get something easily working while the open-source community makes it very smooth. Actually, the openG package format is probably the best way of setting up NI packages, it's easy. NI involved manually moving files to various directories, and rememebring where they are if you want to uninstall. Does anybody else besides me think the NI LabVIEW documention is fairly minimal and lacking? I was so surprised after discovering these communities at how much more LabVIEW could do than the NI documentation led me to believe. So anyway, thanks for those links, I actually found them after posting here, but wasn't able to get that soft front panel working at all.

Has anybody written or read HDF files from LabVIEW? Or perhaps a similar scientific data format, such as CDF or netCDF? (For those that might not know, HDF files allow a platform-independent, and even application-independent, method for storing various kinds of data. Eg multiple-dimensional numerical data, pictures, color tables, and also descriptional meta-data to go with each data set.) The HDF distribution comes with a shared library file that contains the input/output routines, which would need to be accessed with CIN. If anybody has used HDF, was it difficult to access the files? Or does anybody know of public LabVIEW code that already exists to read/write to HDF files? And finally, if somebody knows of a reason that CDF or other might be preferrable to HDF, that would also be useful to know at this point. The reason I need this is because my datasets typically involve variation of several controlled parameters (current, temperature, applied magnetic field, gate voltage, etc). And from run to run I'll vary some of these parameters and hold others constant, and it's rarely the same. So I need a common sane way to save the data such that it can be recalled and processed between runs without needing an individualized data parser for each specific dataset that is written. Eg, one dataset will record differential conductance as a function of current, and repeat this at various temperatures. Another dataset will also record differential conductance as a function of current, but this time temperature will be held constant and I'll vary the magnetic field. I want a sane way to recall and parse the data such that it can be processed using the same program (most likely the parsing would be done out of LabVIEW, so I'm more interested in writing HDF files from within LabVIEW). Multiple-dimensional arrays seem like the way to go here, and with the meta-data allowed by HDF, it seems that it would make sense.

I've picked up the Programming in Lua book from my uni library. Lua is a great little language and I really like what I've seen about it so far. I am currently in the process of getting into the details of both Lua and LuaVIEW. May I suggest including the two-button-dialog example (shown in the LuaVIEW visual overview)in the LuaVIEW examples code? That's the simplest example I've come across demonstrating how to call LabVIEW modules from the lua script, and I was surprised after seeing it in the overview that it wasn't included with the other examples. And I did run into some path problems trying to do it myself at first. Some of the other example scripts (eg the fractal script and calculator) get relatively complicated quickly, in terms of both the LabVIEW state machines and the Lua scripting commands. That dialog example, while limited, gives a quick and simple overview of the method of calling LabVIEW from the lua script. Do you know how many other people are using LuaVIEW? I'm surprised there are so few google hits on it, because it seems like it would be a very handy tool for many developers. Anyway, is this LAVA board a proper place to bring up any LuaVIEW-specific questions I'll most likely have in the near future?

Thanks alot for the explanation, and especially for that detailed link. I was looking a bit at LuaVIEW, but I didn't want to learn a whole new scripting language. But it does seem that LuaVIEW will do the trick, so I'm off to the library to get the Programming in Lua book. Have you experience using it? I've found the LuaVIEW examples a little confusing, I'll just have to go over them with a fine-toothed comb. Do you know if there is a LuaVIEW mailing list? On a somewhat different note, what exactly is "LabVIEW Scripting" as listed as the title one of the LAVA programming forums? Does that just refer to the act of dynamically calling VI's, and not really the traditional sense of scripting per se?

Hi Michael, It is now three months since your post on labpython and luaview. Have you made any progress with either of these scripting extensions to LabVIEW? I would like to use python as a scripting language, but development on it seems to have slowed down. Also luaview seems fairly more advanced. Namely, I'd like to call LabVIEW vi's from the script, but AFAIK one can do that in luaview but not in labpython. Is this wrong? Also do you know about using python 2.3 instead of python 2.2 with labpython? Changing the path of the dll seems to work so far, but it could make things unstable later.