gb119

Released a new build as a VIPM package. Slightly redefined the version numbering so that this really is newer than the previous build. Should have correct dependencies on the RCF packages.

New build posted v 1.1.2 is now a VIPM Package file. No major changes in functionality, but should install a little more easily and has a palette file under a LAVAG Category. Please ignore the slightly odd dependency of the .vip on itself. This is a result of a dirty hack that I've used to get VIPM to include a palette file of XNodes and is harmless

Uploaded a new build 0.20.02.6 which is now a VIPM Package (built with VIPM 2010). This doesn't add any new functionality, but does now install palettes properly into a LAVAG Category.

The match regular expression node on the string palette is an XNode and is manually growable, so it is possible. I've not actually done this on any XNode I've written (yet) but the output of the GrowInfo ability vi has settings to mark the XNode as growable etc. I think you will also need to make the Get Terms(3), Bounds, Image abilities aware that the XNode can be resized.

Is there a reason why you are using open vi reference rather than a static vi reference for the template ? I'd have thought the static vi reference would mean that you do all the loading of the templates when the XNode library first enters memory.

Yes that was exactly what I meant. I hadn't gotten round to trying this before, but the development version of my unbundle and unindex Xnode now checks for the input type changing like this: It seems to work right (given about 30secs of testing !) I'd be interested in knowing the most efficient way to compare variant types too - I end up doing this at various points in my code and often on critical paths.

This sounds like the XNodes are being rescripted on each type propagation. I guess this could get very slow with Xnodes embedding XNodes. Do you get any improvement in behaviour if you keep track of the types of your inputs and only run the generate code ability when the type actually changes (rather than if the inputs are valid) ?

Ok, that's weird. The only thing I can see that looks a bit odd on your BD is that it looks like you have a new line after Tag0 on the Find Tagged Object. Unless you tell it to do a regular expression search then it will do an exact string match. It may be that you want to use the Get Tag routine instead which doesn't check the value (I'm sure there is a good reason why the Find Tag... methods filter on the tag value but I can't for the life of me remember why now !)

Since you've already got the Array XNides I'm guessing you will have the Scripting Tools package as well ? If you have, then you also have (in the examples folder) a VI that will allow you to set tags on objects in the block diagram. That is in fact the routine that is used for tagging the template in the all the array XNodes. The Scripting Tools also includes routines to wire and XNode's terminals by tag (which is why the tunnels have 'odd' tags - they correspond to the names of the terminals in the XNode. The basic approach is to move the object tagged as 'script' into the XNode's working diagram, then connect wires to all objects that are tagged with the same name as the terminal name. If the number of inputs is constant then the Generate Code ability is simply needs to select the correct template as a static VI reference and then do the move and wire operations.

There was a (long) thread on various hash (or map or dictionary) implementations started by Aristo Queue when he introduced an implementation using classes - various implementations were tried and benchmarked - this seems to be the relevant page in thr topic. At the ime variant attribute seemed like it was the best (cespite those that should know about the internals of LabVIEW being surprised). I know AQ noted that his map with classes suffered from some specific bugs deep in the memory management interneals - I'm less clear if the performance has been fixed in 2009...

New version (1.1) uploaded. This adds: 1) Handles growable nodes with 2 and only 2 inputs (e.g. build array) 2) Handles bundle/bundle by name with two input elements 3) Handles a selection of two wires which have a common destination node (thus allowing one to swap the wiring when you have more than two inputs on a node). Known issues and non-features: Won't handle the case of two wires wired into tunnels on the same structure (I need to add an extra level of indirection to check whether the two tunnels/shift registers/sequence locals are actually on the same structure). I'm still thinking about the circular permutation of input terminals and wondering how generally iseful it is. Only works on input terminals. I guess I could make it look for both inputs and outputs and generate two menu entries for each case as appropriate. Again, I don't know if I make this sort of wiring error often enough to be bothered.

Ok, public egg on face tine... That one had completely passed me by - clearly I don't read the release notes carefully enough when installing new versions (or wsa it only mentioned in a weekly nugget ?) Still my plugin handles the select and coerce primitives and will handle swapping terminals that aren't wired in. I'd like to add code to pick up on two wires that connect the same node and then swap ther terminals, also workign with growable nodes such as build array or bundle into cluster with two inputs might be useful.

Name: Swap Terminals RCF Plugin 1.0.2-8 Submitter: gb119 Submitted: 04 Mar 2010 File Updated: 23 Aug 2010 Category: JKI Right-Click Framework Plugins Version: 1.0.2 LabVIEW Version: 8.6 License Type: BSD (Most common) Swap Termianls RCF Plugin - 1.0.1-7 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright © 2010, Gavin Burnell All rights reserved. Author: Gavin Burnell G.Burnell@leeds.ac.uk"]G.Burnell@leeds.ac.uk[/email]"]G.Burnell@leeds.ac.uk"]G.Burnell@leeds.ac.uk[/email][/email] Distribution: This code was downloaded from the LAVA Code Repository: http://lavag.org/ind...p?app=downloads Description: This is a plugin for the JKI Right Click Framework (version 1.0.2). Ever inserted a primitive like add, subtract, greater than, or less than into a wire and manage to get LabVIEW to wire up the 'wrong' input because you right clicked one pixel the wrong side of the wire ? Ever looked at code and realised that you've got the input terminals hooked up the wrong way round on a select ? Then this plugin is for you, simply select the block diagram primitive, activate the JKI RCF plugins and select 'Swap Terminals'. This plugin will work on any primitve function or 'growable' function that has two and only two inputs and also on the 'Select' and 'In Range and Co-erce' nodes to swap the top and bottom inputs over and rewire the wires. In version 1.1 it will also handle 'Bundle' and 'Bundle by Name' which have two input elements and a special case of two wires that are wired into different terminals of the same node. Dependancies: JKI Tools Right Click Framework >=1.0.2 Support: If you have any problems with this code or want to suggest features: Change Log: 1.0.2-8 Corrected a regression in previous version with bundle/bundle by name nodes. 1.0.1-7 Rereleased as a VIPM Package File built using VIPM 2010. Should have correct package dependencies for RCF Packages 1.0.1.1 Added growable functions with special cases for bundlers and two-wires-to-the-same-node. Refactored the code to kake extending it for other GObject types easier in the future. 1.0.0.1 Initial release on LavaG License: Copyright © 2010 Gavin Burnell All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the University of Leeds nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Click here to download this file

