drjdpowell

Make it that simple and perhaps I do use Action Engines. Turn the enum into an “(Re)Initialize” boolean, or have the code initialize itself on first call, and you’ll find such things in my code. But none of them will be usable to communicate between code modules like AEs are often used. Logging is a good example of where multiple things can share something without affecting each other.

I must not be understanding the problem you’re presenting. Perhaps you could explain a AE/DVR solution, and illustrate how it cannot be done by messages. You mention Daklu, who only has LapDog as a reuse library. LapDog is less a messaging framework that your Dispatcher. Dispatcher is an implementation of a “Message Broker” messaging pattern, I believe, so one is making more of a design choice by using it than one would be by using LapDog. My “Messenger Library” is meant as a flexible message passing library, where you don’t need to use the “actor” stuff at all if you’d rather not (most of the examples installed with Messenger Library are simple message passing). Its central messaging pattern is “Request-Reply”. The Actor Framework, on the other hand, is very much intended to be a framework to enforce a certain style of program architecture. One should (I hope) find Messenger Library very useful even if one doesn’t follow similar design principles to me, but it is (deliberately) hard to use the AF in a way not intended by AQ. Perhaps, though, you actually meant “principles” rather than “framework”, as Daklu has written a lot about the “actor-oriented” design principles he follows.

Your kidding, right? Just register on “Total bytes downloaded” and look at the increase (which stops when they finish). Trivial. Edit>> or register a Queue for all the “Throughput” messages and average once every 10 secs. Also easy. And are you really worried about sub-millisecond timing uncertainties on a 10-second average? If so, I think you have those with an AE also, just due to OS jitter. Don’t forget your “Dispatcher".

Well, the simplest way to do that would be to Register Notifiers (well, NotifierMessengers) for the info one wants and then For-loop over the Notifiers to get your snapshot. I’m not that fast at coding but it’s no faster for me to make an AE. And don’t you have to modify all your data sources to add calls to this new AE? I don’t have to modify any of the data-producing actors, my actors aren’t code-coupled via this subVI and can be reused as is, and some of my actors can be on remote systems (try that last one with your action engine!). How long would it take for a novice? I’m not as positive on the ability of novices to understand action engines (they seem to love Local variables, from my experience) but learning messaging patterns is more of a learning curve. But learning is an investment. Learning messaging is well worth it.

I have one User Event per “actor”, that basically carry Text-Variant messages. No maintenance at all. The main weakness of polling on “data changed” is that you can miss updates.

My first thought is “consider doing views of past history for real and use SQLite”, as I’m sure you agree. My second thought is “that sounds trivial to do with the Register-Notify messaging pattern”. Why in the world would you message subsystems to get data in response? This is what I mean by focussing on a few complimentary techniques and learning them very well. SQLite is very complimentary, but if one mixes limited-capability messaging with some similarly simplistic “tag” implementation then you end up with an overly complex result that is weaker than just picking one technique and really understanding it.

Oh yeah, there are quite a few “tag” libraries on NI.com. Using one of those might be better than rolling your own. I don’t use them because they wouldn’t give me anything I can’t do with messages, and they increase the amount of stuff I need to know (gotta know messaging, tags, and how tags interact with message timing).

Single writer is good. Why “global” then? I generally have data flowing around by messages and locally stored by anyone who needs to store it. The other issue is constantly polling a DVR for changes, versus receiving notification messages only when things change, but for “slow” apps that doesn’t matter much (but it affects your ability to reuse your solution in “fast” apps).

What are you “global storage needs”? How many writers are there of each data item?

Hey, let’s infinite-loop the conversation! I should clarify. Message-handling loops, Action Engines, and by-ref classes can all be used to organize a complex application into subcomponents and control interactions between the subcomponents. The means of interacting may be different, async messages versus sync subVI/method calls, but the purpose of these structures is the same. Because they are different, but used for the same underlying purpose, I would recommend that a developer focus on one. It reduces complexity if you standardize, and allows you to really get competent at the techniques you have chosen. If asked, I would personally recommend using messages over any by-ref techniques, and also not using globally-accessibly things like standard AEs, but it is more important that one pick a technique and get good at it.

Well, even at its most nebulous, “actors” interact by passing asynchronous messages, and are actively handling those messages. “Message-handling loops”, basically. That is significantly different than AE/DVRs, which passively wait to be synchronously called. More specifically, “actors” should follow the Actor Model, and I should probably have used the more generic "Message-Handling Loop” as a thing to compare with Action Engines.

Eh? Where was that in the discussion? I was comparing AE's, DVR-based by-ref objects, and "actors". One can do complex or very simple things with any of them.

Link title is "Passing Arguments by Value and by Reference" Ah, so you’re meaning pass by reference, as applied to arguments to function calls (terminals in LabVIEW), and some of the things we are talking about are not passed as arguments. I’m meaning “act on by reference”, or “having a reference to something”, meaning I have the means of acting on something that others also can act on. I don’t care if the reference is passed as an argument or is statically compiled in (like a Global or a subVI call).

That weird design has always mystified me. The editing tools for the IPE structure are also painful.

Yes, I also am not able to identify what you’re using the terms “by reference” and “by value” to mean, so I was trying to rephrase in different terminology in hopes we advance.

Let’s try a different tack. There is an important difference between situations where one loop can affect another loop operating in parallel (a side effect), and where it cannot. Globals, Locals, DVRs, Queues, Notifiers, FGVs, Action Engines, or the new "Channels” are all means where one can “reach in” and affect a loop while it is running. Data on a wire is not. An interesting talk related to this by AQ: Why Dataflow Works: The Potato and Candy Explanation

Branching makes copies; but the individual copies are not shared. Globals are by-ref.

Spend some time learning about Queues and User Events, and the concept of a loop handling messages. Forget about Get/Set invoke nodes.

Ah, you mean the encapsulated data. Your right, but you talked about a “shared resource” that might need “mutexes”, which is about accessing things from processes running in parallel. By-value objects are not sharable and have no use for mutexes.

Actors, AEs and by-ref classes can all be used as wrappers around shared resources that serialize parallel access to them and protect critical sections of code. They aren’t equivalent, but they have considerable overlap.

I’m surprised there’s not more love for Action Engines. I’ve never really used them, but instead have focused on making “actors/processes” easy to make and communicate with, and on having by-value classes live wherever it’s natural for them to live. If they naturally need to live in an independent process, then it is easier for me to make it an actor than an Action Engine. I’m not really negative on Action Engines, but they don’t give me capability that I can’t get with an actor, and as hooovahh said, I can do active, periodic stuff with an actor. I only very rarely use actual by-ref objects (usually using a DVR). “ForceCalibration” would most likely by a by-value object for me, too. As a general programming principle, I believe one should standardize on a set of complimentary techniques (and get very good at those techniques), rather than mix multiple alternate ways of doing similar things. Action Engines, “actors”, and by-ref objects are different ways of doing the same thing, so one should pick the one you think is best and run with it.

Have you looked at Help>>Find Examples.. and searched for an example of an intensity chart?

In the end, I decided to make my “Graph Augment" stuff a separate add-on package, so I don’t immediately need to switch up from 2011 in the main Messenger package. But I still think i will soon move up to LabVIEW 2013 anyway, for a number of minor reasons.

Try libLV_2835.*, as that means to use .dll or .so as applicable.

Forgot to add that a goal is to make adding functionality to controls easy, ideally a single subVI that can be called multiple times with different graph references. Customization is via references to simple subVIs used to generate the text. Below is the code of the first example.