drjdpowell

That 15-30 sec figure, at 1.5 to 3 ms per line, seems an order of magnitude too slow to me.

I've just got the evaluation kit for an sbRIO with RT Linux. I ran the example with 'Instrument' on the sbRIO; I found that the OpenG zlib compression library did not deploy to RT Linux. So I had to disable zlib with the following Project Conditional Disable: ZLIB_Compression == OFF Otherwise I didn't make any modifications. But I (so far) have not been able to get my custom probes working on RT, so I'm investigating other RT-usable tools. -- James

OpenG was written before proper recursion existed in LabVIEW, and uses (slow) VI-Server calls to dive into clusters. MGI is more recent and uses proper recursive calls, so should be significantly faster. Personally, I use JSON for configuration files.

Why are you not just (plain-old synchronously) calling the subVI?

References are “owned” by the "VI hierarchy" that created them, and are automatically destroyed if that hierarchy goes idle. Asynchronously-called VIs run in their own independent hierarchy (even if you use the Run method instead of ACBR). In your example, the DVR was destroyed when the launched VI finished.

Why? Actors are tools. One configures a tool for a specific task. You know the task; the tool doesn’t. Why would the tool be responsible for configuring itself?

I use messages containing JSON for configuration, combined with a subVI for handling "Set Config” or "Get Config" messages that accepts config info as either a variant cluster or an array of control references. Once set up, adding new configuration info is trivial.

You could extend your Action Engine to have a “Register” action, which takes a User Event and saves it in an array internally, then posts to the Event whenever the config value changes. Then processes loops can register if they need to be informed when something has changed. Then you have a hybrid AE/messaging system.

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â€.