LabVIEW's built-in XNode editing tools are enabled using a license file, rather than a simple INI toggle. Presumably they do this for stronger discouragement from unofficial use, as hacking one's way past that feels a lot more "shady" than just adding a line to a config file.
But what about the Linux and Mac versions? They don't have a license manager, so how is XNode development enabled there? One might guess that those features simply aren't compiled into the released builds of those versions, but there is actually precedent to suggest otherwise. VI Scripting used to be similarly restricted using a license, but then they made it public. At the time, LabVIEW didn't have a toggle in the Options for it. But they didn't need to release a patch to add one. Instead, they simply published their formerly-internal license file, and set their activation server to accept requests to activate it. And yet, Linux/Mac users weren't out of luck: it turned out that for them, it actually was just a configuration key.
The VI Scripting license had the internal name "LabVIEW_Scripting(_PKG)". The Linux/Mac configuration key was "Scripting_LabVIEWInternalTag".
At 17:48 in this video, several XNode-related configuration keys are shown, likely found in strings in the EXE or resource files. One of them is called "XNodeDevelopment_LabVIEWInternalTag". Guess what the internal name of the XNode Development license is.
I don't have the Linux/Mac version to test with, but I know a pattern when I see one. The following command was given in the readme for the VI Scripting package for Linux:
echo -e "labview.Scripting_LabVIEWInternalTag:\tTrue" >> ~/.labviewrc Here are the Mac instructions:
If you have either of those versions, it's probably worth a try: follow those instructions, but replace "Scripting" with "XNodeDevelopment", and see if you can open an XNode in the IDE, or create one from File->New. (Also, in the case of Mac, replace 8.6 with your actual LabVIEW version if necessary.)
(Here's where I got my information about enabling scripting: https://forums.ni.com/t5/LabVIEW-APIs-Documents/LabVIEW-Scripting/ta-p/3535340?profile.language=en)
We've lost something useful in the "official release" of Malleable VIs (.vim files aka VI Macros) in LabVIEW 2017. In previous versions, because VIMs were built around XNodes, then you could right-click the XNodeWizardMenu to look at the Generated Code given a particular wiring. There's no such option in 2017, even with the appropriate LabVIEW.ini keys. Is there another ini key that provides a similar functionality again? I find it a useful check that the VIM is coded correctly. The closest is to "Convert Instance VI to Standard VI", however that removes the VIM.
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.
I'm trying to do some scripting on a Realtime-VI wich uses the FPGA Interface "Read/Write Control". I open a Reference to a VI containing a Read/Write Control, and when scrolling through the BD-Objects I find it with the class-name "nirviReadWriteControl".
I used the "to more specific class"-VI to check wich class i can cast it to, and i tracked it down to be child of the GObject->Node Class. But i can't cast it to any of the childs offered in the class specifier constant.
I also found out, that the "nirviReadWriteControl" is a xnode.
I have never worked with those, is there a way to access theyr methods (I think they're called "abilities" for xnodes)?
The goal of the application is to make the Read/Write Control display all available FPGA FP-Elements, and connect Controls/Indicators to them.
There is the same Problem with the "Open FPGA Reference"-Node (Classname "nirviOpenFPGA").
I really hope somebody dealed with the xnodes a bit and can help me programmatically controlling them!