Aristos Queue

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.