Jump to content

Aristos Queue

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Aristos Queue

  1. Does anyone have a picture showing how, given a VI, I can get ... ... the size of the monitor hosting that VI's panel... ... minus the taskbar size (if any) on that monitor... ... in a platform (OS) independent manner? I had a clean-but-annoying way to do this until I discovered that Windows10 has a mode that lets the task bar be replicated onto different monitors (and, worse, those taskbars aren't necessarily the same size). The only trick I can come up with is to maximize the panel momentarily and grab the panel size at that moment, but that creates flicker in the UI. Yes, I am aware of these two properties: They do not suffice. The first one gives all the monitor sizes without accounting for taskbar. The second one only reports taskbar on primary monitor. If I could be sure the taskbar was only ever on the primary monitor, I can figure it out from this info, but discovering taskbars on multiple monitors was an option throws a wrench in that plan.
  2. Nifty trick! I'm impressed with the ingenuity. But two minor caveats... Warning 1: This XControl allows local variables and Value property nodes. LabVIEW prevents the built-in latching Boolean controls from having either a local variable of the latched Boolean (compile time error) or a Value property node (run time error). Those things would mess with latching, and will interfere with this code executing correctly. You should not use either of those things with a latching XControl. Warning 2: This XControl uses an unpublished private method of scripting that is known to have problems with thread synchronization. It was created to handle some very specific editor operations. It is not a safe thing to use generally, which is why it has never been made public, because of inplaceness optimizations that make multiple wires share the same memory. I think the use in this case is safe because there isn't any optimization that I know of that will make LabVIEW avoid the data copy if a downstream node modifies the value. For example: The above image shows the Buffer Allocation dots... and we can see that the Not copies the Bool, even when debugging is turned off. I will ask my team if there are any scenarios where inplaceness will elide that dot. I don't think there can be (because So it seems to be ok here, but I would not advise freely using that method in code generally.
  3. > If a second loop is needed, it could probably be handled through composition instead of inheritance. Agree in general. Composition can get complicated if that second loop needs to be a Timed Loop -- if the timed loop's operation sometimes needs to be reconfigured while it is running, messages may be needed that extend Actor's API, and avoiding that is just more complicated than I think is worth doing. It may be a technical conflict of SRP, but practicality does temper the principles sometimes. There may be additional cases.
  4. Actors in Actor Framework inherit from each other, and if the parent defines a message to be handled, then the children can handle that message. Put another way -- I built an entire framework to handle that exact problem. It doesn't use the Event Structure. The only solution I came up with that I liked that used the Event Structure was an entirely new conception of inheritance, a new fundamental type of VI, and a new editor. It not only solves the problem of event inheritance but also front panel inheritance. I have it all mocked up in PowerPoint to build someday (when LV NXG is mature enough).
  5. This is not really true. I mean, it's kind of true, insofar as LV executes assembly level instructions, not byte code. But it is also misleading. LabVIEW doesn't ever get to a deep call stack. Suppose you have one program where Alpha VI calls Beta VI calls Gamma VI calls Delta VI and a second program which is just Omega VI. Now you run both and record the deepest call stack that any thread other than the UI thread ever achieves. What you'll find is that both programs have the same maximum stack depth. That's because all VIs are compiled into separate "chunks" of code. When a VI starts running, the address of any chunk that doesn't need upstream inputs is put into the execution queue. Then the execution threads start dequeuing and running each chunk. When a thread finishes a chunk, part of that execution will decrement the "fire count" of downstream chunks. When one of those downstream chunk's fire count hits zero, it gets enqueued. The call stack is never deeper than is needed to do "dequeue, call the dequeued address"... about depth 10 (there's some start up functions at the entry point of every exec thread).
  6. A programming language exists in any Turing complete environment. Magic:The Gathering has now published enough cards to become Turing complete. You can watch such a computer be executed by a well-formed program. People might not like programming in any given language. That's fine -- every language has its tradeoffs, and the ones we've chosen for G might not be a given person's cup of tea. But to claim G isn't a language is factually false. G has the facility to express all known models of computation. QED.
  7. This might vary by operating system, but I think you're correct. I have only once had reason to drill that deep into the draw manager layer of LabVIEW's C++ code. But the whole point of deferring updates is to avoid flicker, so it would make sense that LV would aggregate into a single rectangle and render that as a single block... if it tries to do all the small rectangles, that's probably (my educated guess) the same flicker that would've occurred if defer never happened.
  8. A call to a static dispatch VI will always invoke that exact VI. A call to a dynamic dispatch VI may invoke that VI or any VI of the same name of a descendant class. Exactly which VI will be called is decided at call time based on the type of the object that is on the wire going to the dynamic dispatch input terminal. A dynamic dispatch VI is equivalent to a virtual function in C++, C#, or JAVA (and other text languages).
  9. For anyone else interested in how far this bug goes, I got this from one of my coworkers: From my research it affects all processors based on the Zen 2 architecture (AMD processors that started being released in July of last year). AMD claimed that they dropped support in Zen 1 for fma4 instruction set, and the illegal instruction causing the crash is part of that set. The first series Ryzen processors sound like they may still work, but I didn't have access to any to verify one way or the other.
  10. The MKL problem is in the wild? I thought that was something that was only affecting LV 2020 (now in beta) because we were updating to the latest MKL. The bug isn't on my team's plate... I just sit near the people who are handwringing a lot about it. If that's in the wild affecting already shipping MKL versions, then, yeah, that could be it. I still don't know how the node is rolling back to its last known good resolve path... I can't find that path stored anywhere... but if we assume it is binary encoded *somewhere* in the node's saved attributes, then this makes plausible sense. Workaround is to a) get a new CPU or b) wait until LV issues a new version where we do whatever we are doing to avoid calling certain CPU instructions (I'm unclear what the planned solution looks like).
  11. 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?
  12. Is this desktop LV or target LV? What is the actual path on disk to that Mean.vi?
  13. 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.
  14. @NeilPate : please run the attached VI on your misbehaving Mean.vi and tell me what path it shows. Read path to analysis lib.vi
  15. 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.
  16. 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
  17. 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
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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! 🙂
  24. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.