<advert> Volatile state for XControls </advert>

The problem with a shift register on the facade is that you can't access the volatile state in a method or property node. I *think* what I'm seeing is that the 'unsaved changes' flag of my main vi gets set as soon as I modify the display state cluster, so although I can purge it of unwanted data at close, won't LabVIEW still try to save the vi even though there are no 'real' changes. This is mainly an annoyance since it adds extra entries in my revision control system for no good reason.

I've been having the opposite problem - trying to work out the best way to store volatile state information for an XControl. If one writes this into display state then you end up with LabVIEW thinking it needs to re-save the parent vi which is a pain. (By volatile state I mean things about the appearance or behaviour of the XControl that need to be kept track off during runtime, but can happily be rest to default values when the program stops - values of sub-controls that form part of the XControl for example). I think the answer is to use one of the traditional storage mechanisms like a LV2-stlye global(FGV/USR) but then I got to wondering what happens if I have multiple instances of the same XControl - I know XControl's facades run in separate applications instances, but do multiple XControls share the same application instance or do they get one each ? What do others do about volatile state data ?

Wow - I don't think I've used occurrences since about LabVIEW 5 came out (like well since we had notifiers and queues etc !)

Although the question that nobody seems to have answered yet is what you do when you want both loops to run in parallel, but one of them to deterministically start first. I think that needs semaphores to do properly - something like this: Apologies for the walking ants - poor interaction between the screenshot programme and LabVIEW

Alternatively, it's on the very little used LAVA Code Repository at http://code.google.com/p/lavacr/source/browse/#svn/trunk/8.5.x/Machine%20Vision%20and%20Imaging/TIFF%20File%20Reader There's instructions there on how to use subversion to pull off the repository. Unfortunately 8.5 will only save back to 8.0 so someone who still has 8.0 will have to back port it to 7.1. Alternatively, you can forward port the 5.1 original version which should stillbe at the link given in one of my earlier posts on the thread and fix up the bugs.... EDIT: Except that I've just checked and my old research group have stopped directory listings on the web server. The direct link still works ok: http://dmg-stairs.msm.cam.ac.uk/~gb119/labview/Tiff_reader.llb Edit2: .htaccess is a wonderful thing

Sure, but new features means new opportunities and I think writing obfuscated code that remains obfuscated even after diagram cleanup removes a whole classnon-topological obfuscation.

Obfuscated LabVIEW code challenge anyone ? Rules something like: Should be programmable using the base LabVIEw 2009 (or earlier) system with no scripting and able to be forward compatible code (i.e. no LabVIEW vi's represented as binary constants) and no private property or method nodes. May use vi's found in vi.lib on the base system but no other dependencies (i.e. no calls to external dlls etc). Should have undergone code cleanup (i.e. no obfuscation by hiding code under structures or other boringly simple techniques). Any other restrictions ? Winner is the code that performs to the specification but in the least obvious and most contorted way possible.

There are some examples in UK politics. The (in)famous Prime Minister, Margaret Thatcher read chemistry at Oxford, and was a research chemist for a plastics company. TheLabour party politician, Margaret Beckett was a metallurgist who worked as an researcher at Manchester University in the late 1960's. The now departed (in disgrace) MP Ian Gibson was a lecturer in Biology at the University of East Anglia in the UK. There are others I'm sure, but those are the three that came to mind first.

:frusty:Ok that's my comeuppance for coding when too tired. 1.0.04 sets the palette berore saving the library. I think everything is now relativised properly - after a certain amount of pain moving and conflict dependency fixing. I'm still very hazy on when LabVIEW uses absolute paths and relative paths in the xml files - I had always though that it would use relative paths by preference, then paths relative to 'well-known' directories and then absolute paths. but this experience would suggest otherwise.

Thanks for the tip. Strangely, I'd thought about using the Get tag method to read the Endevo Goop tags but it didn't occur to me to use the Set tag method to set the default palette file. Duh ! The misplaced refresh palettes invoke node was just that - the whole code got wrapped in the for loop at a late stage and I had been too lazy to move the invoke node back. I've also fixed up the dependency problems - it was caused by the .lvlib file getting a bunch of absolute paths in it. What I'm not sure about is how to force LabVIEW to recalculate the relative paths (or why they got turned into absolute paths anyway) - in the end I manually hacked the xml which is not really very satisfactory.