ahlers01

Haven't noticed that yet, but you can use the 'Group' feature from the 'Reorder' icon menu to group those items into one grouped item so they keep their spacing

I do not experience any problems when I load the dynamic VIs into a built application (.exe file). The instrument drivers are not included in the .exe but are located, as regular LV VIs, in the filesystem. Important is that their location is made known to the .exe at runtime (and of course that they are in a runnable state). I use config files (.ini files) for this. Driver VIs which the user wants to make available to the bulit app are simply added to this config VI (which you can consider as a sort of primitive database) with a text editor. There is one slight drawback to this approach: when a new driver is written it usually needs some debugging to optimize it. In the LV Runtime environment (RTE) this is not possible. BUT you can also run the compiled main app in the RTE. Just rename main.exe to main.llb and open the llb's top level main.vi in the LV development environment. Then you can set breakpoints, probes etc. in the driver.vi (and its subVIs) which you developped. (The hierarchy of main.vi is of course still inaccessible to debugging since its BD was remved during the application build.)

There is no entry in the controls pallette of the FP that create the rendezvous refnum directly. In the LV help, go to the 'Search' tab, enter 'rendezvous'. Among the found items, select 'Types of Refnum Controls and Indicators'. The second but last paragraph in that section reads:

Actually, the driver VIs are meant to cover ANY type of instrument, not just GPIB. I have driver VIs for serial, USB instruments and some which just simulate an instrument (so I can do some testing of the main.vi without having any instrument connected. Look at the HTML Doc of a typical driver VI. It is a driver for a Agilent HF source. There is only code in the action case 'SET'. Everything that I want the driver to be capable of I have to program into the various cases. Here I just put code in the SET case. The good thing with my approach is that one can start with such a minimum of coding (and later add more if needed). The configuraton you mentioned is done from the main panel. The attached image shows the main panel when the user clicks on the button labeled 'Current I/nA': a pop-up dialog occurs and one can configure the instrument. (Actually the objects are what I call a 'Signal': a signal consists of an instrument, transformation rule (maybe you read e.g. a resistance, but its physical meaning is a temperature, so one needs a transformation), and some other onfi like name, unit etc.) In the displayed example there is not really a current meter shown, but a simulated instrument called 'Random'. It has 2 parameters, 'offset' and 'scale', but this could be anything for a real instrument, like e.g. sensitivity, filter, cut-off freq, time-constant, .... If YES is activated in the last column of the dialog table, the corresponding entry is saved in the metadata of the measurement file. That would be cool, my program does not yet allow this. Just as I said above, I can have those instrument settings which I consider as relevant stored in the measurement file's metadata. OK, this place is too short to describe in detail what my program does (It's size is ~ 280 VIs). See the link at the end of this post. I use menus only for configuration things (saving the status, assembling a new set of signals etc.). Things which are done seldom. Most of the user interaction is with the list of signals in the lower part of the main panel. The main.vi is always in one of three states: 1) running idle: user selects which measurement he wants to do next 2) user has opened a configuration pop-up dialog 3) a measurement is running: controls (except STOP button) are disabled, ongoing measurement is displayed in the graph panel. Updating of the graph is done by a separately running VI which peeks on the heap and displays (at low rep rate) what is new. I should definitely be possible without GOOP, but for me it was of great help to use such a prestructured framework (..I am a pretty chaotic programmer. No fishing for compliments here, just plain truth) The batch capability is based on a minimal scripting language invented ad-hoc. It basically allows to make most user selections on the front panel also programatically (via the batch kob). Technically it was not too difficult to implement since my main.vi consists of an queue driven state machine. It does not matter if the queued actions come directly from the user or from a batch processor (which is just another state in the state machine). The batch language has only 8 different commands, but even they are difficult to remember, so I added a 'batchmaker' which programmatically creates a batch job for the most useful cases: e.g. measure I-V curves at 300 different gate voltages, repeat this at 20 different vales of B-field and so on.. Here you find the complete doc of Modulab One of the things that I might change in the future is the format of the stored data. I use a custom format which was defined a few years ago with some ideas (about connectivity to a selfmade database) which are now obsolete. I'm therefore very much interested in the thread on HDF format which you started in one of the forums.

