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.

Different applications can have different config needs. In fact, a single app can have multiple different needs requiring different styles and thus different config files. So it is hard to give general advice other than "JSON is flexible and easy". Re your questions: 1) saving and loading files isn't complicated, so I've never seen value in a separate "config" actor. 2) I usually use just "LabVIEW Data", but see also this blog post. 3) I've done similar systems. Here configuring the system involves reading (from the config file) what actors are needed and launching them before sending them there config subJSON. This can involve dynamic loading of the actor class (from the lvclass name in the file). Your max of 96 messages second doesn't sound that much to me. Using a standard message will be simpler. But this is something you should test as soon as possible. It is ok to introduce something more complex if needed, but only if needed.

I know nothing about ARP, but why would this come instead of a UDP packet?

You can either use a transparent PNG (there is one in "<vi.lib>\JDP Science\Flatline Controls\Transparencies\Full Transparent.png") which, strangely, is not the same as colouring something transparent. But the best option, if you don't want the User to be able to click on those arrows, is just to make them very small and hide them behind the main body of the slider.

I investigated, and it is because you made the two incr/decr arrows transparent. I've had suspicions in the past that there is something buggy about colouring things transparent.

If you replace with an unmodified slider direct from Flatline does the problem come back?

BTW, the VIMs in JSONtext are all simple wrappers to make the API easier; you can use the Variant conversion functions available under the "more" menu to avoid all VIMs if needed.

That's inherited from the NI JSON function, which I used for fast array parsing. I may have to spend the effort to develop and alternate solution, or develope better guards for corner cases.. There are a lot of edge cases mapping LabVIEW's strict types to JSON.

Pretty Print is designed to keep small objects compact. Anything less than 40 characters. I think it's more readable, especially for arrays of small clusters.

Are you using 2018SP1f1? This sounds like the horrible compile bug present in 2018 before SP1f1 that tended to hit VIMs heavily (CAR 715018). The f1 patch fixed this.

You could consider a JSON header, followed by binary data. I strongly suspect the float representation in both languages is identical: IEEE standard.