drjdpowell

I didn’t notice the MAX install part, so that might be my problem.  Thanks.

Here is my current RT version of the example project (to go with the newest version of Messenger Library).  To run the actor manager on the RT, you'll need to add it to the project (its in <LabVIEW>/project/Messenger Library).Messenger Library RT Test 2015.zip

Sorry guys, I was on holiday when Stobber asked his question.  Rolf has answered better than I could.   I have only used polling to identify changes.   I tend to have timestamped data with the timestamp as primary key, and getting MAX() of the primary key is very fast.   One could also use triggers to increment some field whenever something of interest changes, and then poll that field.

20 hours ago, smithd said:

I personally think the only real right answer is:

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

On 13/03/2016 at 9:56 AM, drjdpowell said:

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.

...

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.

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.

29 minutes ago, Stobber said:

Thanks, but "ugh" . Guess I'll have to pass a DVR in.

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

26 minutes ago, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

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.  

On May 14, 2016 at 7:37 PM, Neil Pate said:

Now I think perhaps each actor should be responsible for the serialisation of its own config.

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?

6 minutes ago, ShaunR said:

Well. Messages are ephemeral and config info is persistent so at some point it needs to go in a file. This means that messages are great for when the user changes something but a pain for bulk settings. Depending on the storage, your framework and your personal preferences, the emphasis will vary between the extremes of messaging every parameter and just messaging a change has occurred.

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.

1 hour ago, Neil Pate said:

I currently have no mechanism in my framework  for informing a process that a configuration value has changed. This works fine, but I wonder if others have gone the extra step and implemented configuration data using User Events and removing the global data store?

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.

33 minutes ago, CopperD said:

When the user hits the abort button in the IDE I want the threads they created to be killed.

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

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

1 hour ago, monzue said:

Number of elements in the queue is all that I have ever used.

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

1 hour ago, monzue said:

 Will you include a vi in the queue messenger library that is simply queue status?   I've made this vi a time or two, to see if a actor gets behind,  the problem is that when I switch to a different computer, or update the Messenger library from the repository, this QueueStatus vi is lost......

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?

Does this imply that, in general, "This VI" references do not need to be closed? So I am guessing that memory leaks typically arise from other references (e.g., control refnums, indicators, files, etc.)?

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’.  

What is an OPC-UA method?

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

I use warnings to tell users/developers that data is being dropped and an error is not appropriate for that.as it is a designed feature to protect the server/client.

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.

This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do.

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.

Also opening another can of worms...do you often have parent-child inheritance situations where an actor inherits from another?  For instance, for an "instrument" do you have an abstract parent and implementation in a child actor or do you make the messages abstract (message names shared between the same instrument type) such as "measure" and "set range" and the actors of the same instrument type do not inherit?

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