Leaderboard

I've developed a few experimental XNodes to assist with running VIs asynchronously. The ones pictured here are LV-Async.xnode and LV-Await.xnode. You can drag a VI onto LV-Async. It will open or check out (more on this later) a VI reference with code x100. LV-Await.xnode will Wait on Asynchronous Call, but instead of closing the reference it will check it in to a lookup table to be later used by LV-Async.xnode. The benefit of this is that when used with a reentrant VI, the asynchronous hierarchy will not go idle, so reference types created in the hierarchy will not go bad. There is an example in the VI package that demonstrates this behavior. The downside is that the memory the hierarchy uses does not get freed (subsequent async/await calls do not leak memory though since the hierarchy is being reused). LV-Async-And-Forget.xnode opens the VI reference with code x80 and closes it after running the VI asynchronously. LV-Async-Or-Show.xnode is meant for non-reentrant UI VIs. If the VI's front panel is not open, it will run the VI with option x80. If the front panel is open, it will bring the front panel to the front. Attached is a VI package that will add these nodes to your palettes, along with a couple package dependencies. Source code for LV-Async is here: https://github.com/erdosmiller/lv-async LV-Async requires LabVIEW 2015 or later. Let me know what you think! lv_async-1.0.0.12.vip lv_scripting-0.7.0.6.vip lv_vi-0.0.0.5.vip

View File XNode Editor 8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs. In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. The original thread with discussion and progress on this tool was started here. Submitter hooovahh Submitted 03/15/2017 Category XNodes LabVIEW Version

I always loved this idea exchange idea to add sum types to LabVIEW: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525 I was sad to see that it was dismissed as being classes. I think there are differences, and that having these kinds of types in LabVIEW could be nice, so I jank implemented them using XNodes: LV-Define-Tagged-Union.xnode takes an enumeration and a cluster as inputs. If certain enum values have data associated with them, the cluster should contain an element with the appropriate type and the same name as the corresponding enum selection. The output of this node is an enum & variant cluster or "tagged union". This output can be bound to an existing typedef by right-clicking on the node. LV-Construct-Tagged-Union.xnode takes a tagged union created by the define node at the top input and gives you a drop down menu. The input type adapts appropriately. LV-Case-Tagged-Union.xnode goes inside a case structure. It's output type adapts based on the frame it is in. Source code can be found here: https://github.com/erdosmiller/lv-tagged-union I've attached a VI package that will add these XNodes to your palette, along with a package that will install a scripting library that this depends on. I wrote this awhile ago, so I don't remember all the details, but some types like .NET references may not be supported yet. LV-Tagged-Union requires LabVIEW 2015 or later. Let me know what you think! lv_tagged_union-0.0.0.7.vip lv_scripting-0.7.0.6.vip

This should be a bold pop-up for the first 10 times anyone drops a vision VI. Image wires are references.

No-one has stated categorically, so... The first image is a raw, unadulterated image of the part under inspection with a rake overlaid. Whilst you can take measurements that way, it is very lighting and part specular dependant. To make more repeatable measurements you post process (threshold in this case) to remove noise and make features more defined. The result is a binary image. You then apply the rake to the post-processed image (second of your images). None of this is camera dependant so changing camera properties does not yield the second image unless it is a smart camera with post-processing (threshold) on board. So how would you create the first image? Two ways: 1. Acquire an image and use the Horizontal Clamp to to make your measurement (it will add the rake overlay). 2. Acquire an image. Make a copy (using the IMAQ Copy Image primitive) then apply a threshold to the copy (there are a couple, one of which I gave earlier) . Next, use the Horizontal Clamp on the copy then copy the Overlay (IMAQ Copy Overlay) onto the original image. This will give you the measurement repeatability of the second image with an output of the first. Note that operations on IMAQ images are destructive so if you want to keep an image after processing you must make a copy of it before the processing.

Often in vision if a picture is analysed then the original is overwritten / destroyed. Is it just a case of taking the image reference before the processing and then overlaying the analysis result onto the original Image. Difficult to explain and I do not have the vision toolit to hand. You often have to copy the original image and use one copy for image processing, then overlay the results onto the original Image, not the processed one.