AdamRofer

Name: XNodes - A Crash Course (PowerPoint)

Submitter: LAVA 1.0 Content

Submitted: 03 Jul 2009

Category: XNodes

LabVIEW Version: Not Applicable

Version: 1.0.0

License Type: Creative Commons Attribution 3.0

Potentially make this available on the VI Package Network?: Undecided

This was presented at the 02/22/07 LAVA meeting.

Discusses the various aspects of both XNodes and External Nodes, shows comparisons, and shows example usage.

I ended up skipping over two of the "Creating XNodes" pages since Aitor Solar's XNode Manager is a much better place to create your XNodes with.

View the comments page

Click here to download this file

Name: Picture Hacks

Submitter: LAVA 1.0 Content

Submitted: 03 Jul 2009

Category: User Interface

LabVIEW Version: 6.1

Version: 1.0.1

License Type: Creative Commons Attribution 3.0

Potentially make this available on the VI Package Network?: Undecided

Copyright © 2006, Adam Rofer

All rights reserved.

Author:

Adam Rofer

--see readme file for contact information

Description:

A couple of Picture datatype hacks to illustrate the structure of the (LV 6.1 - LV 7+ is untested) picture control.

-- Main VIs --

Example - Show How Picture Is Made.vi:

Main example, shows (incrementally) how a specific picture is generated by displaying the picture with each packet

incrementally added. Good way to see how your own pictures display information.

Opcodes.csv:

Comma-delimited file explicitly describing the packet types and their requirements / uses.

Tool - Picture concat.vi:

Given two pictures, concatenates the data to create a single overlapped picture.

Tool - Packets to Picture.vi:

Given an array of picture packets (cluster), generates a picture.

Tool - Picture to Packets.vi:

Given a picture, generates an array of picture packets.

-- Utility subVIs --

sub - 8-Bit string to 32-Bit number.vi:

utility VI to cast a string to a 32-bit number. Typecast might work instead but this is more explicit.

sub - Find Opcode:

Given a picture data string that has the size header removed, this will extract an opcode from the front.

sub - Strip top of and check picture.vi:

Utility VI to strip the header (size) from a picture data string so that it can be scanned for packets.

Change Log:

1.0.1: (11/13/06)

Cleaned up code for LAVA requirements:

- Renamed VIs for clarification of purpose

- Fixed coercion dots

- Added 0ms delays in all loops

- Added error encapsulation in some subvis

- Replaced local variable for cluster to constant in order to limit thread swapping between the user interface and code threads

1.0.0: (11/07/06)

Cleaned up code from 6i 2001 version for submission.

Click here to download this file

ABOUT FRIGGING TIME.

That is all.

Also, XNodes would be good to "release," like other people have said. Even if they need to be "cleaned up" for the "public."

- Adam

QUOTE(Aristos Queue @ Aug 3 2007, 12:29 PM)

Eventually someone will ask why non-LVClass VIs can't have recursion. The answer is, they can, and someday they will.

They sure can!

Just pop in this bad boy (commence shuddering and fear): http://forums.lavag.org/Recursion-t9832.html' target="_blank">Rusty Nail

Use caution with them, though. I am not perfect. NI will provide much more stability in this arena than I will with my rusty nails.

This is a posting of code I haven't touched in a while that seems relevant.

This was originally inspired by this forum posting by Norm: http://forums.lavag.org/Automatic-Recursion-t4318.html

External Node: http://xnodes.lavag.org/externalnodes/recursion.html

XNode (LabVIEW 8.20+): http://xnodes.lavag.org/xnodes/code/AHR_Recurse_xnode.zip

This XNode is one that I demonstrated at the User's Group meeting a year ago. It's not tested much, and might need polish, but it seemed to work.

Just make sure your VI is re-entrant for it to work.

If you want to use the External Node, then make sure to enable them in your INI file. I'd recommend the XNode. Just be wary and save your files often when dealing with user-made XNodes!

