Aristos Queue

I have no idea what other DLLs that one calls. This is really weird.

Weirdly, yes, it does make sense. This is what would happen if the DLL was corrupt and couldn't load. The DLL is found on disk, but it could not load. I don't know exactly how the node is getting the build machine's path, but that would be the path it had the last time it resolved successfully, so I'm betting it is encoded in there somewhere and being used as a fallback location. Has someone been rewriting your DLL on disk? Can you try copying that DLL from a clean installation?

Is this desktop LV or target LV? What is the actual path on disk to that Mean.vi?

Is there anything you can think of that has been done special to this machine? Did you get someone from NI to send you a custom patch that has never been generally released? Like, I'm seriously grasping at straws here... we grep'd the binary of Mean.vi -- that path does not appear anywhere in the shipping copy. So somehow you have a copy of Mean.vi that is not the one that is installed by an installer. I would say "it's a fluke" except for that post earlier that someone else had this happen to their LV2017! Now I have a real mystery.

@NeilPate : please run the attached VI on your misbehaving Mean.vi and tell me what path it shows. Read path to analysis lib.vi

Here's what should be happening... The path saved inside Mean.vi is (should be) a symbolic path to the analysis library. The exact thing saved should be <resource>:\lvanlys.* which you would see if you use the private Application method. (Actually, you'll see the "*" replaced by "dll" because the method does that small bit of platform-OS interpretation of the path.) That symbolic path gets interpreted when the VI loads into memory. That means that... ...if you open up the Mean.vi and open the configuration dialog of the Call Library Node, you should see an absolute path that leads to the lvanalys.* on your machine. ...if you move the VI out of vi.lib and to some other location on disk, you should still see the same absolute path. ...if you open that VI with a different copy of LabVIEW, you should see the path of that other LabVIEW's analysis library. But given what you're seeing... It seems like whatever the absolute path is being saved is not being saved as a symbolic path. "e:\builds\penguin\labview\branches\2019\dev\dist64\resource\lvanalys.*" is the directory on the build machine where the installer is created. I don't know of any way for this edit to be made, but clearly, it is happening. It seems impossible that we could be making this mistake everywhere... we would have lots of customers complaining about an inability to build apps. Heck, the VI would be broken in the editor! Very strange.

Nothing looks broken to me in LV 2019. I've attached my 64-bit LabVIEW 2019 Mean.vi... does it work for you? I tried several different ways of moving the files around without any problems. Mean (DBL).vi

Figured someone over here might be interested... over the weekend, I built a new right-click menu item plugin for editing set controls and constants. The UI is bad, but it works; if anyone wants to work on the UI, you're welcome to do so. Building a map editor would follow the same pattern as the set editor. https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Edit-A-Set-Value-llb/ta-p/4020190

The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.

Found a fix for this. It should be fixed in LV 2020. The bug ONLY affects copying from a 1-element cluster of variant to a variant. Or a cluster of cluster of variant to a variant. Or... you get the idea... "any number of cluster-shells all containing 1 element, culminating in a variant" being copied to a variant. This was a fun bug... consider this: The memory layout for an byte-size integer is { 8 bits } The memory layout for a cluster of 1 byte-size integer is { 8 bits } They are identical. "Cluster" doesn't add any bits to the data. That's just the type descriptor for the data in that location. This is true for any 1-element cluster: the memory layout of the cluster is the same as the memory layout for the element by itself. This is true even if the 1 element is a complex type such as a nested cluster of many elements or an array. When a VI is compiling, if data needs to copy (say, when a wire forks), LabVIEW generates a copy procedure in assembly code. For trivial types such as integers, the copy is just a MOV instruction in assembly code. But for compound types, we may need to generate a whole block of code. At some point, the complexity is such that we would rather generate the copy procedure once and have the wire fork call that procedure. We want to generate as few of those as we have to -- keeps the code segment small, which minimizes page faults, among other advantages. We also generate copy procedures for compound coercions (like copying a cluster of 5 doubles into a cluster of 5 integers). Given all that, LabVIEW has some code that says, "I assume that type propagation has done its job and is only asking me to generate valid copy procs. So if I am asked to copy X to Y, I will remove all the 1-element shells from X and all the 1-element shells from Y, and then I will check to see if I have an existing copy proc." Nowhere in LabVIEW will we ever allow you to wire a 1-element cluster of an int32 directly to an int32. So the generator code never gets that case. In fact, the only time that we allow a 1-element cluster of X to coerce directly to X is... variant. The bug was that we were asking for a copy proc for this coercion, and the code was saying, "Oh, I have one of those already... just re-use copy-variant-to-variant." That will never crash, but it is also definitely not the right result! We had to add a check to handle variant special because variant can eat all the other types. So if the destination is variant, we have to be more precise about the copy proc re-use. I thought this was a neat corner case.

