flarn2006

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.

VISA is ok but not everyone uses it so...

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

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

Hedge, is that you? 😉 EDIT: If you don't get it, just pretend I'm insane. Have you tried passing it a preallocated string? preAllocateStringsUIEnabled=True preAllocateUIEnabled=True preAllocateEnabled=True Right-click string control/constant, Set String Size

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.

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!

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

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

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.)

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

Ah right, I forgot about that. Though I swear I remember using a trial version on my Mac at some point back when I used one. I wonder though, do they really need anything elaborate for a license manager? I doubt it would be difficult to put something together from scratch. I guess it wouldn't necessarily be worth the effort for a free product though—hell, I wasn't expecting them to ever give away LabVIEW for noncommercial hobbyist use at all, as much as I hoped they would. I already filled out the Site Feedback form reporting it as a bug, but I guess if nothing else it'll make them aware that the message is misleading. I'm going to try bypassing the NI Package Manager by copying an already-completed installation from a VM into Wine.

Has anyone mentioned how long it takes to start up?

It specifically says "previous versions" in the message.