ahlers01

Has anyone else noticed that if you have several items spaced out just the way you want them, then you select them all and hit shift-up|down|left|right that as they move they INDIVIDUALLY snap to the gird, ruining your spacing? Most annoying.

3267[/snapback]

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

You use the loader with vi server for calling the driver of instruments.

I use this in advance but when i build the executable, the complex vi called by the loader, don't load correct (more errors appeare)...

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.)

I have a difficult time finding the rendezvous refnum in the controls palatte as given in the help.

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:

Rendezvous Refnum

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?

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.

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.

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.

Would it be that much harder to implement without GOOP, just using initializing and shut-down routines? 

Is there anything special you do for scripting the batch commands in that window?

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.

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.

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.

3210[/snapback]

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).

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.

3210[/snapback]

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

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)?

3210[/snapback]

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:

HI.

I want to make some mathematical opertations with matrix, for example, sum, rest, multiplication, etc.

Anyone knows how to do that??

thak you

Lukas

2814[/snapback]

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.

Im trying to change the colour of an led, depending on the number selected from a dial.

I'm using a case structure, with a property node linked to the LED, with the property BoolText.FGColor.

This should change the forecolor of the LED?

If i feed the property node a number representing a colour eg RRGGBB. On running the VI, an error is thrown.

I think its due to the way im trying to specify the colour. 'HELP' says it should be hexadecimal...

how do i do this?

2816[/snapback]

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.

Hi!

I like to open a spezial file (open visually, I would like to see the written text in the file). I created a file with a own path and I would like to open this file with a click on a button.

I took  "open/create/replace file.vi" and wired the path as a proberty node and a constant named "open", too.

If I click the open file button it displays me a win dialog I should choose a file to open it.

How could I open it "real"?

2552[/snapback]

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!

Is it possible to build an array of a file path for extracting more then one file with one click? Or is there an other - better possibility?

2290[/snapback]

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