Sparkette

Yes, LabVIEW has operator overloading, or at least a form of it. It's what the matrix typedefs use to override various math operators, where it replaces them with a subVI.

Operator overloading, as far as I can tell, is undocumented, and not used anywhere outside the matrix typedefs. It's configured using a "NI.LV.All.OperatorInfo1" tag on the control VI, set using the private method "Tag.Set Tag".

I've attached a VI I was using to mess around with; it's supposed to create a string typedef which, when wired to a Multiply node, will replace said node with a Three-Button Dialog subVI, but it seems I haven't gotten it to work yet. I haven't really investigated that much, and I'm sure I can figure out what the issue is, but I thought I'd share my VI anyway. In addition to creating that VI, it also loads the NI.LV.All.OperatorInfo1 tag from the RealMatrix typedef as a working example.

It's worth pointing out, for anyone else who feels like experimenting, that there's a "Debug Operator Overloading" toggle in the Ned options, as well as an "Available Implementers" section in Heap Peek which seems to be related.

Operator Overloading Test.vi

Hey, that's pretty cool. If you still have it, would you be interested in posting the files?

I don't know what National Instruments was thinking when they decided not to include this control in the official LabVIEW distribution.

Both eyes are included and automatically synchronized, so you don't need to worry about contracting lazy eye.

Googly Eyes.ctl

I just tried to update my profile to list LabVIEW 2021, but it wasn't in the list.

On 12/15/2021 at 6:25 AM, Rolf Kalbermatter said:

And the Community Edition does not include things like RT, FPGA, and just about every other thing with a paid license including the Application Builder.

Community Edition does have Application Builder.

On 1/8/2022 at 6:42 AM, Rolf Kalbermatter said:

While I do believe that the LabVIEW developers and the managers who directly work there really would like to make LabVIEW a good and flourishing product, I feel the higher management has already decided that this is going to be a dead end and have very little intentions to do anything else than let it bleed to death, so they can get rid of that liability.

Are you saying you think they're looking to discontinue LabVIEW? If they aren't going to sell it anymore, it would be great if they'd make it open source. Not sure how likely that is though.

3 votes for XControls; seems legit

EDIT: Oh wow, 7 years since a reply to this thread? I guess that doesn't matter since it's a sticky post though.

7 hours ago, dadreamer said:

Did you know that this option shows "Autopreallocate arrays and strings" checkbox on VI Properties -> Execution tab?

Here's the excerpt from the LabVIEW Help about this setting.

 

Oh, no I didn't. I actually forgot that the fixed-length string UI was used for FPGA's.

On 10/2/2020 at 3:05 AM, dadreamer said:

I have not, but I just tried and saw no difference in passing strings into CLFN (no matter, if variable, bounded or fixed length). I think, it could be some archaic setting for early LVs before 2009. It even doesn't cause a VI to be recompiled unlike "Type Only Argument" option. It just adds 0x40000 to the flags field in the terminal's DCO properties.

Having played with that flags field a little, I can conclude, that it affects IDE behaviour and the terminal look only (to accept some wire(s) or not), but has nothing to do with the compiled code execution. For example, with value of 0x30000 I'm getting this.

These tokens should be added to this thread for sure.

Oh, forgot I posted that thread. Thanks

If you use Ctrl+Shift+D,|, it will enable logging DPrintf messages. Then you can do Ctrl+Shift+D,P to display a list with most of them:

LabVIEW internal debug keys - Ctrl + Shift + D + one of the following
 |  toggle DPrintfs.  Currently on.
 :  print global font table
 A  check app heap
 B  print TD dictionary stats
 D  PrintDSStats
 E  toggle QElement checking
 G  toggle StripChart scroll/copybits
 H  show/hide heap peek.
 I  print heap text info
 J  rebuild all malleable instance VIs in current VI's context
 L  prints linker graph viz info
 M  toggle memory checking.
 N  show Ned, the friendly debug options dialog
 O  toggle drawing on/offscreen
 P  prints out this list
 Q  toggle show nonIP terms. currently off
 R  print VI Server info
 S  print net connection table
 T  toggle print compile stats. currently off
 U  toggle sanity checking. currently on for compile/save
 V  print all OLE Variants
 W  show window monitor
 X  toggle new Preferences dialog
 Z  print execution and eventQ status
 {  compact DS now.
 }  toggle gUseNativeFontSizing currently %s
 " print HeapTextRec line table.
 ~  toggle unattended mode
 <  toggle clump display (use ctrl-shift arrow keys to cycle thru clumps)
 &  print heap text font runs
 _  wireframe 3D controls
 >  ActiveX Control Property Browser
