gb119

Thanks to the LAVA team for resurrecting the Scripting Tools.

The latest version is available via subversion on the LAVACR repository on Google: http://code.google.com/p/lavacr/ including an 8.6.1 version. Future releases (as and when I get ownership of the CR entry back (!)) will be for LabVIEW 8.6.1 or higher versions only. With the release of LabVIEW scripting most of this code is now easily reproduced but hopefully some folks will still find it useful.

Name: Array Function XNodes

Submitter: gb119

Submitted: 03 Jul 2009

Category: XNodes

LabVIEW Version: 2012

License Type: BSD (Most common)

Click here to download this file

QUOTE (Vladimir Drzik @ May 27 2009, 08:52 AM)

Yair,

Interesting idea, thanks. Maybe I'll look into that a bit further.

I contacted NI and the answer is the option of embedding the editor is not supported. The Vision Builder probably uses some parts of LV core to implement its Calculator step. Well, it seems like this is not the way to go.

Vladimir

Technically I think you probably could build a very limited labVIEW code builder using scripting and a picture control, however (a) it would be very hard work, (b) it would require a development system to be installed on the target machine for the scripting to work and © I'm pretty sure that this is explicitly forbidden in the various LabVIEW licenses.

QUOTE (Ic3Knight @ May 19 2009, 02:40 PM)

Hi All,

I'm developing some software to control a measurement system comprising of (amongst other things) a tuneable laser. The slight problem I have is that I want the same software to be compatible with different lasers (at present I have 3 different lasers I may want to use with the system). I wanted to use a plugin type architecture, so that I can simply select which type of laser is currently connected and everything will work happily. I've started to implement this by having a set of "actions" that I want the laser to perform (such as switch on/off, set wavelength etc etc.) and having a generic VI for each action which calls the appropriate driver depending on which laser is being used, and this works to an extent. The problem is that I need to perform a rapid sweep of the laser channels, which is typically achieved by running the "set wavelength" vi in a loop with an incrementing input to the wavelength value. Doing this with the "plugin" type VIs takes much much longer than if the driver is "hard written" into the application. I presume this is because of the continual opening and closing of the VI reference, is there a way round this? Is the plugin architecture really the way to go in this case?

LabVIEW Classes are a really neat way to handle this sort of thing. Write a base class that defines the generic functions you want to do - e.g. set wavelength, turn on/off laser etc. These are implemented as dynamic dispatch method vis. The method vis in this class don't actually do anything at all - they are just defining the interface to a general laser. Then write child classes for each type of laser you want use that provide methods that override the dynamic dispatch vis for the parent 'generic laser' class. In your main program you write everything using the generic laser class vi's but at some point have some code that selects the correct child class for whichever laser you are using on that experiment. This can be as simple as a case structure with a class constant in each case, alternatively you can also use the node that generates a default value from a class file to load the child class from disc at runtime.

I use this sort of architechture for working with my instruments - I have a very generic "instrument" class that provides vi's that wrap VISA functions but with additional debugging code that I can turn on and off, a layer of classes that define APIs for different type of instruments - e.g. source meters, temperature controllers, lockins, magnet powersupplies and then a layer of classes that implement the interface for specific instruments (or even combinations of instruments). This is sort of reinventing the wheel in that it duplicates IVI drivers, but (a) I know exactly what commands are being sent to the instrument and (b) I get to design the interface layer.

QUOTE (crelf @ May 17 2009, 01:54 AM)

Oh, that's just purdy. Not pretty, but definately purdy.

Er, thanks, I think.

You know for some very strange reason the original poster never got back to say thanks for the help.

QUOTE (jcarmody @ May 11 2009, 11:11 PM)

That would be HILARIOUS!!! Solving HH questions with obfuscated (or Rube Goldberg) code!

Actually I did it for real http://forums.lavag.org/who-will-help-me-t9851.html&p=40521#entry40521' target="_blank">once last year but nobody else got it on the act (possibly because writing artisctically bad code is hard work !)

QUOTE (TobyD @ May 8 2009, 02:17 PM)

You could submit this as an OpenG candidate.

Attached below is an XNode (LV 8.5.1) that implements this for all numeric types and also when the A input is an array. More or less completely untested other than running once on my development machine but I think it'll work. You need my Scripting Tools library installed and if you are not using the one from the LAVACR subversion repository on Google (i.e. you've downloaded from the LAVA Code Repository instead) you'll probably need a mass compile of the XNode code.

