By
bbean,
in Code In-Development
-
Similar Content
-
By hooovahh
View File Hooovahh Array VIMs
Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette.
Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are:
Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)
-
By hooovahh
Here is the Hooovahh Array VIMs. This initial release contains VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette.
Version 2.0 changed the suffix naming standard. Updating may mean replacing calls to the new versions since the name on disk has changed. This was for consistency and I'm sorry for breaking compatibility. The added type defs in 2.0 may break compatibility too but these help avoid code breaking bugs since VIMs allowed any data type previously.
Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates.
Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are:
Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort -
By X___
For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool.
The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried.
This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type?
Enters the Types Must Match function:
I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim
Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored.
Of course, as the comment on the diagram says:
"This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details."
Here is the context help for Types Must Match:
My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...
-
By jacobson
I am getting this strange error whenever I try to drop a .vim into a VI that is saved. If the VI is not saved, everything seems to work but as soon as I save it and try to drop in a .vim, I receive this edit time error.
This happens to any .vim file, even blank ones that I have just created. If I double click on the error then it will highlight a specific object that I can delete but the object is otherwise invisible and unclickable. This started happening right after I tried to add a VIM through scripting. I can actually still add a VIM through scripting but it has some pretty interesting context help.
So I guess the question of the post is what the heck did I do and how can I get LabVIEW to start behaving again.
-
By bbean
I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures. With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference. Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster. This video shows the "problem" and the potential solution using the xnode:
Re-Label Xnode - Event Registration
Here's another example showing another use case with ShaunR's VIM HAL Demo code:
Re-Label Use Case ShaunR HAL Demo
This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback. I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog). You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete.
The Double Click ability is also a work in progress. Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection. You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link". Something I'm trying to avoid.
The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice. This seems to update attached event structures.
- B
sobosoft_llc_lib_diagram_tools-1.0.4.1.vip
-
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.