QUOTE(TobyD @ Dec 28 2007, 01:05 PM)

ALT+0176 will give you a smaller version. Hold either ALT key and type 0176 on the keypad (you must use the keypad - the numbers above the keyboard will not work).

ALT+167 = º

ALT+0176 = °

http://en.wikipedia.org/wiki/Degree_symbol

QUOTE

So, like everyone said, but ALT+0176 is the only "proper" degree symbol (U+00B0, °) (I just learned this today).

---

Adam Rofer

Easy stuff:

1) Keep code optimized, fewest amount of other apps open, etc etc

2) There's tons of LabVIEW only stuff that you guys should list here that I can't think of

3) Keep your hard drives defragged, registry cleaned, etc etc

4) Get XP SP3 when it is released (assuming it doesn't break anything, who knows yet) -- 10% on average increase in application speed from what people have been saying

Mildly advanced fare:

1) Force the application priority AboveNormal/High/RealTime using win32 dll calls (setPriorityClass) or a third-party app that can enforce application priority based on the program (like "Iarsn's TaskInfo"). This affects a single process quite a bit for performance.

2) Optimize your quantum/process background or foreground priority (e.g. big time chunk means less switching to other processes) [see the NI link/Tomi's post above] (and my details on the same thing) -- set this according to if your "target" application is in the foreground or not, and whether or not it will always be.

3) Buy a solid-state/flash hard drive (a lot faster for HDD calls and virtual memory paging)

4) Disable the Themes service (makes things ugly but faster)

Super tweaks to (dangerously) try:

1) Disable Virtual Memory only if you can handle it and know exactly what this entails and sets you at risk

2) Disable services you don't need (sound, indexing service, etc)

3) Any of these depending on your needs

Untested uber tweakage:

1) Play around with some fun win32 calls (I haven't used these):

timeBeginPeriod

LockSetForegroundWindowgetCurrentThread

multiprocessor --> set thread to specific processor(s): setAffinityThread or setThreadIdealProcessor

setThreadPriority

2) There's a way to make certain threads have realtime priority, apparently:http://kotaku.com/336552/windows-media-pla...wow-load-faster

"...this is because media player is the only app known today that uses the MMCSS stuff it elevates the priority of threads in a process registered with MMSCS to the realtime level which cannot be done by an app itself only the MMCSS (a system component) can do that magic..."

...as long as those threads are "registered with" MMCSS, whatever that might entail.

Gotta love the magic. Hope some of these (potentially dangerous) tweaks can help.

Also, there might be something helpful for LabVIEW optimization here: http://wiki.lavag.org/LabVIEW_configuration_file/Unknown

Likely not, though.

---

Adam Rofer

QUOTE(jed @ Sep 11 2007, 01:26 PM)

I would love to do this, but I need to delay the shutdown:

Any idea how to delay it until I am done with some housekeeping?

Or can I figure out exactly what the shutdown params are (shutdown/restart/etc), then cancel it, do my thing and reinitiate it?

I keep a shortcut on my desktop to "C:\WINDOWS\system32\shutdown.exe -a" which aborts any shutdowns that I notice quickly enough. I'm sure a Windows DLL alternative is out there but calling this should work as well.

QUOTE(Aristos Queue @ Apr 30 2007, 02:12 PM)

So do I post the document somewhere or not? I guess not -- I thought it was a free download, but if it turns out not to be I probably shouldn't promote their security mistake.

For me, I get:

QUOTE

A quick click on the "Terms Of Usage" below garners:

QUOTE

It looks like a really cool article.

Yes, AQ, I did intend for "new" to refer to "newly discovered." I also figured that Aristotle had not published without some discourse since, but I am always wary of the way of thought that "everything has been discussed" over these topics (or any topics). As the palimpsest uncovering seems to be from Alexander of Aphrodisias (the Wikipedia article needed updating), I thought that a fresh (counter) look from waaay back when this sort of stuff was just beginning to take fruit would be real nice since OOP has been mulled over in completely new context recently. In learning more about the old philosophies that brought about such conceptual advancements (as taxonomy), people with complaints and concepts targeting OOP can take a step back and say "ok, so this is a fundamental limitation to this way of thought" as opposed to "this is a bug."

