drjdpowell

What are you meaning by a “thread” here? Users don’t create threads.

No, because you didn’t identify what package you want.

Added to 1.8.1 version now in the CR. Please test it for me.

Sure, Ben. I haven’t needed such thing (yet) so I hadn’t put it in. Is it just the number of elements in the queue that you need?

Some refs are static; they always exist and you are neither creating or destroying them. “This VI†and control refs are of this type. “Closing†these refs is a no-op. Other refs are both dynamically created and involve holding resources open of some kind (like an open file, or a Queue or something). Here is where one worries about ‘memory leaks’.

Basically a function call on a server. Used for controlling the server. “Calibrateâ€, “Measure Sampleâ€, etc.

The speaker who called it an anti-pattern was Dmitry, at the recent CLA Summit in Berlin. I don’t think he posts on LAVA, but I suspect he might argue that calling code should decide if “data being dropped†is acceptable or not and thus either dropped data should be an error (with calling code forced to decide what to do) or it should be a separate output, such as a “data dropped†boolean, which calling code should immediately either handle or explicitly choose to ignore.

The VI ref was created by the calling code, and the calling code is responsible for closing it if/when it needs closing. If I were updating this VI, I might add a “VI ref out†output to visually prompt the developer to deal with the ref.

Many LabVIEW developers don’t use warnings, and I recently saw a talk where they were described as an “anti-pattern†(a common software design that has more negatives than positives and should be avoided). You are right though, that a toolkit like OpenG shouldn’t be dropping warnings that pass through it.

Thanks Neil, The toolkit gives off a “not quite ready for prime time†vibe to me (including that annoying partial implementation of events, poor documentation, minimal single example, etc.) so I’m glad you are happy with it. I suspect it is an incomplete version of OPC-UA (no method calls?) but probably sufficient for the simple server I need to make. Thanks again, — James

In case the OP wasn’t aware, there is an Actor Framework group on NI where there are more AF users who might respond. Waiting on things that are reliably quick is often the best thing to do, IMO, as it is often simpler.

Hi Neil, I'm looking in to using LabVIEW's OPC UA implimentation, both client and server, and wondered what your experiences were with it. Would you recommend it? -- James

HI Rob, Have you looked at the example code (and video linked to) here? It’s a TCP example. Standard Request-Reply and Register-Notify should work seamlessly over TCP (as the various TCP actors route the messages back over the connection) without needing to do anything special.

I use composition instead of inheritance: actors with common behavior will all use some common class to get this behavior. You can change the “Default†message case from throwing an error to calling a “Handle Message†method of some common class. The “Pipeline Component†actor classes, in the example above, all contain a common class that handles common messages (the actors can “override†these messages by choosing to explicitly handle them). Note that you can inherit off of this common class and inject different behavior to your actors by having the caller send the common class to the launched actors. Below is an example that is as close as I’ve done to all-internal-data-in-one-object. All this actor does is receive a “Graph Augmentation†object from it’s caller, then it passes all events on a graph to methods of this object. It also passes any unknown message to the “Receive Msg†method. “Graph Augmentation†is a parent class of several children that actually do things, and 99% of the work is done in methods of this class. This is quite powerful, but it is also harder to figure out what is going on. You would have an easier time understanding my other example, because you can see high-level stuff happening on the diagram. Here it is just “Cursor Moved—> call 'Cursor Moved’ dynamic-dispatch method; Message Received—> call 'Receive Message’ DD methodâ€.

