Jump to content


Popular Content

Showing content with the highest reputation since 01/25/2020 in all areas

  1. 4 points
    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.
  2. 4 points
    I'm working on a personal project (more information will be shared about this later) that needs Message Queue Telemetry Transport (MQTT). While searching for LabVIEW libraries for MQTT I found 1 on VIPM, 2 in the NI Forums, and 1 through Goggle on GitHub, as follows: WireQueue-MQTT Driver for LabVIEW by WireFlow AB (this one costs $550) MQTT Client API in native LabVIEW by Peter - daq.io (also on GitHub as LVMQTT) MQTT-LabVIEW by Michal Radziwon Quaxo MQTT LabVIEW by Stefan May This is not unusual for just about anything you might be looking for. In fact searching on GitHub there are 13 results for LabVIEW+MQTT. What was weird is that two of them were almost completely the same, yet neither attribute the other. I don't know which came first. I ended up forking from one of them but I guess I'll attribute both to be safe if I end up using it. However, talking about code confidence, I just found this one: LV-MQTT-Broker by @Francois Normandin. I know Francois, he is a LabVIEW Champion. He has included unit tests. It has full documentation as well as an NIWeek presentation by him and Sarah Zalusky, both of whom are Certified LabVIEW Architects (CLAs). From GitHub I can see he has been actively contributing to it and its open source (which most of them were). Honestly, I wish I had found this one first. Just some words for thought...
  3. 3 points
    [Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.
  4. 2 points
    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.
  5. 2 points
    It is not a bug. It should break for any unsigned integers because that's how the "negate" method works.
  6. 2 points
    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.
  7. 2 points
    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! 🙂
  8. 2 points
    Did you enable foreign key constraints? You need to set PRAGMA foreign_keys = ON Otherwise foreign key constrains are ignored. https://www.sqlite.org/pragma.html#pr>agma_foreign_keys
  9. 2 points
    Here's a review of LabVIEW 5.0 from Macworld magazine, July 1998. "It's gigantic---a typical installation might involve 200MB of support files and programs"
  10. 2 points
    @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!!!
  11. 2 points
    I'm so glad malleable VIs and the Type Specialization Structure exist now. Well done NI!
  12. 1 point
    View File SQLite Library Introductory video now available on YouTube: Intro to SQLite in LabVIEW SQLite3 is a very light-weight, server-less, database-in-a-file library. See www.SQLite.org. This package is a wrapper of the SQLite3 C library and follows it closely. There are basically two use modes: (1) calling "Execute SQL" on a Connection to run SQL scripts (and optionally return 2D arrays of strings from an SQL statement that returns results); and (2) "Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to "Bind" parameters to the statement, and get the column data back in the desired datatype. The "Bind" and "Get Column" VIs are set as properties of the "SQL Statement" object, for convenience in working with large numbers of them. See the original conversation on this here. Now hosted on the NI LabVIEW Tools Network. ***Requires VIPM 2017 or later for install.*** Submitter drjdpowell Submitted 06/19/2012 Category Database & File IO LabVIEW Version 2011 License Type BSD (Most common)  
  13. 1 point
    I have always done the second method, and just accepted the extra overhead of one extra message pass. Beware of premature optimization. It is generally rare for me to want to just forward a message like this without the forwarding actor needing to change or react to the message in some way. An alternate design is to accept that you don't have an actor-subactor relationship, but that your subactor should really be a helper loop of the actor. A dedicated helper loop can share references no problem. Your "actors sharing references" is a potentially suboptimal mix of "actors are highly independent but follow restrictive rules" and "helper loops have no restrictions but are completely coupled to their owner"
  14. 1 point
    Thank you once again Dr. Powell for sharing this powerful approach. I can see it being used in "Metronome" actor (e.g. Set Period). And I already started to use it in my projects. If you don't mind I would like to ask you another question: I have an actor (A) that launches a sub-actor (B) to delegate some tasks to it. When sub-actor (B) publishes an event, actor (A) gets a message. However I would like to publish that message beyond actor (A). So that actors subscribed to actor (A) would also receive events from sub-actor (B). Currently my approach is to send Observer Registry of actor (A) to sub-actor (B) during initialisation. Then sub-actor (B) publishes its events into Observer Registry of actor (A) directly. Another idea was to republish the event from actor (A) when it gets the message from sub-actor (B). Neither of these methods feel right to me. The first one shares internal reference of the actor (A). The second method is not as efficient (receives, then sends again). How would you approach this?
  15. 1 point
    Do want to be part of the inaugural GDevCon N.A. in Boulder, Co. this July? We need a few more presentations to fill up our schedule so submit your idea now before we run out space. https://gdevconna.org/deadline-extended-to-feb-29th/
  16. 1 point
    How about the Arduino™ Compatible Compiler for LabVIEW
  17. 1 point
    He's talking about edit-time panel and diagram menus and run-time diagram menus that are implemented as right-click plugins. This bug fix does not affect right-clicks in the project window.
  18. 1 point
    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.
  19. 1 point
    You can find out more and sign up here: https://forums.jki.net/topic/3082-vipm-2020-beta-sign-up-is-now-open/ here’s a teaser (below). Lots more exciting stuff to come...
  20. 1 point
    I've now incorporated flarn's code into a tool that will set splitter size. See here: https://forums.ni.com/t5/Quick-Drop-Enthusiasts/Pane-Relief/gpm-p/4014004/highlight/true#M1130 Just search "PaneRelief" on VIPM to download!
  21. 1 point
    Hello LAVA-ers! If you haven't heard already, the CLA Summit 2020 will take place in Budapest on March 24th to March 26th. You can read more and register here: https://events.ni.com/profile/web/index.cfm?PKwebID=0x94716776a&varPage=home . This year we have an Open Source Session dedicated to the people who want to show their projects and encourage the collaboration. The rules are simple: Contact either me (through private message or email: piotr.demski@sparkflow.pl), Thomas McQuillan (who's also wrote about it on linkedin: https://www.linkedin.com/feed/update/urn:li:activity:6628225386339803137/ ) or Anastasiia Vasylieva (anastasiia.vasylieva@ni.com) You'll prepare three minutes presentation to showcase your project (we'll provide you with two-slides presentation template to fill most important info) (optional) We also have a poster session, so you can prepare an A1 sized poster to display at the Summit (please also contact us if you're interested) I know that not everyone here is CLA and is able to come to the Summit, but I encourage you to submit your project anyway. We'll compile all the presentations into one document and we'll distribute it in the LabVIEW community. So it's also a good way to promote your project!
  22. 1 point
    I have an app that uses a watchdog built into the motherboard. Failure to tickle the watchdog will trigger a full reboot, with the app automatically restarting and continuing without human intervention. In addition, failure to get data will also trigger restart as a recovery strategy. Still failed at 55 days due to an issue that prevented a Modbus Client to connect and actual get the data from the app. That issue would have been cleared up with an automatic reboot, but detection of that was not considered.
  23. 1 point
    I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.
  24. 1 point
    View File JSONtext Package for working with JSON. Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster). Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types. Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly. JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest. Requires LabVIEW 2017 and install by VIPM 2017 or later. Original conversation about JSONtext. Now on the LabVIEW Tools Network. Copyright 2017 JDP Science Limited Submitter drjdpowell Submitted 08/02/2017 Category General LabVIEW Version 2017 License Type BSD (Most common)  
  25. 1 point
    Took more time than it should have. But I'm glad we got there.
  26. 1 point
    I don't tend to use them unless they have meaning beyond the message itself (ie. they are a natural grouping of data, rather than something that just exists for the message). Most of my messages contain only one piece of data, so no typedef needed (unless that data is naturally a typedef). Also, it is possible to go more than just a typedef: have an API of subVIs to send and receive the messages in a common library. This can be a lot more powerful than just a typedef. An example would be having any message starting with "Config:..." being passed to a Config subVI, with multiple possible messages being handled by that subVI ("Config: Get as JSON","Config: Set from JSON", etc.). Another option is to send an Object that has multiple methods that the receiving actor can use. I view a typedef as a poor cost-benefit trade-off, since you have the coupling issue without the maximum possible benefits.
  27. 1 point
    Unfortunately this contrasts with the current behaviour that null-->NaN for a floating-point number, rather than being the default number input. In standard JSON, the float values NaN, Infinity and -Infinity have to become null, and to convert them back to a default value doesn't make sense. We could add an option to "ignore null items" which would treat nulls as equivalent to that item not existing.
  28. 1 point
    A possibly better option is to replace your string/integer values with JSON strings, which is LabVIEW strings with <JSON> at the start of the name. So "<JSON>Comment" rather than "Comment". JSONtext will happily parse out the value into your cluster as JSON, then when you actually need your value you can convert it to string/integer, with appropriate handling if it is null or throws an error. This method, by the way, is also how to handle JSON that has variable structure.
  29. 1 point
    @Francois Normandin, I'm finishing another project now but I will be returning to this soon. If it doesn't do what I need yet, I'll work with you on it to accomplish more of the features.
  30. 1 point
    The behavior AQ mentioned is similar, but not quite the same. In the LabVIEW 2019 f2 patch, we addressed Bug 188376 (CAR 742093). That Bug resulted in a crash when probing class wires that included maps in the object's data. I've reproduced the behavior you're seeing in LabVIEW 2019 SP1. I filed Bug 966521 to get that on our radar. As a quick note, I did test LabVIEW 2019 and the behavior isn't there. If you need to debug, you can do so on a patched 2019 installation.
  31. 1 point
    How many tons of coax, cat5 or fiber have YOU buried inside a test fixture / station?
  32. 1 point
    Like Shaun's? https://lvs-tools.co.uk/software/mdi-toolkit-labview-library/
  33. 1 point
    Ok this is so random how I found this, but I was able to reproduce it. I'm hoping others on here can reproduce it as well. If this is a known issue then please link to the source for reference. I've attached code that reproduces it. But basically in order to reproduce it: Place a Map datatype in the private class data of the class. Make the Map datatype a typedef. lava.zip
  34. 1 point
  35. 1 point
    I assume you meant this video? There is this older video of Dr. T and Jeff K. introducing a LabVIEW Basics Interactive CD-ROM (~LabVIEW 4), but it's not as exciting as the LabVIEW 5 promo.
  36. 1 point
    You *can* use DETT on built applications, just enable VI server access and debugging in the build. Here is a description of it: http://digital.ni.com/public.nsf/allkb/A50A8BBFD737679186257D7700688757
  37. 1 point
    Everything works now, here's what I've learned: LabVIEW is using a list of trusted authorities from the file: "%ProgramFiles%National InstrumentsSharednicurlca-bundle.crt" If your Certificate Signing Authority is not in that list, you will receive Error 363507 - LabVIEW could not verify the authenticity of the server. In order to avoid this error, either find a new Certificate Signing Authority, or you can specify your own Trusted Certificate Authorities using ConfigSSL.vi (shown in the screenshot below). When you distribute your application, ensure to include this file with the distributable. When you download your certificate from your CA, through the management console you can probably also download the Root Certificate of the CA -- this is the file that you wire into CA certificate file of ConfigSSL.vi. (This file might even be included as a zipped certificate bundle when you download your cert.) This file will look like the following if opened in a text editor: -----BEGIN CERTIFICATE----- MIIFB...LinesAndLinesOfBase64....== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIED...LinesAndLinesOfBase64....== -----END CERTIFICATE-----
  38. 1 point
    You can set the INI variable and restart LabVIEW using two Invoke Nodes. You will have to confirm "Quit will abort all running VIs" and it should start back up with the correct setting. (LV 2012)
  39. 1 point
    Helped by a NI support Engineer I have achieved what I wanted to achive using the Lends Number of Rows coupled with the Legends plot minimum properties. If yuo are interested in see what we have done, look at the attached VI. Modifying the Lends Rows control you will see the effect. The legend will be resize properly (avoiding the exceeding plots). Try inserting as sample 10 --> 25 --> 12. Graph_Problem - Fixed.vi
  40. 1 point
    Set the following attributes of the string control: Key Focus = TRUE Text.Selection:Start = Desired Cursor Position Text.Selection:End = Desired Cursor Position

  • Create New...

Important Information

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