gb119

I'd be very happy to redeclare my allegiance to the people's republic of Yorkshire, but I'd be even happier to reinstate my premium membership !

Further playing around suggests that there is some badness creeping into LV's compilation - copying and pasting the main error case structure to a new diagram can let me run the cleanup ok. You're quite right about the inplaceness structure - it's rapidly becoming my favourite inappropriately used LabVIEW structure

This is a latent cross-post from the NI forums, but I figure that the LAVA readership has a higher density of real experts than the NI site. In the course of working the Scripting Tools library, I've manged to generate a block diagram that is obviously in need of some cleanup and for which, when I press Ctrl-U, the cleanup tool beeps at me and does nothing else. Can anyone shed any light on what code constructus might cause the BD cleanup tool to fail like this ? I've attached a screen shot of the vi in question - if you want to look at the code then just check out the current LAVACR svn repository (8.6.x folder) from http://code.google.com/lavacr The problem area is the in-place structure between the 2 tunnel property nodes (vi-scripters will recognise this as turning on case insensitive selection in a case structure).

Cheers !

Ok, this is probably me being stupid, but having had my CR entries repatriated (thanks !) I can't find the way to uploading a new version of the file and editing the meta data. The list of "My Files" in my profile has the correct entry but doesn't have an obvious (to me anyway ) edit link, nor does going straight to the CR entry page. What have I missed ?

The latest version of this (including a 8.6.x version) is available via the LAVACR subversion vepository on Google (http://code.google.com/p/lavacr/). As and when I regain ownership of the code repository file, I'll post an updated version of the array XNodes. Future developments will all be in 8.6 or greater.

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) lava_lib_LabVIEW_API_array_xnodes v1.4.3.36 by University of Leeds Author: Gavin Burnell Copyright: Copyright © 2014, University of Leeds License: BSD Compatible LabVIEW Versions: >= 2012. Compatible OS Versions: ALL. Description: Description: This is a collection LabVIEW 2012Sp1 XNodes. XNodes are a hidden and unsupported feature in LabVIEW >8.x. As such, this code may not necessarily work in versions of LabVIEW > 2013 and the technology is not supported by NI. On the otherhand they are really quite useful. Because XNodes are scripted at edit time they offer a form of polymorphism far superior to polymorphic vis as they will support any array type and not just ones that the developer has provided polymorphs for. This package contains the following XNodes: * Array Dimension Array This XNode operates in a fashion similar to the Array size primitive Xnode except that it always returns an array of sizes of dimensions. For a 1D array, this is an array with 1 element, for n-D arrays where n>1, this is the same as the primitive and for scalar inputs, returns a zero length array. * Array Dimension and Index * Array Size and Unbundle These are slightly different versions of the same XNode. It will take in an n-dimension array and return N I32 outputs with the dimensions of the input array. Array size and unbundle is perhaps the better named version. * Array Dimension This is equivalent to the Array Dimension Array coupled with an Index Array node to return as an I32 the specified dimension of the input array. If the specified dimension is greater than the dimensionality of the input array, -1 is returned. * Filter Array This XNode splits the input array into two sub arrays according to a boolean array input - one for elements where the boolean filter was true and the other where the filter was false. * Foreign Key Sort Sorts one array based on the sort order of a second array - useful when you have an array of items and an array of keys and you want the first array elements in order of their keys. * Shuffle Array The inverse of an array sort - randomises the order of the elements of an array. For 2D arrays it can randomise either the rows, columns or both rows and columns. * Unindex and Unbundle.xnode Performs the inverse of Index and Bundle Cluster Array. Takes an input array of clusters and un-indexes and unbundles each cluster and returns arrays of each element of the original clusters. This is equivalent to feeding a cluster array into a for loop with auto-indexing turned on, unbundling all elements, and wiring back out of a for loop with auto-indexing turned on in order to generate arrays of each element. * Minimum Array Size This XNode will take the input 1D array and either make it at least n elements long, or exactly n elements long. If additional elements are needed, the default value for the element is used and the new elements are appended to the end of the array. For the fixed-size variant, if elements are to be removed, they are removed from the end of the array. Known Issues: One of the palette entries is (a bit) broken: Array Dimension and Index appears as "Help" in the palette, but otherwise works fine. Click here to download this file

View File Scripting Tools lava_lib_LabVIEW_API_scripting_tools v0.22.1.21 by University of Leeds Author: Gavin Burnell Copyright: Copyright © 2007-2010, University of Leeds License: BSD Compatible LabVIEW Versions: >= 8.6. Compatible OS Versions: ALL. Description: This is a LabVIEW 8.6.1 Library of VIs to help with scripting. The public VIs include routines to get hold of the block diagram references, control terminal references, get the connector pane reference and select the connector pane pattern and wire controls up to it. There are a number of routines to help wire the block diagram up, including creating a selection of the primitives (I got bored of coding them all up !). I've stuck in some routines that work with tags - hidden away is the capability to tag LabVIEW vi-server objects with arbitary data. One possibility is to use this to identify bits of the block diagram of a vi for moving and rewiring via scripting. The scripting Tools includes a separate XNode support library that provides routines to help scripting and terminal adaptation in XNodes. There are some routines to help with undo transactions new to this release. This Package Conflicts with these other packages: LAVAG_scripting_tools >= 0.0 Scripting Tools >= 0.0 Submitter gb119 Submitted 07/02/2009 Category VI Scripting LabVIEW Version

QUOTE (Vladimir Drzik @ May 27 2009, 08:52 AM) 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) 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) 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) 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) 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) 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) 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) QUOTE (ragglefrock @ Dec 21 2008, 11:03 PM) I'll throw in another very useful aspect of XControls. They're extremely useful in custom probes, because they allow the probe's panel to remain in an active state after the data has passed through the probed wire. This is very useful for analyzing reference-based data, because you don't have to know exactly what you're looking for before the data passes through the wire! 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) 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) 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) 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) No, but at least there's now a product suggestion made in the right place...(as opposed to moaning about it on LAVA