There's a little fiddle to workout which type to make the outputs - correctly detecting which input provides the higher order numeric type - I'm ranking U8,U16 and I8, U32 and I16,...,U64 and I32, I64, Single, Double, Extended, Single Complex, Double Complex etc which is not quite right but near enough. Look in GetTerms3.vi for that code (but don't look too hard it's 10 minute spagetti code).

Download File:post-3951-1241816400.zip

Oh yes, XNodes are unsupprted, not necessarily forward compatible, may cause LabVIEW to crash, destruction of the Universe and other bad things.

QUOTE (rolfk @ May 7 2009, 06:38 PM)

Just a quick and dirty example. I didn't try to get around having to supply a valid path to the method note.

http://lavag.org/old_files/post-349-1241721479.zip'>Download File:post-349-1241721479.zip

It's LV 8.0 because although the node is there, it returns an unimplemented error in 7.1.

Rolf Kalbermatter

Hmmm, I think for a competition one might want to disallow undocumented methods - I was thinking of possible "unhelpful but working" solutions to homework problems. The sort of thing that if you can explain why it works then you'd probably have been able to the LabVIEW homework already type.

For the original purpose of concealing algorithms that is pretty sneaky - I assume the buffer contains the compiled code, so presumeably a simple constant holding the buffer would break on LV version changes ?

I sure hope that my equipment suppliers don't start pulling these tricks in the code they ship with kit - some off them are a little twitchy about their control algorithms which wouldn't be a problem if the rest of their code wasn't so dire.

QUOTE (Black Pearl @ May 6 2009, 07:03 PM)

Ok, now it's more going to be fun in hacking than real work (*).

[...]

* So why I would say it's more on the fun side now, is that the skills you need to hack that would easily allow you to write the code on your own in less time.

Felix

I think it would more fun to have a coding challenge to write the most obfuscated code that does some defined task that does not employ any 'graphical' code hiding techniques and instead relies on daft ways to achieve a trivial operation. One my favourites is something like the following:

http://lavag.org/old_files/monthly_05_2009/post-3951-1241686658.png' target="_blank">

Of course this sort of the challenge is also a good test of the LabVIEW compiler's ability to optimise the code...

QUOTE (Aristos Queue @ Dec 20 2008, 12:37 AM)

Nor have most people succeeded in that domain. Could it be that some crucial connection between the two is missing? Does it feel, perhaps, unfinished...? If it feels that way, yet again, you are not way off...

QUOTE (ragglefrock @ Dec 21 2008, 11:03 PM)

