Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/31/2020 in all areas

  1. @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!!!
    2 points
  2. 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...
    1 point
  3. @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.
    1 point
  4. 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.
    1 point
  5. 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
    1 point
×
×
  • Create New...

Important Information

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