gb119

Well I'm not sure if XNodes can be grown manually, but I do know that the Build Array node is NOT an XNode. It's a native node and is directly implemented in C inside LabVIEW.

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.

Found out that runtime problem is due to Open VI Reference, which opens a template VI. This template VI contains the Xnodes Code. Information like Icon Image are also taken from that template VI. Just in the moment when I open a template containing other Xnode these all get initialized i think and that takes time.....

I call Open VI Reference in GenerateCode but also in Image to get the actual Icon from the template for my XNode. Icon is also used in Help. Help is called every time I move over the Xnode on my Diagram. Therefore I would like to extract the Icon Image not by Reference-> VI Icon Get as Image Data but directly out of the Binary/String data of my template.vit to reduce the number of Open Vi Reference calls.

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.

I'm not sure if I get your point right.

Example: Placing my Xnode on the Diagram triggers about 10 times or even more often the AdaptToInput Ability VI of a Xnode 3 hierachical level lower. I checked that with a breakpoint.

AdaptToInputs is checking if the input type is same or different. If different, then run GenerateCode, else do nothing. Is that what you meant?

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

But it seems that the type checking itself makes lot of troubles. For example if I have arrays of clusters or any insane combination of different data type I have to generate first of all default data of the new input type and of the existing type. Than I compare their values, if they are equal or not. Their are contained VI's like Variant to Flattened String and some ugly selfmade code to generate default data out of the type descriptor. Then again Flattened String to Variant VI, some loops and so on.

How could I compare just the data type more easily or with less calculation effort?

I don't even know, if that is the only cause for this bad runtime.

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

Problem: BAD RUNTIME BEHAVIOUR.

Even if do not work on the Xnode directly but only on the same Block Diagram the LabView environment is getting slower and slower depending on the depth of the Hierarchie. In my opinion, (I didn't debug it until now) this happens, because the "Child-Xnodes" are updated each time when their "Parent-Xnode" is updated. In my case that means: 100% of processor load for 10 to 15 seconds and RAM consumption raises from normal 200MByte above 600MByte. After the 15 seconds it decreases again to 200MByte. Time and storage consumption may vary on the written routines.

My solution: just update an Xnode (and all its Sub-Xnodes) when I directly work on the Xnode but not when I just work in the same Diagram without changing anything that has an influence on the Xnode.

OR

Just update on dubble click.

Question: How could I Inhibit Ability VI's to run? What Ability VI is called, when I change something in my block diagram? How could the Ability VI recognize if a change on the Diagram containing the Xnode influences the Xnode or not?

Thanks and looking forward to your inputs :-)

Alright, so recently ive run into some trouble with using the scripting tools package. I've been attempting to tag an array control, but when i copy it from the template (the tempmlate consists of a numeric array which is tagged, thats all) and move it to a new vi, the tag disappears! I've noticed that the tag doesn't disappear on the sequences and tunnels used in the example vi's, but they disappear for array controls.

See thte attached screenshot. The first 'find and move' works, but then the find tag doesn't find anything afterwards. However, i can successfully retrieve the tag using the 'tagged object output' of 'find and move'.

Anyone?

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

I am attempting to find how i can tag objects in vi templates as in the example in the codebase:

http://lavag.org/ind...ads&showfile=58

Specifically,

array dimension array - array 1D template.vi

In it, two tunnels are tagged (with the number 0 and 2) and the sequence is tagged as 'script.'

Thanks

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.

Is there an equivalent of a hash table in LabView?

Not that I've seen.

You can build your own hash table system with arrays for storage. The actual hashing function is up to you, as are features like chaining and collision resolution.

You can also implement dictionaries, either with parallel arrays, or using the Variant and Variant Attribute types (which have an underlying red-black tree for speed).

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.

From here. Is yours different?

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>

There is nothing about the XControl that says you can't have another shift register on the while loop.

Or another technique is to utilize the 'Close' ability of an XControl to clear state data that you don't want retained.

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 ?