**** NOTE **** Debug keys are preceded by Ctrl+Shift+D !!!!!
**** e.g. Ctrl+Shift+D+N shows the debug options dialog.
**** You have 3/4 of a second after hitting the D to hit the N

There's a few missing, however. Pressing Ctrl+Shift+D,C makes LabVIEW check the "HedgesSpecialCrash" INI key, and presumably if it's set to some specific value (not True) it'll crash. (Edit: the value is 1, and yes, it crashes with "Hedges Special gDAbort".) Ctrl+Shift+D,+ checks the "FakeInsanity" key; I tried setting that to True but there wasn't any visible effect there either. (Edit: I set it to 1, and Ctrl+Shift+D,+ made it crash when I right click a terminal.) For me, Ctrl+Shift+D,: didn't display the font table, but it checked "HedgesSpecialDWarn". I think the options for this key are "single", "singleLots", "multiLots", and "multi100", though I only tried the first. As expected, it triggered an internal warning. There's also Ctrl+Shift+D,!, which DPrintf's output like this:

DPrintfVIObjRefList: [VI "GSW.lvlibp:GettingStartedWindow.vi" (0x0000000006d107d0)] objRefList has 7 obj refs
....[00] (787480577) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006ce0318}, subKind=0, subIdx=-1
....[01] (882901084) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006ce0408}, subKind=0, subIdx=-1
....[02] (881852507) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006c89dc8}, subKind=0, subIdx=-1
....[03] (880803930) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006c7c598}, subKind=0, subIdx=-1
....[04] (883949661) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cdfaf8}, subKind=0, subIdx=-1
....[05] (879755353) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cde5e8}, subKind=0, subIdx=-1
....[06] (884998238) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cde008}, subKind=0, subIdx=-1

On 9/5/2014 at 1:08 PM, ned said:

I really hope one of them has an exciting-sounding name, but actually just introduces random crashes.

Hedge, is that you? 😉

EDIT: If you don't get it, just pretend I'm insane. 

On 5/22/2020 at 8:54 AM, dadreamer said:

allowPreallocsInDll=True - adds "Allow Preallocated Data" option to CLFN context menu, when clicking on a node's terminal (off by default). Did not study this one well, but it seems to not do anything or I'm wrong? Here's its scripting counterpart.

Have you tried passing it a preallocated string?

preAllocateStringsUIEnabled=True
preAllocateUIEnabled=True
preAllocateEnabled=True

Right-click string control/constant, Set String Size

6 hours ago, dadreamer said:

A few WinAPI calls are used there. Besides of that I suppose that assembly blocks should be altered and the hard-coded offsets should be checked as well. It all needs a time to debug on those platforms. I have VMs for Linux/macOS on one machine only, so... Do you really need this on Linux or macOS?

It would be nice to have it cross-platform, but it's hard to bring myself to ask when you've done so much already! Don't feel like you have to worry about it.

Wow, awesome—I would never have thought anyone would go to so much effort for this! Thank you!

I do have one question: what is it that's stopping it from working on Linux/Mac?

Awesome that it works! I'll add it to the LabVIEW wiki.

I'm already aware of how to do it on Windows; at first I thought you were saying it works on there too (which I haven't tried in the latest version, but have no reason to think it would work there.)

Has anyone else wanted to be able to simplify their block diagrams without saving lots of subVI's that will only be used once? Like an embedded subVI? I feel like I must be missing something because as far as I can tell, this functionality is already 99% of the way done, and not even hidden. LabVIEW just doesn't ship with one that you can actually put whatever you want inside. And yet, this feature can be trivially created using what I'm pretty sure are all officially-supported LabVIEW features:

This is nothing specific to VI scripting; that's just what I decided to use for the example as scripting diagrams tend to become unwieldy pretty quickly. Yes, that's an Express VI. Except instead of a configuration dialog, it opens a blank VI to edit. You can double-click on it to open the VI for further editing. It all saves inside the main VI. And it doesn't even add any dependencies to the VI—dependency-free—the only thing you need the express VI files for is if you want to conveniently edit the contents without converting it to a regular subVI; it'll load and run perfectly fine.