In reading what we have so far in the palimpsest, I have the same (shallow) response you do. I'm not as familiar with ancient Greek as I once was, but I do believe that when referring to feet one cannot assume that these feet will be able to move unless the context (namespace) of the type of object is inherent in the discussion. This sort of "same name" difficulty is what can make a language easy or hard to use, versus how fast you can communicate concepts. See it as language compression, if you will. Yes, "foot" means the same thing in that it usually represents something at the end of a "leg" that keeps an item up, and in that sense you can apply anything you want to that definition. I think the flaw is inherent to how you use it...if you say you went into a house and counted the feet you found, nobody could say if you meant animal feet or table feet.

I've played the 20 Questions game several times, and as a result I almost thought about demanding some royalty fees...They usually got my items wrong, and whenever I provided them with what I am thinking of that information was stored. This stored information now helps them sell the portable units that have a stripped down version with probably pretty compressed data stored on the pucks that are sold. Wikipedia, Digg, del.icio.us especially, and virtually any Web 2.0 application has one intended purpose: taxonomy. Taxonomy simplifies thought and focuses efforts on core problems (in most cases, if done properly) and as a result one does not have to work as hard in the best situations of OOP as the same ones in non-OOP languages.

I'm pretty sure we won't see anything that hasn't been asked before, but in this case we can certainly cut through the junk and get right down to the core OOP elements with this discussion (and more appropriately in your new direction here).

I'm glad I could spark such an involved discussion on this topic...I've somewhat avoided OOP in the past!

P.S. The article you link to looks awesome but I'm afraid a lot of people don't have a SIG or ACM membership, which appears to be required. Free web signup does not allow one to download this PDF.

A new critique on the "object oriented" way of thinking has been uncovered within the Archimedes Palimpsest (article here):

QUOTE

A provisional translation of the commentary is currently being undertaken.

It reveals a debate on some aspects of Aristotle's theory of classification, such as: if the term "footed" is used for animals, can it be used to classify anything else, such as a bed?

The passage reads:

For as "foot" is ambiguous when applied to an animal and to a bed, so are "with feet" and "without feet".

So by "in species" here [Aristotle] is saying "in formula".

For if it ever happens that the same name indicates the differentiae of genera that are different and not subordinate one to the other, they are at any rate not the same in formula.

This refers to Aristotle's Categories. From the article Categorization: "The classical Aristotelian view claims that categories are discrete entities characterized by a set of properties which are shared by their members."

And yeah, I know quoting Wikipedia is asking for trouble.

QUOTE(Pablo Bleyer @ Apr 12 2007, 02:03 PM)

Hello.

I've always wondered, is there a direct way of retrieving the value of a control given its reference? Always using variant to data (as shown in the attachment) is tedious and cumbersome.

Thanks in advance. Best regards.

If you know the type of the control (such as Digital), you can use To More Specific Class and cast it to that strict type...Value then returns the the value in the type that the strict reference has.

http://forums.lavag.org/index.php?act=attach&type=post&id=5486''>http://forums.lavag.org/index.php?act=attach&type=post&id=5486'>http://forums.lavag.org/index.php?act=attach&type=post&id=5486

If you don't know how to get a strict reference type, then do this:

a) Find the control you want to get the strict reference type from.

b) Right click on it and select Create Reference.

c) Right click on the new reference and select Create Constant.

d) Delete the item created in step b.

QUOTE(dsaunders @ Apr 12 2007, 11:06 AM)

mballa's post on the property page reminded me of something I was trying to do a while back, which is to invoke the icon editor programmatically.