I've had some success when using XControls to make probes for LVOOP classes, but I've also badly bitten myself. Problems start happening when you have an XControl that uses class members and then use that XControl in a probe that is itself part of the class. The result is an uneditable class (at least in 8.5 and 8.2 - I haven't tried the sequence in 8.6) which needs manual editing of the .lvclass to rectify. The general issue is that the facade of an XControl runs in a spearate application instance and runs even if the containing vi is idle. It's then very very easy to get a class that is locked because it is in use in another application instance, but the vi that is causing this is itself a member of the class. One can see the logical necessity of all the individual steps but the end result is spectacularly irritating.

If you manage to avoid shooting yourself in the foot, then yes it all works really nicely for class data because of the flexibility in manipulating the presentation of the (often complex) class data after the data has passed through.

QUOTE (horatius @ Dec 5 2008, 12:48 AM)

another point: this tool should simultaneously work during creation of a block diagramm and automatically snap the objects to optimum positions like a dynamically intelligent grid

Ugghh, no ! Please no !

Surely I can't be the only one who drops things in places which I think will be near where they need to be when I've finished the diagram. The thought that LabVIEW might decide to out guess me and move things around before I'd finished makes even some of Word's 'intelligent' features look good. Unless of course LabVIEW code automatically write the rest of the vi based on my half-formed mental plan of the vi...

Out of interest, is there any information in the public domain on hooks into the project window - e.g. creating new context menu items for different entries in the project heirarchy like the Endevo GOOP toolkit manages - or is this all provided only under a NDA with NI ?

QUOTE (Gavin Burnell @ Sep 13 2008, 07:36 PM)

The cleanup tool is kind of fun - but I'd really like it if it could be persuaded to work on sub-diagrams.

As a footnote to myself - after a bit of poking and script magic, I discovered that there is a 'Relayout' method defined for Diagram references. For a couple of hours I was very excited, thinking I'd discovered a way to do the selective layout - but unfortunately the method only seems implemented for TopLevelDiagram references. Oh well, that's what you get for trying to use features NI haven't actually released... - still perhaps a future version of LabVIEW will do the selective cleanup...

QUOTE (PJM_labview @ Sep 15 2008, 07:53 PM)

I am trying to make a VI that can get a class inheritance paths from a LV Object.

http://lavag.org/old_files/monthly_09_2008/post-121-1221504333.png' target="_blank">

Additionally I want the VI to be able to do the following:

1. Run in the runtime engine
   
2. Get the inheritance without loading the classes in memory
   

Ummm, if that LV Object input is an instance of the class you want to get the inheritence tree for, don't you have to have all the parent classes in memory for the runtime dynamic dispatch to work ?

The lvclass xml file does appear to contain a class genalogy property which (if one could parse the binary data) might be the key....

QUOTE (Aristos Queue @ Aug 15 2008, 12:57 AM)

Is there a CAR on that?

No, but at least there's now a product suggestion made in the right place...(as opposed to moaning about it on LAVA

QUOTE (Michael_Aivaliotis @ Sep 12 2008, 01:42 AM)

This first version of the cleanup tool is just that. It's going to be improved. What we need to do is let NI know what needs to be improved for the next release. So far, every time I use it I have to undo it. I have yet to find a case where it does what I want. Playing with the settings doesn't help.

One suggestion is that NI look at clean code that Pro developers like us create and find the key elements that characterize our layouts. Then, they could incorporate those elements into the cleanup tool as predefined styles that can be chosen in the options. You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

The cleanup tool is kind of fun - but I'd really like it if it could be persuaded to work on sub-diagrams. I can't think of the number of times that I've written a state-machine and while the basic structure is clean and tidy, there's one case that is a total mess. As things stand with the current clean-up tool it will cleanup my mess and then (to my eyes at least) de-optimize my state machine. For example, if I'm passing data through the state machine with shift registers, then I've normally set the y position of those shift registers with some reason - I think (without extensive testing) that the cleanup wizard is rather fond of moving and re-ordering them. Short of having the ability to selectively 'lock' BD objects I'm not sure how one would encompass that sort of style decision in a style schema.

I do really like the idea of a code-cleanup tool that could 'learn' what a user thought was good style - I've seen text programming code pretifiers that inferred correct style from samples - it would be really neat if the code cleanrup tool came with several 'style definition' vis that you could edit into your idea of good style...

QUOTE (Aristos Queue @ Aug 1 2008, 10:20 PM)

1. 
   
   
2. 
   
   
3. 
   
   
4. The LabVIEW Schema palette includes the following changed functions:
   • Flatten To XML—Supports LabVIEW classes and the fixed-point data type.
     
   • Unflatten From XML—Supports LabVIEW classes and the fixed-point data type. [ :ninja: <<< All the other items had smilies when I finished typing this. I thought this should have a smilie too.]
     

Though I see that it doesn't seem to handle Variant Attributes yet - which is shame as until the To More Specifc class bug gets fixed, variant maps are one of the more efficient maps and it would have been nice to have had an easy way to save them to disc or squirt them over the network in a human parseable fashion... oh, well next time perhaps ?

QUOTE (wkins @ Aug 11 2008, 01:05 PM)

1. What are the best most efficient methods of transferring data between Sub VI's?

In terms of clarity of coding and most efficient use of memory transfering data via the normal connector pane and wires is the best way to go. If you have many items of data that are related consider using a cluster to hold them all together on a single wire and a single input/output terminal. If programming in LV>=8.2 then using a LabVIEW class rather than cluster has advantages in terms of encapsulating the data and potentially improving maintainability. Passing data between sub-vis without sending it through the parent diagram is not great style, but you should look at notifers and queues if you really want to do this.

QUOTE (wkins @ Aug 11 2008, 01:05 PM)

Queues are the way to go here. Again, if you are passing large amounts of related data, then define a cluster (look at Type Def controls), create q queue with that type as the element outside both loops and then pass the queue reference to each loop. Queue data in one loop and read it in the other. Have a look at the examples of produce-consumer design patterns to get the idea.

The University of Cambridge one is almost entirely pointless at 32x20px (what do you expect of an institution that predates the printing press never mind computers )

QUOTE (ktvz @ Jul 29 2008, 03:28 PM)

Hi Gavin,

By default STDIN and STDOUT have no meaning for a GUI based application (process to be exact...) like LabVIEW. But you can create one for a process does not have this. A use-case would be to output debug information. There is no Native LabVIEW way to do this (as far as I know). The System Exec.vi just executes a process on system level that could have a Console.

I have been using the following VIs that call the Win32 API to create a Console Window for the LabVIEW Process and write to it. I primary use it for debug output so I did not look into reading from the Console.

Download File:post-1819-1217341336.vi Download File:post-1819-1217341345.vi

Tested in LabVIEW 8.5.1 on Windows Vista SP1 32 bit

Yes, but the original poster wanted (and I have no idea why other than to show that LabVIEW can't create 'proper' console apps) was to open a console window and type something like "cat input.txt | foo.exe > bar.dat" where foo.exe was a compiled LabVIEW program. So it's easy to see how to hide foo.exe's GUI and there are lots of ways to get that GUI to open a window that is a console window or looks like a console window and spit out text, or even to open a console window and read in text that the user types in. In your examples, if you don't create the console window, what happens when you call GetStdHandle ? If it works as above then that's very nice for answering mavericks who want to use LabVIEW to create a text-mode application

Ouch !

The VariantType utility functions in vi.lib include a vi that will give you the class filename of the class 'on the wire'. Does that do some horrible memory copy as well, and if not, could it be used to test for the 'true' class of the wire (if the testing code had enough intelligence to know that class A.lvclass was in fact a descendent of class B...) or is the problem that you always actually need the wire of the descendent class ?

Edit: oops, reread the original post and realised my question is stupid. It's been a long day.

QUOTE (Rio C. @ Jul 29 2008, 07:50 PM)

I'm gonna guess that you are using the drivers that you can download from Keithley's website for the Model 6221? This driver represents some top level measurements that you can do with this equipment. To get the best performance you should issue SCPI commands using the VISA read and write VIs. Take some time to familiarize yourself with the manual and develop the remote commands you need. I think for your measurements you can talk solely to the Model 6221. The Model 2182A should be connected to the 6221 with the trigger link cable and the RS-232 cable as shown on page 5-8 of the REFERENCE manual for the Model 6221 (you don't even need a GPIB cable to the 2182A). Also on page 5-51 it talks about differential conductance measurements, which might be similar to the kind of measurement you need. With this mode you can make measurements with intervals as small as 1 ms. Page 5-62 even has an example of the remote commands required for the measurements.

All of this is sound advice - I find the flow charts of the trigger and arm cycles very useful for these instruments in figuring out how to set things up. Essentially you want to have the 6221 emit a trigger signal after it has set the current, have the 2182 wait for this trigger pulse and then have the 2182 emit a trigger pulse after it has doen the measurement for that point to signal the 6221 to move to the next current step.

From memory, the built in modes that hav the 6221 and 2182 work together automatically are rather limited and I'm not sure if you can persuade them to do an arbitary waveform (you can do arbitary pulsed measurements and differential conductance linear sweeps and I think a range of straight and log dc sweeps). If you do have to 'roll your own' then you will need to configure the 2182's buffer to match the number of points that you're defining for the source waveform. Also, whilst it is possible to get the 2182 to talk to you via the 6221, it might be easier to just hook both of them up to GPIB.

In my experience, the Keithley drivers are not very good (but frankly, most manufacturer's drivers aren't very good !) so writing your own is probably the way to go. If I get a chance I'll put my 6221/2182 drivers up somewhere - although they're a bit complex because they're a LabVIEW OOP heirarchy (e.g. Instrument Class -> DMM Class -> 2182 Class etc).

One other comment, you mention wanting to read the current back - the 6221 doesn't actually measure it's own current directly. You could arrange to measure it (in principle) by having a standard resistor in series with current and hook the second channel of the 2182 across it and measure the voltage drop across it to get the real current. On the other hand, you could just trust that the 6221 is doing what you told it to do...

QUOTE (Tom Bress @ Jul 29 2008, 02:37 PM)

I [...] Go Blue!

Ah, but light blue or dark blue ?

QUOTE (ASTDan @ Jul 11 2008, 09:10 PM)

What does Open G Dictionary pallette do? I have been trying to find some documentation on this, but have failed. Can anyone point me to some documentation on what these curious set of tools do?

Does anybody else use Open G Dictionary? Do you like it? Is it a form of GOOP? If so how does it compare?

The term dictionary is borrowed from Python. Other languages would call these data structures hashes or associative arrays or maps. Basically it's an array that stores data indexed by a non-integer key. Typically one would use a string, so rather than having surname[1]="Smith" you would have surname["James"]="Smith". This can make it very easy to construct data storage where items of data naturally have names rather than positional indices. I tend to use a dictionary structure to store experimental metadata eg. sample temperature, applied magnetic field, instrument settings like ranges, heater powers etc.

The OpenG dictionaries are far from the only implementation - in recent versions of LabVIEW the variant attributes can be used to make a reasonably efficient dictionary, as can implementations using single element queues. There's been several discussions in recent months over the most efficient implementation. Here, for example.