drjdpowell

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.

Are you sure that’s true? Why do they say DVRs should seldom be used. I rarely use them, but that's because I rarely share by-ref data between loops, by any method (I use messages, instead).

I note that the SQL code to do arbitrary planer cuts through a 3D cube seems relatively straightforward, with a single large table and a simple WHERE statement ("SELECT … WHERE ABS(1.2*X+0.3*Y+.9Z) < tolerance", for example). So you should prototype that with a large dataset and see if the performance is sufficient. Also, don’t neglect the 3D picture control for visualization.

I think they mean creating Destinations set to LLB on the Destinations tab of the EXE build spec. I tried putting LVLIBs in these Destinations and it seems to work. Added later>> shoneil posted while I was experimenting.

Some of the presentations at the recent CLD Summit in Newbury, UK, were recorded by Steve Watts and are available on the CSLUG YouTube Channel.

Each plot can only be associated with one X scale; I’m not sure what the “normal†your referring to is.

Both your plots are on the same X scale, so the second X scale has nothing to autoscale to.

Bug still present in LabVIEW 2015. I have reports of this issue in an app of mine, though I don’t touch the Yaxis properties at all. Does anyone know of other properties that trigger this issue? — James

Notes on the 1.6 version: 1) there is a “Create Actor From Template†option under the Tool>>Messenger Library menu. the DEV template is what I mostly use, though there is also a JKI “Statemachine" version. 2) One can now make actors non-reentrant. To do this one must rename the “Actor.vi†to “ActorNR.vi†in addition to making it non-reentrant.