Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 03/22/2020 in Posts

  1. 2 points
    I definitely saw somewhere discussions about this that were not LabVIEW 2020 related. The solution was to create(edit) some environment variable for the MKL library itself where some thread configurations were forced explicitedly rather than letting MKL detect the right configuration automatically. See this thread for some discussion of the problem and possible solutions. It seems to be related to latest AMD Ryzen CPUs with a specific SSE architecture. That it falls back to trying to load from the penguin path is however rather strange. Generally these paths only exist in the executable as debug messages related to the source module the specific code was compiled from.
  2. 1 point
    I might be wrong, but I've never seen a LabVIEW built-in and exported function like nextafter or nexttowards in extcode.h or inside any Managers. But there's a WinAPI implementation according to MSDN: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/nextafter-functions?redirectedfrom=MSDN&view=vs-2019 So you might try to use those func's from msvcrt.dll by the means of CLFNs. Untitled 1.vi Hope, it helps somehow. Oh, and by the way, for Linux you could use libm.so and libSystem.dylib for macOS to call the mentioned functions, if you're not on Windows.
  3. 1 point
    Far from perfect, but what I have at the moment, is on Mouse Move, Mouse Down, or Mouse Wheel event (with the limit to 1 just like you), read the Top Left Visible Cell. This gives the Tag and Column number. Using a second property node, write the Active Item Tag, and Active Column Number to what was just read. And then read the Active Cell Position Left. I then use a feedback node to see if the Top Left tag, Column, or Cell Position Left has changed from the last time the event was fired. If it hasn't do nothing. If it has, then go do what it takes to either shift the current image up and down, or left and right. Left and right are property nodes on the controls to move them, but value can stay the same. As for shifting and image up and down, I use Norms low level code found here, which is pretty fast, but I did have to add a couple of op codes to it since his post. Alternatively you might be able to set the image origin to get the same effect but that uses a property node, as apposed to the value of the image control.
  4. 1 point
    You can change your terminals to dynamic dispatch at any time by choosing This Connection Is > Dynamic Dispatch Input/Output (Required) at the terminal block. You'll find that this option is only available for class inputs and outputs. To change your VI from static dispatch to dynamic dispatch, simply change both - input and output terminals - to dynamic dispatch.
  5. 1 point
    Here is a KB article regarding the differences between controls and indicators, local variables and property nodes: Control/Indicator, Local Variable, and Value Property Node Differences There is also an article that explains the different threads in LabVIEW and what they are used for: How Many Threads Does LabVIEW Allocate?
  6. 1 point
    It works for me just fine on latest versions of Chrome, Firefox and Edge. Stupid question: have you tried clearing cookies and cache? On a side-note:
  7. 1 point
    The main difference between LabVIEW and a C compiled file is that the compiled code of each VI is contained in that VI and then the LabVIEW Runtime links together these code junks when it loads the VIs. In C the code junks are per C source file, put into object files, and all those object files are then linked together when building the final LIB, DLL or EXE. Such an executable image still has relocation tables that the loader will have to adjust when the code is loaded into a different memory address than what its prefered memory address was defined to be at link time. But that is a pretty simple step. The LabVIEW runtime linker has to do a bit more of work, that the linker part of the C compiler has mostly already done. For the rest the LabVIEW execution of code is much more like a C compiled executable than any Virtual Machine language like Java or .Net's IL bytecode, as the compiled code in the VIs is fully native machine code. Also the bytecode is by nature address independent defined while machine code while possible to use location independent addresses, usually has some absolute addresses in there. It's very easy to jump to conclusions from looking at a bit of assembly code in the LabVIEW runtime engine but that does not usually mean that those conclusions are correct. In this case the code junks in each VI are real compiled machine code directly targetted for the CPU. In the past this was done through a proprietary compiler engine that created in several stages the final machine code. It already included the seperation where the diagram was first translated into a directed graph that then was optimized in several steps and the final result was then put through a target specific compiler stage that created the actual machine code. This was however done in such a way that it wasn't to easy to switch the target specific compiler stage on the fly initially so that cross compiling wasn't very easy to add when they developed the Real-Time addition to LabVIEW. They eventually improved that with an unified API to the compiler stages so that they could be switched on the fly to allow cross compilation for the real-time targets which eventually appeared in LabVIEW 7. LabVIEW 2009 finally introduced the DFIR (Dataflow Intermediate Representation) by formalizing the directed graph representation further so that more optimizations could be performed on it and it could eventually be used for LabVIEW 2010 as an input to the LLVM (Low-Level Virtual Machine) compiler infrastructure. While this would theoreticaly allow to leave the code in an intermediate language form that only is evaluated on the actual target at runtime, this is not what NI choose to do in LabVIEW for several reason. The LLVM creates fully compiled machine code for the target which is then stored (in the VI for a build executable or if code seperation is not enabled, otherwise in the compile cache). When you load a VI hierarchy into memory all the code junks for each VI are loaded into memory and based on linker information created at compile time and also stored in the VI, the linker in the LabVIEW runtime makes several modifications to the code junk to make it executable at the location it is loaded and calling into the correct other code junks that each VI consists of. This is indeed a bit more than what the PE loader in Windows needs to do when loading an EXE or DLL, but it isn't really very much different. The only real difference is that the linking of the COFF object modules into one bigger image has already been done by the C compiler when compiling the executable image and that LabVIEW isn't really using COFF or OMF to store its executables as it does all the loading and linking of the compiled code itself and doesn't need to rely on an OS specific binary image loader.
  8. 1 point
    I don't know which debugging technique you are employing, but if it's at edit time, you could temporarily change the scope of that method to be public. It's not a silver bullet, but works in a crunch, Now, if it's at runtime, I don't think there is any way apart from writing extra code into your class.
  9. 1 point
    Oops, looks like I missed when this feature went in. As AristosQueue mentioned in a reply to your Idea Exchange post, you can use the Dependencies > Missing Dependency Names and Dependencies > Missing Dependency Paths properties of the GObject class in LabVIEW 2015 and later. Can you verify that these properties give you want you need, and I'll close out the Idea Exchange post as Already Implemented?
  10. 1 point
    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.
  11. 1 point
    @The Q My library is not complete by any means, but what works really works... I've followed a TDD approach. So far I've covered only 79 requirements out of 141, and I haven't started any branches to support MQTT 5.0 yet... So it covers the basic needs such as shown in the presentation you're referring to, but nothing fancy like QoS 1 and 2 and the likes. (or TLS for that matter). If you want something more complete, I'd check Wireflow's implementation first. Now, I'd really like to get other folks to contribute to my Open Source Project. It would give me a moral boost to continue pushing it further. In the meantime, thanks for the advertisement!!!
  12. 1 point
    To all the warriors out there a heads up if your computer is suddenly running at 100% CPU. In the Task Manager, the Task Manager process will gobble up any CPU available. I swore it was a virus. A 3rd party tech support knew about this. Turns out a camera did not shut down correctly. To avoid Windows willy-nilly starting a process it likes that will screw up tasks such as frame grabbing response this Windows setting is used. Use PowerShell & run the following: "C:\Program Files\Point Gey Research\FlyCap2 Viewer\bin64\PGRIdleStateFix.exe enable"
  13. 1 point
    Locally, SQLite. Remotely, MySQL/MariaDB.


×
×
  • Create New...

Important Information

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