I'm happy to report that I can reproduce your bug in LV 2019. I'm even happier to report that I cannot reproduce your bug in LV 2020. We did some work on that window for the new release, including some much needed refactoring. Whatever we did seems to have cured this issue. So it'll be fixed soon. I'm glad you have a workaround.

Best bug description I've heard in a while. This doesn't sound like a LabVIEW issue, so I'm not going to escalate it, but drop me a personal message if your ongoing investigation leads you back to NI.

Edit time. These are right-click plugins that make edits to the VIs and then those edits get immediately undone. I don't know what you are referring to, but, no, these are block diagram plug-ins. See https://ni.com/lvmenus for details if you don't know about these useful tools.

Issue: Customers have noted that every once in a while, right-click operations implemented in G do not work, but when they try to reproduce the issue, everything works fine. Some users have written the issue off to "I must have clicked the wrong thing." But, no, it turns out that there's a rare race condition in the transaction logic for the right-click plugins. You can fix it by downloading one VI and replacing the version that ships with LabVIEW. Details here: https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Bug-Fix-for-ALL-Right-Click-Menu-Plug-Ins-LV2015-to-2019/ta-p/4016064 The bug? Don't close your refnum while you're still using the refnum. *head smack* And for those of you who tell me that refnum programming is easy, I'm adding this as evidence number N+1 that, "Sure, it's easy... easy to screw up." Long live dataflow! 🙂

A) LabVIEW will hold onto memory once allocated until the system says it is running low or until we have a large enough block to give back to the OS. Task Manager tells you nothing about how much memory LabVIEW is using, only how much it has available to use. B) Every wire can maintain an allocation of the data if the compiler determines that keeping the buffers inflated gives us the best performance. You can force a a subVI to release those allocations at the end of every execution by calling the Request Deallocation primitive, but I REALLY DO NOT recommend this. You’ll kill performance and possibly not save anything as people usually discover their app immediately re-requests the freed memory. Unless you are getting out of memory errors or are a real pro at data flow memory optimization, I recommend that you let LabVIEW do its job to manage memory. Beating LabVIEW and OS memory management generally requires bursty data flow with infrequent but predictable data spikes, where you can teach LabVIEW something about the spikes.

That’s a new one. Is this any hierarchy or a specific hierarchy?

Probably not. LabVIEW gets out of the way of the running front panel for you to have full control of your app, but there's never been a reason for us to do that for a block diagram. I doubt there's a way to achieve what you're trying to do in LV as it stands.

None that I could find. That kind of meta control of the LabVIEW IDE is not something we’ve ever focused on as a feature.

I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.

Took more time than it should have. But I'm glad we got there.

I looked at App:Tool Number... it's code has never been implemented (which is why it is still private, presumably). Someone put it in as a placeholder and then decided they didn't actually need it. Should have been backed out but wasn't. I don't know of any programmatic control over the autotool. I'm not saying it doesn't exist, but I don't know of any. Can you fire a shift+tab key at LabVIEW using OS calls before the framework starts running?

Twelve fixed connections? I would definitely look to channel wires for the in and out communications. No question about it. See "examples\Channels"

The entire Class Properties dialog is written in G. Anything you can set there you can set through scripting because that's the only way that the dialog works. It was how my team guaranteed that our scripting API was complete -- by never having another API exposed for the UI.

90% sure this is the issue fixed in one of the already-released 2019 patches or the 2019 SP1, but I've asked someone internal to NI to verify that.

That is better. I'll fix it.