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.
This is about a problem that I had with xnodes and its resolution, just any case some other poor sap finds themselves in the same situation. There may be others that have done more research on xnodes that are aware of this, but I didn't come across any info when searching.
In a set of xnodes I recently created, I attempted to have ModifyCode called immediately after GenerateCode. The last step of GenerateCode, in my case, was always going to be identical to the complete step for ModifyCode. Since GenerateCode has a Response output, I thought a nice clean way to do this would be have GenerateCode respond with ModifyCode. I was wrong. All this does is
a) Not call ModifyCode
b) Cause LabVIEW to throw a DWarn on exit.
Perhaps some more experienced xnoders have some insight as to why what I tried didn't work. In any case, I resolved it by having GenerateCode directly call ModifyCode rather than just responding.