Mads

There is no change when it comes to Real-Time support now with 5.0.4 right? Still need to stick to 4.2 to use it on RIO-targets?

I agree, with the former😉 It is time to pause the planning to redecorate the kitchen when there is a fire in the living room (no matter how fire retardent the new paint is going to be).

Here is one quick draft of a VI for 2D searches. You might also save it as a VIM to use it on other types of 2D arrays... Search 2D Array.vi

One important thing to note is that if the application was built with the "Pass all command line arguments to application" key checked the OS Open Document event is never triggered 🙁 (come to think of it this might be why it has not worked as expected in the past 🤔). This might be a show stopper in cases where you *sometimes* want to be able to launch the app with additional/other arguments, e.g. to trigger some special behaviour. We do that to allow system administrators to disable some features in the application depending on the user's access, or point the application to an alternative configuration e.g..

Yes, it does work 🙌 When that tip first got out way back it did not seem to do the job properly, but it does now, in LabVIEW 2022 at least. I could not get the filter-version of the event to give me anything for some reason, but the regular does and it picks up opening multiple files together. (Looking at the issue again earlier I noticed VIPM e.g. still uses the helper app (VIPM File Handler.exe), but perhaps that is just a legacy / if it ain't broke, don't fix it thing. This is "supersecretstuff" too though, so trusting that it will continue to work is another issue.)

Command line arguments is fine for the initial launch, but the helper app is used to also pick up double-clicks on associated files when the applictaion is already running.

Oh, I knew. I just like to poke dormant threads (keeps the context instead of duplicating it into a new one) until their issue is resolved. Only then can they die, and live on forever in the cloud😉

The "LVShellOpen"-helper executable seems to be the de-facto solution for this, but it seems everyone builds their own. Or has someone made a template for this and published it? Seems like a good candiate for a VIPM-package 🙂 (The downside might be that NI then never bothers making a more integrated solution, but then a again such basic features has not been on the roadmap for a very long time🤦‍♂️...)

Did you figure out this crash @smarlow?

Here is a good thread that covers various related scenarios: https://forums.ni.com/t5/LabVIEW/why-open-new-clone/td-p/2976973 Regarding the queue; if it is not in use anywhere (regular dequeue e.g.) so that the close can be detected there? If it is polled in the timeout you probably do not need to run that timeout every 10ms as that will put a high load on the CPU. For users to perceive things as "real-time"/instant anything below 300 ms or so will do. You can also wire the error wire directly to the stop terminal unless you have other cases there that generate a boolean, then using the status alone is more practical..

Not having looked at the details of the code you have, here is a quick general comment: If the dynamically called error monitor needs to close if the main VI closes I would not code that by having it monitor the boolean of the main (reading values using property nodes is not optimal in any case, globally or locally), but rather destroy the queue in main when it closes and then have the dynamic VI react to the queue erroring out, or use a dedicated user event, notifier or channel wire to message this (bidirectionally if needed). (There are countless ways to do this, all with their pros and cons. A named "System" notifier e.g. that is used for any part of the application that needs to know when to gracefully shut down, reload setting etc. is *one* simple solution that allows anyone to monitor it without polling or having anything pre-wired (just mentioning one such solution here is opening up for a bunch of protests from people preferring other methods due to cons with this particular method, but anyway...))

Any code can contain errors. If you script the code you are just adding another layer where you can have errors (the script itself, in addition to the code it generates). When the script has created the code you still have to test the generated code to see if it works correctly. If you write it manually and test it (easier than testing scripts as you can test its intermediate steps directly as you progress) you can use that code for all ports, not just for one. Having to repeatedly create complex but similar code from scratch could justify doing it with scripting to reduce the risk of human errors, but here you can still handle it by having the code cover all scenarios and/or with code reuse . And much of the code has been written and tested for you already (examples) so all you need to do is add whatever extra functionality you need and test those changes. Have you tried solving this the easy way by relying on the RT OS and VISA support already, but observed that it does not meet the your reliability requirements? Or have you just assumed that it will not and are optimizing it prematurely, making the path to a working solution unnecessarily hard and complex?

Yes, I never said they did, but I did wonder why you need to script their creation.

The top one, the SAC, will run even if the root loop is busy, AND allows you to set the inputs. This function was not available in LabVIEW until version 2011 or so. It is especially useful if you need your application to spawn VI clones to handle various events (TCP session handlers for example) regardless of what the user is doing in the GUI... The two bottom ones will be blocked if the root loop is busy, e.g. if the user happens to be viewing the time picker of a time control it will halt until the user closes the time picker. Before the SAC was introduced in LabVIEW you had to use the run method (bottom one) if you wanted to avoid having to wait for the dynamically launched VI to complete (it has the Wait until done input). The Call by reference node on the other hand had the advantage over the run method of offering control inputs to the call whereas the run method would require you to use set control invoke nodes for that. Here is a long thread about the root loop issue from before the SAC was introduced: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idi-p/1417794?search-action-id=359039184054&search-result-uid=1417794