drjdpowell

A major goal of my "Messenging" system is to make passing messages between loops and asynchronous VIs easy; easy enough to NOT be tempted to bypass it with alternate systems. I also hope to make the individual interacting components (actors or loops) simpler and more flexible by giving them a simple common method of providing information to other components. I'm concerned that the initial learning curve is obscuring that it's supposed to be easy. Pick an actor template (there's three), copy it, open the one and only "Actor.vi" that defines the actor and add message-handling cases. "Reply" to messages and publish info using "Notify". Then drop your new actor in your main VI, "Launch" it, and "Send" it some messages. Every step is actually quite simple. And it's scalable; make a few actors and hook them together with the "Register by Label" method (like the Acquisition and Logging actors are connected in the example). One only has to create one VI per actor, and only the most basic of LVOOP familiarity is needed (basically, just don't be frightened of a LVOOP class constant).

For lack of a better reason I just used the default. More digits would be better for precision, but worse for compactness. Perhaps we could make the format string an optional input?

For reference, if you put some data into a DVR, it will continue to exist until: 1) you explicitly release the DVR. 2) the owning VI (the top of the call chain that created the DVR) goes idle (stops). 3) you access the DVR with an IPE structure and change the data. LabVIEW will not destroy/change the data for any other reason. It does not matter if you DVR reference (which is just a number) is in a shift register or not. If you are "losing" your DVR data, you are either doing one of the above three things, or (4) you are losing the DVR reference number somehow. BTW, from your description I would guess that whatever code is receiving your "event" is releasing the DVR. Thus if you make a copy it solves your issue.

Ah, a terminology problem then; this code actually has nothing to do with the Actor Framework. Rather, both take the "actor" terminology is from the Actor Model, which is used by a large number of frameworks for many languages. I used the JKI because that's the QMH template I've used for years. Perhaps I should adapt the QMH used by the NI example. I don't really like it because it's a "send messages to myself" style which I think is potentially problematic. You could share references, but the idea behind the Actor Model is that such sharing becomes more and more problematic as a program scales up in complexity. My "actors" are actually nothing but single asynchronous VI's sitting behind a message receiving mechanism. Was that by Allen Smith? I saw his talk at the European CLA summit. If I may criticise the Actor Framework, that is just too complicated. Even bending the "actor" rules for the "flexible UI" is too complicated.

Thanks, that in itself is valuable.

I just rename them and let the SCC record the old class as deleted and the new one created.

C'mon guys, throw me a bone. Did anyone at least get it to run?

Your images show neither the creation, destruction, nor actual use of your DVRs, so it's hard to be of any help. Like other LabVIEW references, the DVR will be tied to the VI hierarchy that created it, and will be destroyed if that hierarchy goes idle. However, unless the OP is using dynamic launching of asynchronous VIs, there will only be one hierarchy, so that wont be an issue.

Multiple dequeuers on a Queue are predictable; one and only one dequeuer will get each element. This can be wanted if what you want is a worker pool. But multiple Event Structures drawing from the same Event Registration is unpredictable, because at least one, but possible multiple, of the structures will receive the event. This is always unwanted behaviour, so one cannot do a worker pool with User Events.

I think Jack is referring to a 1-to-N "Worker Pool", where one desires one (and only one) worker to handle each task. This is simple with a Queue but can't be done with User Events. You're talking about a 1-to-N multicast, where every receiver gets a copy. This is easy with User Events but requires an array of queues to work with Queues. -- James

Why was it only a problem in an EXE? That should be a problem in the IDE also.

I doubt it, but a good debug mode is to have all your subUI VIs open their front panels instead of inserting them selectively in the subpanel. Try that and see if that makes to memory issue go away (and check that all are functioning and not blocked when they are "closed").

I your app working normally while this memory is building up? If one of your components' event loop were somehow paused (by something that happens only in an exe) then User events would build up as observed.

Any comments on this? Too complicated? Too simple?

You can use lots of them; I often prepare several statements once just after I open the database connection.

But does it leave a path of easy steps for new programmers to learn? If you can only use technique X if you also use techniques Y and Z too, then you’ve introduced a high all-or-nothing step in the learning curve.

Here’s the long neglected Idea Exchange entry for that very worthy idea.

An alternate is below, using synchronous “queries”, where the subVI waits for the remote actor to reply to the command (we don’t care about the contents of the reply, just it’s existence). This seems a lot clearer. It’s disadvantage is that the Main message-handling loop is blocked while the two subActors start up, but in this case that is no problem, as we are preventing the User from doing anything anyway with the Busy Cursor.

I’m hoping to add some sample projects to my “Messenging” package, and I thought it would be easy and instructive to rework one of NI’s templates, “Continuous Measurement and Logging”, as it is already somewhat actor-like with three communicating modules. Attached is a (back-saved for 2011) copy of the NI project, with my version included (run “Main.vi” for the original, “Main.lvclass:Actor.vi” for my version). I kept the basic functionality the same, but couldn’t resist changing some of the UI (in the old code, “Main” controls the UI; in the new code, published state messages from the Acquisition and Logging Actors set the UI). Continuous Measurment and Logging with Messenging.zip Any comments appreciated. Is this example less clear than the NI original? Why? How could I improve it? In particular, is code like this (the most complicated interaction, I think) understandable without heavy documentation? It’s a “Start Logger, then Start Acquisition, then Unset the Busy Cursor” three-actor chain message: I’m thinking of making a “Send Chain Message” subVI (that accepts arrays of addresses and message labels) to replace the above code. — James

Though recently all my multiple event structures have been in separate VIs (often with front panels assembled via subpanels), I don’t see any reason why multiple ES shouldn’t be on one block diagram. And I certainly had such on multiple occasions in the past.

I make a project that holds EVERYTHING that references the classes involved and then rename classes and move things about in the Files tab. Once the set of things referencing it becomes too big, or I have it in a reuse VI package form, then I’m stuck with Darren’s solution. — James

I looked into zeroMQ with the idea of using for actors, but I couldn’t really identify how it would work for me better than just using TCP connections. ZeroMQ has many communication patterns, but none really matched up to what I need in an “Actor’s address”.

For anyone using this package, I’ve uploaded the latest version (should really have updated this more than once a year). I’d like comment on the following new features: This is one of three asynchronous dialog boxes. This can be used in a “delayed message to oneself” form of doing a continuously updating process (as opposed to using the “Metronome” helper actor or the (ill advised) timeout case). Intended for when the reply is uncertain. With this VI, a process can be confident that it will get a message of some kind back, and thus does not wait forever. Observes an address and triggers a response if that address goes invalid.

I had original made similar probes using an Xcontrol, with the idea that display customization would then be easy (and clean, using right-click menus). But after a lot of head banging I abandoned Xcontrols as unsuitable (lossy if asynchronous; too slow if synchronous) and wrote this package in an afternoon. They are, thus, very 1.0. Haven’t felt much need for a pause option, as I can always just select a different probe for that, and I use these probes in debugging communication between parallel processes; pausing one process while the others continue can be unhelpful. Adding a “pause the probe” option is very easy, though, and I see that Saphir’s probe has this option (labelled “Freeze display”). I’ll consider that for the next release. Thanks.

As an aside, there is also LabbitMQ, a LabVIEW interface to RabbitMQ, to consider.