drjdpowell

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.

Did you wire up the minus as 2-(shift reg), then move the wires around to make it look like (shift reg)-2? Then the shift reg would go 10, -8, 10, -8,… and never be less than -10.

Well, the internals of the framework are not intended to be modified (or at least that would be a very advanced use). Application-specific code is meant to just be simple message-handling loops, with an API for passing messages. No LVOOP beyond copying a template class containing one “actor.vi†method. That those “actor.viâ€s are forced to be shared reentrant, with a resulting learning curve, is a problem. This conversation has lead me to reattempt a way to allow non-reentrant actors and I think I have a solution that works well, with the ability for a CLAD to more easily find his way through the code. I’m going to try it out in my current projects.

Exactly. They seem to me to be much harder for a CLAD to get to grips with than my async-called, shared-reentrant actors (though I am an XNode novice). Poor wording on my part. I don’t mean community standardization; I mean developer or team standardization on using a limited set of ways of doing things, so that one be expert in those techniques, and one can read and understand code quicker. I use my actors extensively, at multiple levels in my code. I don’t use techniques like “Action Engines†or any asynchronous calls of custom VIs, because I’m standardizing on Messenger Library actors. The actor I did just today is a small, one-VI-API “helper†that adds functionality to a WaveformGraph. It is based on the exact same actor template that is used by my “Top Level†main application, and is using the same standard techniques.

Is that how your CLAD programmer learns about your Xnodes? But your right, it is a problem. Even though I could show someone what to do in minutes, it’s easy to have no idea what the first step to do is. Fabiola is fighting that problem by providing several instructional videos for her new Delacor framework. I’ve been trying to develop a way to make my actors easily switched between reentrant and non-reentrant, so I can leave single-instance actors as more “just open and seeâ€. It hard, because I don’t want to give up other simplifying features, like auto-shutdown of actors. As Fab points out, one can also provide a junior developer simplicity via a simple API or set of tools that encapsulates complexity. And personally, I think there is simplicity in standardization, since there is so much effort in learning code structure.