Francois Normandin

I assumed Messenger did this too, although I don't use it. 🙂 In SMO, it's a settable parameter by the user based on their needs. The SMO process itself actually should abort in a few milliseconds, so it is heavily dependent on the process overrides. (edit for clarity) The STOP call is a last resort in case the "autoshutdown" message does not work. Even if enqueued at the front, when the actor loop is locked because a "do" is performing a blocking action, stop will kill the thread. Also, Stop will effectively handle a parallel loop that is running concurrently to the actor message handling loop and does not implement correctly the shutdown messages. I daresay it should never happen in production code. The onProcessKill override is provided to have a way to log this event when it occurs. If the developer killed the caller in development mode, that's fine and can be ignored. If it happens in production code, it should be a concern.

You might want to inspect JKI SMO's way to handle this. The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. Note that you should use such a mechanism only if you always want your asynch process to get killed in case of a caller going out of memory. (This should be an ultimate way to exit, not a normal way...) SMO process still tries to abort before it ultimately kills the thread. (This is a screenshot from SMO:Process.vi)

1. Nowadays, Git 100%. 2. Love it. 3. I forced it on my team, but even for my hobby coding, I use SCC. Those closer to retirement are having a hard time. For the younger folks fresh out of school, they'd be surprised if we didn't use Git. I wouldn't bet that all of them know what SVN means. 4. Pros: Large support community online. When stuck, I just spell it out in the search engine and I find a post on stackoverflow that solves my problem It allows enforcement of a workflow that achieves modularity by design, through submodules. Easy to deploy a repo through a usb stick for offline instruments, and to merge offline changes back to server No one can reserve a file and accidentally prevent others to work Cons: No LV integration for visualizing changes 5. SCC never screws up, the developer or the client app does. The app client I use (SourceTree) has a tendency to show "detached heads" that magically disappear when I close the app and open it back again. Detached heads are very confusing and every time I see one, I'm extra careful not to lose any work done. They never occur in a simple repos: only when dealing with submodules. That's a buggy behavior of the app, not a failure of SCC itself.

Whenever it's been used in a project that I knew would persist more than for a simple demo, I've always wrapped the IMAQ API into an image class that handles the name generation with GUIDs to avoid collisions. Sometimes I'll add a singleton registry to keep track of references, but my IMAQ-flavored apps have generally been of low complexity, so I typically maintain a list of objects in the process' private data. When I need to leak the images across multiple processes, it is generally a delegation pattern, and the caller is still responsible for the reference's lifetime.

Here's a snippet you can use if you want an unbound cluster size that preserves element names. (Note that the "Create Cluster" method is found in vi.lib/Utility/GetType.llb) It is much slower than your direct cast, but in the cases where you absolutely want to keep the element names, it might be worth the hit. Here are some quick comparison benchmarks on my machine: - 256 named elements => 7ms (compared to ~microseconds for the fixed-sized method) - 1000 named elements => 23ms - 10000 named elements => 135ms PS. This is a method found in DataManipulation package on VIPM. Since it is licensed under 0-BSD, feel free to extract at will (no attribution needed).

@pajaramillo1 You can open VIs from previous years at any time. LabVIEW is going to compile it for your version and once you save them, you will not be able to open them in a previous version unless you back save them. Download the file you need from this thread and it will work in LV2015.

As a publisher of packages myself, I really like the interface and how easy it is to have a package of mine find its way to the Community repository. It was always nice to have the LAVAG code repository (same info, direct ungated access), but having the packages accessible to anyone just by virtue of refreshing the VIPM package list is really a nice feature. @Antoine Chalons, sure I'll move the Controls Addon to VIPM Community... Already put in the request!