Here are the files just in case, but it's not quite refined yet. And again, there might even be something I'm unaware of that makes this unstable or poorly compatible or something, as I don't recall ever seeing this technique used before, and it seems like something that would ship standard with LabVIEW.

_SubdiagramConfig.llb

SubdiagramSource.llb

This is probably better for Code In-Development, but I already typed it all out and uploaded/placed attachments here before realizing, so hopefully a moderator won't mind moving it there for me if I can't do it myself.

TL;DR: Linux and Mac users, you can enable NI's hidden XNode development feature by adding the following line to your LabVIEW configuration file:

XNodeDevelopment_LabVIEWInternalTag=True

After doing this, you can create a new XNode from the File->New dialog, and edit existing ones without them just showing up as locked.

Original post:

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)

Buried inside LabVIEW's resource files are several resources with the type "TMPL". They contain information that looks like it could be incredibly helpful in figuring out the structure of many of LabVIEW's internal resources. They're in a binary format, but it's quite trivial to parse, so I quickly put together a tool for loading and viewing them.

Template Viewer.zip

For more information, see this page, which appears to describe the same format: https://www.mathemaesthetics.com/ResTemplates.html (Change the URL from https to http; the forum won't let me add http links for some reason.)

Okay, well thank you very much regardless! I seriously appreciate the effort you both put in!

8 hours ago, LogMAN said:

If we are talking about automating factories, isn't Factorio the game of choice, rather than Minecraft? 😋

 

Maybe; I've never played Factorio. My question might apply to that too.

As we all know, automating industrial systems is a huge use case for LabVIEW. As it happens, building these types of systems in Minecraft (with varying levels of realism) is a popular activity among players of mod packs like Feed The Beast, which add a lot of high-tech craftables to the game. Which makes me wonder: has anyone tried using LabVIEW to control factories in Minecraft? You could probably set something up pretty easily with a mod like ComputerCraft or OpenComputers, which allows for opening network connections. Just write a program in-game to communicate with something in LabVIEW and pass data around.

Maybe someday there will even be a mod designed for this purpose, with craftable in-game versions of real NI hardware—I wonder what the crafting recipe for a PXI chassis would be? And the mod could install a virtual network adapter on your PC that would show up to LabVIEW as if it were actually one of those devices. (Maybe even emulating them—isn't the firmware available free through NI Package Manager?)

Come to think of it, now that Community Edition is a thing, I could even see NI assigning a small team to make that mod; it could be a fun way to spread familiarity, and even some degree of experience, with their hardware.

EDIT: Just for fun, I submitted it to NI Idea Exchange. https://forums.ni.com/t5/PXI-and-Instrumentation-Idea/Make-a-Minecraft-mod-that-adds-in-game-versions-of-NI-hardware/idi-p/4084512?profile.language=en

3 hours ago, dadreamer said:

This gives you a pointer to VI Data Space, not to the object's own space. Well, I see what you want to obtain, so I recheck later, whether it's possible to retrieve a pointer to the object itself.

Thanks! I'll be sure to post here if I find a way too. Might be able to do some cool stuff with the VI data space as well, once I read up on what that's about. Cool to see more people interested in exploring LabVIEW's attic

14 minutes ago, dadreamer said:

Do you need VI Data Space pointer? If yes, then you could use GetDSFromVIRef internal function - check my samples with ReadDCOTransferData / WriteDCOTransferData calls. That function is available in LabVIEW starting from 2009 version.

That's very interesting, thanks! However, I tried it and it doesn't give me the pointer I needed. Unless I'm doing something wrong?

That is, to get the address that would be shown in the Heap Peek window. I doubt there's an official way to do it, but is anyone aware of a private method or named internal function to do it? I'm sure I could locate the reference table in memory and look it up there, but I'm not sure if there's any way to obtain the address for that in as much of a version-agnostic way as possible. (And yes, I know the internal structures at those addresses are subject to change regardless. But ideally I'd like some way to do it that won't break just because a minor unrelated patch happened to place something at a different memory address.)

1 hour ago, Neil Pate said:

I especially like the bit where it locks up my PC so hard that even the mouse stops responding.

I've never experienced that myself, but that's probably because I've only ever tried running it in a VM.