Sounds like a familiar scenario. I use an approach with plugins (instrument driver VIs loaded dynamically at run time). Each instrument is represented by ONE (driver) VI. Everything that the main.vi needs to access from this instrument has to go through this driver VI. The connector pane of the driver VI is always the same, for all instruments. One of the parameters to driver VI is a string, labeled 'ACTION'. The values of ACTION at run-time ar: INIT, CONFIG, TRIGGER, MEAS, SET, RESET. Within the VI there is a case structure with the corresponding action cases. For each instrument in our institute there is (or hopefully will be at some day) ONE such driver VI. In the main.vi a user can select from the available drivers the subset he needs. (Of course such a selection be stored in a config file for later retrieval). The selected drivers are loaded at runtime as plugins (as is e.g demostrated in \examples\viserver\plugins.llb). The available parameters of a given instrument are stored in what I call 'informative controls' on the driver VI front panel (using the 'Make current values default' feature). The informative controls are not used on the connector pane or at any place on the block diagram. They are just read by the VI from the main hierarchy which loads the driver VI. That way the main knows everything about the intrument you want it to know. The momentary settings of an instrument can be changed with a pop-up dialog in the main hierarchy. Again, they are stored in a file to keep them between runs of main.vi I avoid globals as much as possible, only use them to make some general config information available throughout the main hierarchy. The plugin mechanism I use is wrapped into an object oriented framework that I developed with the old (freely available) version of the GOOP toolkit. This GOOP approach makes it possible to encapsulate the config information of a loaded driver plugin with the driver code itself. The GOOP appraoch allows for another nice feature: The destructor method of a driver VI object contains code which stores all the info in a file when the main.vi destroys all dynamically created objects before it terminates. The next time when main.vi is run it recreates all the previously used objects with the same status they had before, since the constructor method of the driver VI object recreates the object using the stored information. (One of the private data of the driver object is of course a reference to the actual instrument driver VI). In an earlier approach I also used to store the information collected during a measurement (the "measurement data") within the instrument object data space. That turned out to become slower and slower when the data size was large (> 10000 data per scan). I decided to use what is called a LV 2 style global (basically this is an 'intelligent' global which uses a VI with a shift register just for data storage). I actually implemented a storage heap mechanism and the instrument objects now only need to store a pointer to their data on the heap, not the data itself. That was fairly efficient. I know this may all sound rather complicated, but it works really well. We use this program now at many different places and there is no problem with quickly plugging in a new instrument if the driver VI for it is available. If it is not and needs to be written, it takes a bit longer, and of course there needs to be somebody who can write it. But that is not awfully difficult either (depends of course on the instrument's complexity). I attach a hardcopy of the main.vi, so you get an impression how it looks:

If you have the Advanced Analysis VIs included in your LabVIEW Version (it is included in the Full and the Professional Development System), you find Matrix operations in the 'Functions--Analyze--Mathematics--Linear Algebra' pallette.

If you want to change the color of the LED use the the property node 'Colors[4]'. It is an array with 4 clusters, each cluster containing two U32 numbers for the FG and BG colors. The first two elements are the colors of the ON and OFF state of the LED. The remaining two are probably for the transitional states of the BOOLEAN LED, you probably won't need them. The BoolText.FGColor would change the FG color of the boolean text, but that is not writable in a running VI (go to the Context Help and click 'Click here for more help') For the colors it is very convenient to use the 'Framed Color Box' (last item int the FP Numeric pallette) or the 'Color Box Constant' (first item in the BD 'Numeric--Additional Numeric Constants' pallette), since you can use the color selection dialog to select values.

Why don't you do this way:

Event structures introduced since LV 6 are mainly meant to catch GUI events, e.g. when the user changes the value of a control. This avoids the continous polling in a loop which had to be used in the pre-LV 6 days. With LV 6.1 and 7.0 event structures got new features, one of them was the ability to react on programmatic (not user-caused) value changes of controls or indicators. But, the programmatic changes have to be made by writing to a control's or indicator's property node 'Value (signalling)'. Writing to the property node 'Value' or updating an indicator in the usual way will not lead to a value-changed event.

Sorry, I made a stupid mistake when replying... Here is my reply: Look at the following 2 threads in NI's forum: windows.dll solution pure_LV solution

Hi, the problem is that the Open/Create/Replace File VI creates a byte stream file. You can use a datalog file instead (see LV's help system for an explanation of datalog files): 'Method A' in attached example code. Or you can flatten the data to a string, save it as string, read it back as string and unflatten it to a 4D array: 'Method B' in example