By Rolf Kalbermatter
It's nothing to fancy. I added a few things to the UI to support more features and in preparation of adding the VI renamining/relinking step that was done seperately in the OpenG DEAB tool before calling the OpenG package builder. But I never got around to really add the deab part into the package builder. It's kind of extra difficult as the DEAB compononent doesn't currently support newer features like lvclass and lvlib at all and of course no mallable VIs etc.
I can post what I have somewhere, but don't get to excited.
By John Lokanis
One of the main topics of the 2018 CLA Summit was the need to improve access to open source code in the LabVIEW community. This is something that I have tried to do in the past with limited success. After hearing what others are doing and discussing the issues, I am inspired to take on the task of getting as much of my code that is shareable out into the open for others to use, improve, learn from and critique. So, the point of this thread is to figure out how best to do that.
I have tried posting code to forums in the past. I have even posted to the code repository here on LAVA. I have used code posted here and via the tools network and VIPM in my own projects. But I am not sure if any of those avenues are the right path forward for me. There was much discussion about different open source repositories on the interwebs that we could leverage. There was also some discussion about how to help others discover the code you shared. What I did not hear was any definitive conclusions on how best to do this.
So, the point of this thread is to try to solicit feedback on code sharing and come to some sort of consensus on the best options out there. If you have an opinion on this please join the conversation and share what you think is the best solution. Here are some questions I am trying to answer:
1. Where should we share code? What system works best for LabVIEW code and is user friendly enough to not discourage people from using it? Please share links and how-to documents for your preferred site/system.
2. How should we license code? I heard some discussion about the various type of licenses. I am not interested in retaining any rights to code I share and do not want to put any burdens on those who want to use and learn from any code I share. What licence is accepted in the open source community that supports this kind of sharing?
3. Once we post, how do we make our code discoverable? Do we need to post links all over the place or is there a better way? Here is one attempt at making that better you should check out if you have not already:
I am not just interested in putting the code out there, but also trying to explain why I think it is worth your time to take a look. I am willing to post on forums, create a blog, even produce some vlogs on YouTube if it is the best option. Please let me know what format would motivate you to take the time to learn about the open source code out there.
Either way, thanks for taking the time to read this thread and contribute what you can, even if it is just to follow the discussion and learn from others like I am trying to do.
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.
While I was having some time to develop new scripting stuff i wondered "would it be possible to add somme scripting stuff in the VI toolbar ? " (the one with run, run-continuously, abort, police stuff and so on). My point is to add kind of a combobox that populate with every events in the current vi for a control when clicking on it. And of course show the effective event and make it blink when selecting it in the combobox.
The scripting part is almost done but i now come to the real problem :
"How can I add this piece of code in the VI toolbar ?"
I know i can create either a Quidrop Plugin or a shortcut menu plugin but they don't fit the way i wan't to use this plugin.
I asked some NI guy that told me the only options where the one above but I can't imagine that LabVIEW is not in some way developed around a "plugin architecture" so if any of you as plunge deep into LabVIEW's files and know where and how to achieve this goal it would be really nice
Thank's everybody and I hope my question was clear.
Hello everyone, I want to share a VI that I recently created to search for orphan files in a (very! ) messy project. As it turned out it's actually very easy to do that (if you find super-secret stuff on the net):
This VI will find files (VIs, Controls, Classes, etc...) in your project folder that are not linked by a given top-level VI. This is done by comparing the call-chain of the top-level VI with the files on disk. It assumes your files are in folders relative to the specified root directory. This also means that files outside the hierarchy will be ignored (vi.lib and such).
Be aware of (at least) two things:
This VI will return false friends if you happen to have any "Open VI Reference" call with constant VI names or paths connected to it (not a problem if you use static VI references). VIs in diagram disable structures are not listed in the call-chain. So if you use conditional (or regular) disable structures this VI will return false friends. Does anyone know a solution to number 2. actually?
Hope this proves useful to you too.