Personally, I tend to look to see if some of the actor’s data should really include one or more classes, then my subVIs are methods of these classes. I generally try not to have a class that is all the data of the actor, or have subVIs that pass in all the data (you’ll note I don’t even type-def the Internal-Data cluster). I like the high-level actions to be on the top-level block diagram, but the details hidden in more specific subVIs that only act on part of the date. For example, here is a Top-level actor that presents a picture to the User, showing a “pipeline†of analysis actors, where the User may modify the pipeline by adding, deleting, copying and pasting. The code for copy/delete is shown. This code is basically: If the User selects “Deleteâ€, then identify which icon was clicked on, write the deleted actor to the Clipboard (so the User has the option of pasting it elsewhere in the pipeline), and delete it from the Pipeline list of actors (calling "change pipeline.vi†to complete this). There are three complicated bits of detail here, but they each only need part of the Internal data. There is a method of the “Icon Picture†object that handles all the details of the picture (rather complex internally); a method of the (not so complicated) “Clipboard†object; and a subVI that acts on arrays of “Pipeline Component†Actors. No subVI needs all actor data. BTW, the actor class here (your “Solo_Msg.ctlâ€) is actually serving as the address of the actor to external processes, so I wouldn’t try and make it do double duty as an internal-data store. Instead, you could make a different class. You could even have the actor’s caller preconfigure such an object and send it to the actor after launch.

This link might be of interest. It redirects stout of System Exec.

Using a number of interaction queued message handlers (QMH) is quite a common architecture (sometimes known as “actor-oriented design"). There are multiple packages in the community that people have made available**, and I believe quite a few people have their own private implementations. Personally, I usually have a separate QMH for each independent bit of hardware. I have sometimes done an LVOOP driver (with child types) inside a QMH, which I think is what you are describing. ** Mine is Messenger Library (an introductory video); there is also the Actor Framework (part of LabVIEW), Delacor DQMH, and Aloha, just to name a few that are available on the LabVIEW Tools Network, and you’ll find a few other examples on LAVA such as Message Pump.

Do you have specifications for the different types of units? If so, you can query the unit for its type then load something specific to this type. Could be a special INI file for each type, or a child class if you are using LVOOP. The file/class would specify what settings are available. Are you testing these units, or just using them? With testing you should test to the spec, not query the unit for what it can do. Otherwise you won’t catch a unit that fails to support a setting that it actually should.

I suspect you had some error in calculating the index. “Insert into array†will fail if you have the wrong index (so inserting at index 3 in a three-element array will produce a four-element array, but inserting at index 4 will silently fail). I would use Build Array instead.

Is your actor reentrant? The VI should be named “Actor.vi†(rather than ActorNR.vi) and set as shared-reentrant. If that isn’t the problem please post an image of your launch code. I use arrays of actors in some of my projects (and the library has VIs meant specifically to work with arrays) so it does work.

See this new video on youtube. I modified the demo so that 'Instrument' is running on a separate project behind a TCP server, with 'Top Level' connecting as a client via a Remote TCP Messenger. I also showed the use of an 'Address Watchdog' to shutdown 'Top Level' if ‘Instrument' disconnects. Here is the code (start the server first): Messenger TCP Server.zip Messenger TCP Client.zip I think I forgot to mention it in the video, but note that the Client project does not load the code of “Instrument", and the Server Project does not load the "Top Level" code. Thus, nothing is locked and you can edit freely (this is a problem in some architectures). This is done internally by the TCP server/client actors by keeping all reply addresses in flattened form on the remote target. If you use custom probes you will see most replies or registrations become something like "Route back to QueueMessenger and then to Flat", which is confusing but means "send back to the TCP actor running this connection, then via TCP to the remote system, and then to this address (unflattening it first)". Please note that only Reply Addresses are converted; you cannot send an address as data in a message and have it work on the remote system (attach it as a Reply Address instead). Please note that I have yet to do a Real-Time project with Messenger Library. I do have a current project using modified TCP actors to communicate with a non-LabVIEW client from another developer (using JSON messages), but that isn't the same. So please don’t be afraid to ask for help or to make suggestions. Please see if you can run this example with ‘Instrument' on the Real Time system. -- James Actor Manager for this TCP example. Note that the 'Control Server' actors are entirely unmodified, and have no knowledge that they are talking to 'Instrument' via TCP. Because everything is by message (no DVRs, no Action Engines) it is easy to convert things to remote operation.

I’ve added a couple of more videos about the Register-Notify system used in Messenger Library. A couple of people identified Notifications as something I had not explained sufficiently (especially the difference between an “event†and a “state†notification). So I have added Register Notify and Notification “Hookup†of a dynamic actor (and generic messages). The later video also shows a technique of handling messages to do with multiple controls in a single Variant-based case. Updated example code:Messenger Library Demo.zip I’ve also made an initial Introductory video to SQLite in LabVIEW.