Has anyone looked into calling the built in icon editor programmatically? I was working on an Icon Editor and I couldn't figure out how to call the built in editor.

If I used a custom icon editor for LV 8+ which replaces the built-in editor, I also had a problem figuring out which VI had invoked the icon editor. I was trying to use the VI name to auto-generate some text for the icon, but I could not get the name or reference of the VI that called the Icon Editor. I tried the front-most property, but the icon editor was already frontmost from the get go. I tried some scripting properties like "Active VI" and "MenuLaunchVI" but also to no avail. Is this a purposeful roadblock or what?

David

App.User Interaction:Edit Icon is what you're looking for, just be sure to pass in valid icon data into "Color 256" or else it won't open.

Attached VI works in LabVIEW 8.0 (and above, I assume).

QUOTE(mballa @ Apr 12 2007, 08:52 AM)

Does anyone have a good method to call the Vi properties dialog page programmatically.

I'm working on an automated documentation vi and would like use the built in LV documentation editor and not have to create my own.

http://forums.lavag.org/index.php?act=attach&type=post&id=5478''>http://forums.lavag.org/index.php?act=attach&type=post&id=5478'>http://forums.lavag.org/index.php?act=attach&type=post&id=5478

From what I can see, you're stuck with creating your own editor.

Use the properties VI.VI Description, VI.Help:Document Tag, and VI.Help:Document Path.

Don't forget to save your VI with the method VI.Save.Instrument before closing the reference.

Of course, someone else might know how to pop up the LabVIEW VI Properties dialog, but I can't find any methods that do this.

QUOTE(rolfk @ Apr 12 2007, 09:02 AM)

Another way is this. It is however Windows only and uses the Windows GDI to print the text to any installed Windows printer.

Strictly taken it is not sending the text to the printer at all, but instead renders the text through Windows GDI and sends the resulting image to the printer.

The most efficient solution I found (no handle leaks or memory leaks, unlike VISA in LabVIEW 6.1) is to open a reference to the "lpt1" "file" and write to it. This is only used for raw text as far as I am aware, and it's definitely a Windows-only solution, but it works fantastically.

No silly CMD stuff is necessary when the Windows API is everything you need.

The attached file is written in LabVIEW 6.1 but it will work in all versions.

Windows APIs used (pseudocode):

Kernel32.dll:

handle = CreateFileA("lpt1", GENERIC_WRITE=0x40000000, 0, NULL=0, OPEN_EXISTING=3, FILE_ATTRIBUTE_NORMAL=0x80, NULL=0)

Error_if_zero = WriteFile(handle, string_buffer, string_length(string_buffer), &number_of_bytes_written, NULL=0)

Error_if_zero = CloseHandle(handle)

QUOTE(Ami @ Apr 9 2007, 01:46 PM)

I'll try this in LV 8.2 and see what happens.

I gave it a shot and the same crash occurred. It's not like it was intended, but it seems that this functionality isn't available yet. The Add Event Method also doesn't seem to let you specify anything valuable. It seems the EventStructure has the exact same items as a MultiFrameStructure, so there's no special functions exposed with the type.

Awesome.

I know the licensing included in LabVIEW 8.0 and beyond has been a show-stopper for some customers.

LabVIEW 7 on a computer with the NILM installed seems to be slower, although I don't have any benchmarks to back this up at hand.

QUOTE(Ami @ Apr 7 2007, 05:23 PM)

Hi Crelf.

Here is the code.

Before you run the "Scripting Tool" VI, please browse for the path of the VI you wish to control (The VI is provided - "Controlled VI").

Thanks,

Ami