This control seems to have been set as a private member of the library, which means you cannot use it outside of the library itself. If this controlID is available on a public method, it should also be made public. Two things can happen: 1- The library is repackaged with this control set to be public 2- Disconnect the type definition. (Right-click on Controller ID and choose "Disconnect from type definition". Solution 2 is your best choice right now, unless someone ants to repackage the library and expose the control publicly

fixed and pre-released as 1.0.2 build. pushed to default branch https://github.com/LabVIEW-Open-Source/LV-MQTT-Broker/releases/tag/1.0.2

@Neil Pate I thought I had fixed this bug. It dates from my NIWeek 2019 demo when I made a last minute change from "Destroy" public method to "onDestroy" protected method. You see what happens when you do a TDD project and you skip the tests "JUST ONCE" because you're in a hurry and the boss wants this code deployed ASAP??? Hahaha! I'll do a fix this weekend... Edit: Was fixed in the Develop branch... I'll test, bring to master branch, build and release a new package.

I had not realized either it was so simple to add TLS. I didn't plan to upgrade my broker to 2020, but multiplatform TLS is tempting. (shameless plug for my project: https://github.com/LabVIEW-Open-Source/LV-MQTT-Broker)

If it's a commercial project and you're on a deadline, you can check Wireflow's MQTT client. It ain't free, but supports TLS. http://sine.ni.com/nips/cds/view/p/lang/fr/nid/213501

I usually run my code against test.mosquitto.org

Just a thought. Have you verified which version of MQTT is supported on Azure? MQTT 5 is most recent, and although MQTT 3.1 is normally supported by brokers, Azure IoT hub is not a fully-compatible MQTT broker. There might be restrictions on QoS, will messages or even TCP vs Web Sockets...

As someone that sometimes publishes open source code, I generally choose the most permissive license I can because I basically only want the code to be shared and I don't mind the rest. I had started using the Unlicense for all my work but realized that it's not OSI-approved (and apparently some countries don't recognize Public Domain as a thing), so I fell back on Zero-clause BSD. https://opensource.org/licenses/0BSD You know, if someone wants to use my name to advertise their stuff, I am not sure I would mind. I guess if they misuse my name in some way, I could sue them for that anyhow. But it's not like they'd build a rocket launcher and say that my code powers it, therefore it's bound to work correctly, right? As for the copyright notice on every front panel, block diagram or VI descriptions: please don't do that. 🙂 It just multiplies by 2 the time it takes to compile your packages. Useless, unproductive, annoying and of no legal value. (IMO anyway)

I, too, have been uneasy about this for a long time, but the convenience of the mechanism is such that I generally hope that the user is going to use it properly. There are two alternatives that I know of: - Use the mediator pattern and make sure the user event is unique for your event consumer (if the consumer closes the reference, the mediator can just assume it doesn't want to be notified again and can destroy the thread) - Use Actor Framework or another message-based framework that does not expose the queue/event/notifier publicly.

How about this for "Array to Cluster"? It works for any array size. I have not tested whether it is faster or slower than the "array to fixed-size cluster" method, but it is cleaner than having 256 cases to handle all possible clustersaurus configurations. The "TD_Create Cluster" type descriptor method is a gem you can find at <vi.lib>\Utility\GetType.llb\TD_Create Cluster.vi // Note: you can ignore the error on the unflatten node, an empty array input will return "void" as an output. Oh, and it's faster than OpenG...

https://www.ni.com/en-ca/events/niweek.html?cid=Twitter-a243q000004k8RqAAI-Awareness-sf120637664&sf120637664=1 https://www.linkedin.com/posts/national-instruments_niweek-activity-6656176258671525888-78H6

I recently did a code review with @Jim Kring about upcoming Caraya 1.0 (yeah, I know, I'm using the opportunity to plug Caraya... shame on me), and when I showed him this block diagram, his eyes immediately caught the top comment I placed on the block diagram. It took him less than two seconds to say something like: "You have to put that on the Idea Exchange." (Jim, let me know if I'm misquoting you) Indeed, the Block Diagram... erm... the Mother of All Diagrams... does not have a Subdiagram label property. I say this is a grave injustice. So anyhow, I wanted to share the paternity of this idea because without his enthusiasm, it would not be there: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Subdiagram-label-for-Block-Diagrams-too/idi-p/4033465 If you like it, please vote!

I don't think it differs from a traditional event-based architecture if one overwrites the Actor Core and adds a parallel loop, which is the equivalent of Gregory's problem statement. The child's Actor Core parallel loop will still need to interact with the parent, through a subscription (user event or message-based). I agree that Actor model solves this problem (AF or event-based): the way to avoid this registration duplication in each child is to refactor the application's architecture where the child does not provide a second parallel loop, but only implements a set of messages that extends the parent. I daresay that a child class that extends its parent, both by adding a parallel loop and by extending its API, is in conflict of the Single Responsibility Principle in that it has two reasons to change. If a second loop is needed, it could probably be handled through composition instead of inheritance.

When I write the file manually in a text editor and I open it, I get "Démarrer", but if I specifically change the encoding of the file to be "ISO 8859-15", I can read it correctly in LabVIEW. Alternatively, any file saved by LabVIEW'S Write to File method can be read correctly as well. I don't know if it works for other languages. My OS is french, so at least that's working for me.

There are graph properties which you can use. Here's an example: (Attached VI saved in LV 2013) LImitCursorRange.vi

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.

First thing, you need to add an INI token to LabVIEW.ini file, so you can display Unicode in LabVIEW. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJRNSA2&l=en-CA That allows to at least display the characters when copied on the front panel or block diagram (instead of showing up as a "?"). However it does not work with the caption text unless your OS environment supports the language pack. As you can see below, my OS has French and English installed, but not Chinese or Cyrillic characters. I can display the unicodes when I paste directly from a source, so you can try it on a virtual machine with the proper regional settings, and that should work. ** Edit: there is probably another step missing, because I can't get it to show up on my VM with a Russian keyboard installed... ** Edit #2: OK, it works. Turns out that the cyrillic character I had copied from google was not part of the Russian keyboard. I have no way to tell :-). But now it works with another character generated from the russian keyboard itself: "ф".

It is not a bug. It should break for any unsigned integers because that's how the "negate" method works.