You could also use an occurrence.

In that case, due to the lack of error-in-error-out to sequence it to the waiting while loop, you could use a flat sequence structure or artificial data flow.

Don't know which people would consider neater or better between the semaphore and occurrence...I have not received that memo

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

As multiple folks have said, in the absence of any data dependency between the loops, the loops will run in parallel as threads become available. One thread may race ahead of the other, one may even complete before the other gets started, and it will be different every time you run the VI. In general, this is highly desirable as it maximizes the use of your available CPUs, thus the answer to your "How can I control this order?" question should be, "Are you sure you want to?" If and only if the answer is "yes" should you try to enforce a particular ordering. Adding a dependency order just to do so only reduces the efficiency of your program and looses one of the biggest advantages of dataflow programming.

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

There was a crash in the site which caused some attachments to disappear. We can ask the moderator to try to find them manually (which I've now done), but I don't know if they will find it or how long it will take them.

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

We had some obfuscated code in this thread.

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.

My first submission wasn't scalable, this one is (up to 32 LEDs). I have the day off today!

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.

[...]

We sometimes hear of a medical doctor moving into politics but I have never heard of any engineers doing such (since Jimmy Carter of course).

[...]

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.

I see now that you placed the code I showed, however you placet it after saving the library, thus thwowing away the info.

I have checked your lvlib, but it fully uses realitive paths (../foo.vi), so I can easily open the lvlib without errors, but when I open the main VI (Make Palettes for Library) it tries to load the subVIs from user.lib/lavacr/.....

What probably would work is saving the tool outside user.lib and submitting that.

Ton

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

Hi,

here is some code that should set the mnu file as the default palette:

[..]

One thing to speed it up, it is good that you refresh the palettes however I don't think this is needed after every library, you can place it outside the main while loop in the Process event.

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.

Here is a XControl design question:

If I want to use user events to generate events in the owning VI where should these events be created? (not generated)

Option A

Inside the XControl and with a read-only property a VI could get the user event and register for it.

Pro: you have a tight integration between the control and the event. Using the Init and Uninit abilities you can exactly define when to create and destroy the event references

- you can have multiple listeners

Con: you can create useless event references which get very much events which are never written.

Can you negate (at least partially) this con by having the event creation happen when the read-only property vi is run. With a simple flag in the XControl state could you then check whether to generate events and destroy it in the UnInit ability ?

I guess there's still be the problem of the user getting the event property, using it once and then ignoring all suvsequent events - in which case you might want a method to inform the XControl that this was the case and replace a simple flag with a reference counting mechanism to keep track of the event being used in multiple places.

In general I like option A better because the XControl defines what the user event data type is - just seems a little bit more robust to my mind.

So the task for someone skilled (or who wants to be skilled) in XNodes is: create a local variable with error cluster terminals

Pretty sure it can't be done - a local variable has to sit on the block diagram of the vi which owns the control. I'm not sure exactly which block diagram an XNode scripts its contents onto, but I'l fairly sure it isn't the parent diagram of the XNode itself. That is of course the main advantage of property nodes over local variables - it allows sub-vis to manipulate the controls of the caller (which of course is a disaster unless you're doing UI stuff....)

Are you able to please list the steps required to show the traditional editor.

Cheers

Ok, further checking, you actually have to break the new icon editor to make it not open in the other application instance (I think I was getting confused with using custom editors in LV 8.6....)

1) Start LV 2009

2) Open <labview>\resource\plugins\lv_icons.vi

3) Make some trivial change that breaks the vi (e.g. create a broken wire segment)

4) Attempt to edit an icon

I made the 8.x LabVIEW Icon Editor appear in LabVIEW 2009!

It was by accident

Has anyone done this?

I can't seem to replicate it.

Nonetheless it is interesting that it is still there.

Yes, I've done that. Attempting to edit the icon of the new LV2009 icon editor will open the 'traditional' editor. I would imagine that any action that breaks the new icon editor or stops LabVIEW from launching will have this effect.