I only have LabVIEW 8.0 in front of me right now, but I found out that casting the Event Structure refnum to a Case Structure refnum and then writing to or reading from the "Frame Names" item crashes LabVIEW (now it's getting fun!).

However, writing an array that differs in size with the existing number of Events causes an error 1302: "The size of the array passed in does not match the expected size of the array for the operation."

Perhaps this works as of 8.2, 8.2.1, or future versions, but not in LabVIEW 8.0 at least. I'm guessing that "Frame Names" would be the desired property here.

1000 posts of impressive quality, as well.

:thumbup:

QUOTE(DanyAllard @ Apr 2 2007, 11:51 AM)

Just a note to get this working, you need to enable external node with "ExternalNodesEnabled=True" in Labview.ini

And in my case it doesn't work with drag and drop from explorer, I need to use "Select a VI" from the palette

Dany

Thanks for the clarification Dany, I had that set from before so I forgot it was necessary. What happens when you drag the .vim from explorer onto a Block Diagram?

QUOTE(Aitor Solar @ Apr 1 2007, 10:55 PM)

Does anybody knows what the Macro External Node is for? Is located in the <LVdir>/resource/Macro.llb/;DMacroizer (without extension). Unfortunately, this External Node and its subVIs are password-protected . Presumably, given its name, it transforms something in a "macro" (whatever is that).

Saludos,

Aitor

I'm not sure how far back this goes (probably as far back as the Macroizer thing exists), but this VI appears to run in one instance. Apparently you can have an automatic "macroization" of any VI you want.

(This was tested in LabVIEW 8.20)

Step one: take a VI "xx.vi", rename it "xx.vim"

Step two: drag it onto the block diagram

Now this VI is a subVI, but note you cannot double click on it to enter the VI itself. I imagine that all the other problems that plague External Nodes in general exist here also, which might be why this behavior is not advertised. You can still access the VI through the VI Heirarchy, although if you copy the VI around the Block Diagram then you might not see it listed as a subVI of that VI (?!?!). I'm sure a lot more "interesting" results can be found...I really don't know what purpose this could have, but then again the locked VI might have some more stuff in it than just this.

Weird stuff.

QUOTE(Gavin Burnell @ Mar 29 2007, 01:37 PM)

The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created. As far as I can see, there must be a property or method to specify the expression that the expression node uses, hence one would expect the expression node to be some class different from e.g. the increment function. If one wires an class that is incompatible with the object that New VI Object tries to create then you get a type cast error (e.g. try specifying a terminal class constant while creating an add function). Compatible in this case means that the class you specify is either the same as the actual class of the object, or a superclass. The reason that wiring the generic class works, is that generic is a superclass of lots of things, but it does mean that you can't do very much with the object you've created without casting it to a more specific class first, for which you need the correct class constant... By replacing the generic control with more specific class types in turn, iterating over the class heirarchy and spotting which generate errors and which don't one can map out the specific heirarchy of the object that one is creating. Thus, I've got as far as 'Node' but no further.

Actually, thinking about it, if I create an expression node on a block diagram, I wonder if I can interrogate that from another vi to determine the class type of all the nodes on the block diagram. Will go and try this...

I started off that way to try to find an answer to your question, and it tells you that it's a Node (surprise!).

You can typecast a similar object to acquire a similar function that isn't necessarily exposed on that object, as Yen pointed out in this forum post: http://forums.lavag.org/How-to-get-reference-to-Text-of-StringConstant-t5791.html' target="_blank">How to get reference to Text of StringConstant?

I couldn't get any probable casts to work, I thought Formula.Formula Expression would be the closest match. Decoration.Text.Vertical Arrangement is another property that should work but doesn't, possibly indicating that scripting on this object type is (for now) not possible in the way you need to.

The most I was able to do is get Node.Style to tell me it was an "Expression Node"

Keep trying, though, and let us know! :thumbup:

EDIT: It looks like the setup is almost identical to UnitCast (Convert Unit) objects, but the UnitCast.Unit property still doesn't yield the Expression Node stuff. Decoration.Text.Vertical Arrangement on UnitCast items is also not possible, oddly enough.

QUOTE(i2c @ Mar 25 2007, 03:23 PM)

Hi

I was wondering whether anyone has any experience of creating ActiveX components for use within Labview? I'm pretty new to Labview in general but pushing ahead and quite enjoying it, yea yea so that irrelevant, but hey!

I'm pretty competent in both C++ and Visual Basic 6 so can use either of those for creating my ActiveX component.

I'm not at work at present so can't log into my NI account to search properly but I was wondering whether there were any quirks to watch out for and ideally if theres any tutorials out there that I can look at to get a better idea of how to push ahead with this more complex element of my project.

Thanks

I have used quite a few ActiveX components in LabVIEW and I've discovered a few things over time:

1) In LabVIEW, always close your references; always close your references. Always close your references. If you don't then bad things might happen, like random hangs.

