drjdpowell

Does it? Closing isn’t the same as unloading. Is your VI reserved-for-execution? If it is, I don’t think closing the FP unloads it or resets anything.

If you executed it, then it must be reserved for running, so the “nasty transition†Neil mentions doesn’t apply. Yes. I put Close Front Panel before Insert VI (I ignore any error from the Close, thrown when it was already closed). You can close the reference. The subpanel doesn’t (I don’t think) ever close the reference itself.

I solve this issue a different way, by making my messages all "control-likeâ€: a label and a value. So I would have messages: “Set Loggingâ€, a boolean that is True or False “Set Play Stateâ€, a string (or possibly enum) with values "Play" "Pause" "Resume" or "Stop"

Attached is the demo project developed over the Actor to Actor communication and Controller-Model-View videos. LabVIEW 2015. Messenger Library Demo.zip

I tried having call-backs that called methods on a LVOOP object inside a DVR. It worked, except that occasionally two events happening at about the same time caused the UI to freeze, possibly due to some kind of lock-up involving the DVR and the UI thread in which the callbacks run. This was near impossible to debug, and I abandoned callbacks in favor of an asynchronous VI that handled events with an Event Structure (calling the same LVOOP object held in a shift register).

Your code was not attached, but I often use variants, dynamic registration of arrays of control references, and control labels that encode the message that needs to be sent, as illustrated in this old post. I also done similar things connecting multiple controls with Camera Attributes or DAQmx channels.

In the end I sidestepped the bug by turning off "Advanced>>Auto Adjust Scales†on all my graphs.

I was more responding to: "It is my understanding I have one of two choices at this point: A.. and B.." I gave an option C.

Are we actually disagreeing? Your pointing out a way for calling code, that explicitly knows what a "dog" is, to call subVIs that only deal in "animals". If the calling code has reason to explicitly be written for "dogs", then that's good. But if you want the calling code to be generic and work with any animal (what's that? an "animal-abstraction layer") you can still support special functions if you define the right methods. Writing code where, if you click on a dog, you get a button marked "bark", doesn't require that code to explicitly work with anything other than animals.

Another option is to push greater responsibility down into the specific classes and have the application-specific code continue to deal in parent-class methods. For example, your power supply with a special feature probably needs a way for the User to configure that feature and observe the results. The application code could call methods like “Has special features.viâ€, “Show Configuration window.viâ€, “Get text description of status.viâ€. If the power supply has special features then show a description of the status of those features and show a button that lets the User open the Configuration window (possibly in a subpanel).

Yes, inside the event case. Show your dialog only on events where the button goes True.

Re 1) The Event Structure has a Timeout, which you can set to zero if you want. Re 2a) Use a Case Structure to do things only on True. Re 2b) the “Value Changed†event is somewhat misnamed as it really is a “new value†event; there is no filtering out of where the new value is the same as the old value. The Event has the old value as well as new value so you could do this yourself, but a far better solution would be using a case structure and only trigger an event on True.

You can also treat the core Actor’s Front Panel as the “debug†UI, since it is easy to add a lot of indicators. Personally, I usually have a lot of actors that are MVC-in-one-actor for their own part of the application. So ‘temperature control’ actor probably has control/view of the SetPoint, PID and other parameters, and can be inserted into a subpanel in the main app. Then additional Views or Control can come from elsewhere (a summary screen of many temperature controllers, say) but these VC tend to deal with smaller subsets of “Model†(such as just the SetPoint).

Most of the web references to MVC is about frameworks and architecture, where the M, V, and C are distinct and clearly separable things. I’m less interested in how to define boundaries between things than in flow. Directions and arrows. The User exerts control on the state of the application. The User views the state of the application. Here’s the Wikipedia diagram for MVC If you search, you’ll be confused by seemingly different diagrams, which divide up Controller and View differently, but they all have the key flows between User and Model. I follow the principle, rather than trying to have specific application layers identified as M, V, or C. — James PS> a link to the video referenced.

I’m more going for SER, Signal-to-Effort Ratio, at the moment as I have limited time to spend on things like editing. Something is better than nothing. And a programming instructional video that doesn’t drag is a pretty high bar (not sure I’ve seen many of those!).

If I were looking at improving an old program I would first look for and refactor any natural ‘objects’, bits of data and actions on that data. You, for example, might have a ‘Camera’ object for taking images, or a “Sample Positioner’ object. Only after this would I ask if some of these objects should exist in separate loops so they can do things in parallel. Re the various QMH designs, I gave a talk recently about some of the issues (main point: don’t use the NI QMH template; use something like the JKI template).

I've started to make some instructional videos on YouTube for my Messenger Library. I was inspired by Delacor's nice videos on their new DQMH framework and also by Steve Watts' CSLUG channel. Any feedback appreciated. James

The lifetime of references like Queues are tied to their calling “hierarchy†(basically the top level VI). Your main thread creates the Queues, so they die with it. Your other ‘threads’, started by ACBR, are actually independent hierarchies. If your main thread finishes before they have a chance to read the final message, then that message is lost. Normally, I have the receiver of a Queue be the one to create it (and thus own it). Use a temporary Queue to pass the created Queue back to the caller.

I thought they had fixed that issue before 2014.

I gave a talk at the recent CLD Summit in the UK where I explain the issue. It is a public video on the CSLUG youtube channel.

I haven’t had an RT project in several years, but if I had a new one I would probably stick to only a single (message-based) method of communication between RT and HMI, and possible only one instance of that. What do other people who do a lot of RT work do?

Question: Do these toolkits support events (such as Shortcut Menu events, Cursor Events, etc.) and do they work with subpanels?

An advantage of many-to-one messaging is that, if you make the message receiver (the “oneâ€) the owner of the reference, then you don’t have to worry about reference lifetime at all. The secret there is the ability to wait on the reply to a message, and have any error passed back with the reply. With synchronous methods to send a message and wait for a reply one can interact with an asynchronous loop just as if it were an object.

Another option, that I don’t think anyone has mentioned, is using a by-val object, but placing it in a DVR (rather than the DVR in the object. Then one can use the by-val object directly in one loop, or share it with a DVR among multiple loops. And you have the ability to call multiple methods on the object within a single IPE structure, which can protect you against race conditions.

Messaging doesn’t actually cost anything (it’s just a pointer under the hood); it’s copying that can be expensive. If you pipeline, with A collecting data to pass to B (without A keeping a copy itself), then there isn’t any copying. Similarly, if you share data between loops with a DVR, but make a copy somewhere (to update an indicator, say), then you have the same overhead as if you had made a copy to send in a message.