drjdpowell

Sorry, I missed your post while on vacation. I actually don't do UML diagrams, so I'm not much help.

Issue 31

See the posts starting here. You have to use opkg to install sqlite on a Linux RT system.

I don't believe a this-VI ref has any problem; it is only a ref openned by name. Example, if I openned a reference to the string "MyVI.vi:6", then clone 6 of MyVI could leave memory without properly closing the ref.

That isn't a use case; it's just the next level up in your solution to whatever the use case is. What is the real-world use case? Who's your "User" and what are they trying to do?

I'm curious; what's the use case you have?

Please try the new 1.3.0 version in the LAVA-CR.

I know this is a OOP question, but there are other ways of addressing your problem that use "duck typing", such as Shaun's SCPI instruments. In my case, there would probably be an "actor" somewhere that responds to requests for current readings, and any actor that responds to those same messages is capable of substituting for it.

The dll uses a global variable, in such a way that it isn't safe to call function in parallel from multiple threads. Whatever that is called if "single threaded" is the wrong terminology.

No, I was trying to avoid blocking the UI thread, as some of the calls take a long time.

Thanks guys, I've been having intermittent lockup of dll. This dll is not safe to call from more than one thread at a time, and I had put in protection to prevent that, but I noticed the lockup occurred in two different LabVIEW instances at the same time. My protection, unfortunately, is confined to a single instance of LabVIEW, and thus couldn't stop this.

Question: if I have VIs running under two different projects (thus separate "instances" of LabVIEW) and both VIs are calling into the same dll, is a separate copy of the dll loaded in each instance? Or is there only one copy of the dll?

FYI, the DEV template is designed to be able to handle simple Events very quickly and easily, just like a more simpler Event-Structure loop. The follow-on actions output from the Event Structure is set to "use default if unwired", and the default action is just the error handler (and message reply). The "Next Action" and "Reply" subVIs that must execute are performance optimised to add negligible overhead in the default case of no actions and no message to reply to.

Can I encourage you have another look at the DEV template? You seem to have taken the DEV template and deleted the entire "Follow-on Action" handler, and are now trying to reinvent some of the very features you just deleted. At the very least, don't delete the error-handling case which already makes a Notification of any error. Have you seen the Youtube instructional videos on Messenger Library? The DEV template looks complicated, but is designed to support both high-performance use, like a simple Event-structure (with error handling) and more complex use, like a JKI State Machine. Since even simply-running things often require complex initialisation operations, I would suggest that starting with a "simpler" structure will led to less simple real-world programs.

What JSON file are you using? You've just given me a VI that expects JSON, and a YAML file. I note that your YAML contains no arrays, yet your JSONpaths treat "Configuration" as an array.