2) Variables (such as the TimeStamp in LV 7+, aka Date in VB6) don't always match up perfectly, so experiment before releasing stuff to other people.

3) Any problems in your ActiveX component (memory leaks, handle leaks) will still exist, so make sure you don't open a reference to a registry location without closing it.

4) If there's a "hidden" ActiveX Property/Method then you can't explicitly "call" it in LabVIEW like you might be able to in another language.

5) Using ActiveX in LabVIEW is pretty easy.

6) Play around a bit with the whole compatibility thing (binary, etc). If you upgrade a component that breaks compatibility then sometimes LabVIEW will make you go through and re-select every Property / Method you have wired up. You cannot have compatibility sometimes when you modify a Property or Method. LabVIEW will always force you to see that things have changed, so just be aware and listen to the Diagram Errors box when something won't run after you upgrade a component.

7) "regsrv32 abc.dll" and "regsrv32 -u abc.dll" are your friends (register and unregister AX components). If you don't explicitly ask VB6 or your C++ compiler to do this already, you have to make sure to (a) close LabVIEW, (b) unregister your old component, © open LabVIEW, (d) make sure things still work with the new version.

As for tutorials, the help file should have some stuff about it, but http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/using_activex_with_labview/' target="_blank">Here is some information on NI's site.

Voting "never" did not work for me, or seemingly the other 0 people.

Fantastic job on this! :thumbup:

This adds the primary necessary functionality to create XNodes now, let the games begin!

One thing that could be added is the documentation for each ability. Sounds tricky, but then again you can find them here:

1) Open Labview 8.x\resources\lvstring.rsc

2) Search for "This is a strict type definition"

3) This refers to the State Ability...the rest follow, separated by x00 or whatever bytes that show up as

Keep in mind the list has grown in LabVIEW 8.2, so don't get the info from the 8.0 folder!

You can probably parse it out, make sure things are pointing to them, whatever here.

I might poke around for a fuller Ability list than what you have (you have most of them), I'll let you know.

Take a look at the presentation I gave last night at LAVA...I ended up skipping over the two "Create an XNode" pages since your utility does all this now! :thumbup:

I'll be posting my example XNode (Recurse) in a couple days when I get a chance to clean it up for the Code Repository.

I'd like to attach the presentation, but it's more than 2 megs.

XNodes Presentation - Lava meeting 02/23/07

QUOTE(Aitor Solar @ Feb 21 2007, 11:50 PM)

That's the tricky part: not all the abilities in that llb work properly. Some of them give an "ability not recognized" error (different from the "parameter X has incorrect datatype" error, that just means the inputs / outputs for that ability are not what they should).

I've noticed some XNodes that have abilites (GetImage.vi) that instead say the ability is the "old" name (Image). Check my ppt presentation for the "old" (8.0) list versus the "new" list (8.2).

If an ability has a 2, 3 following it then it's the working Ability name (example: AAA, AAA2, AAA3). If it's something like "OnXXX" (in LV8.2) and the original is "XXX" (in LV8.0) then the ability "XXX" is the real name, despite the .vi being called "OnXXX" inside the LLB you refer to.

Does that make sense? Not very consistent. I'm also not sure if this is true for all of the "new" names but I noticed it for most of them.