drjdpowell

You mean using LVObject? You should also consider if it is worth having an abstract parent “system” class, and then have the ‘handler’ VI (I use the terminology “shell”, as in “async launch shell”, BTW) be in a child system class. More work but could be more flexible later on. BTW, if/when you get to benchmarking launch times of your handlers, can you try the following: on the first use of a handler clone (when the overhead of creation happens) try it with the handler being part of a class library, and then not part of a class library. I found with my code that it was about four times slower if in a class library. If I recall right, I got initial creation times on the order of a couple of milliseconds if it isn’t in a class and 8 ms if it is (reuse of an existing clone was much faster, something like a 0.2 milliseconds).

I never ‘clean up’ the reference, I let it die automatically with it’s creator.

I keep such generic ‘handler’ VIs in a non-reentrant VI’s shift register. I only need one of them so why put it in class data?

Another hint on the bonus question: To log all the data I collect, I took care to Start Acquisition only after Logger replies that it is started, and I Stop the logger only after Acquisition replies that it has stopped. Yet the Message Display received the stop info published by the Logger first. What happened?

Sending things to the controller is fine, but if all the Plotter does is plot raw Hardware data, then what are you gaining by splitting them? If it’s more than that; if Plotter is more than just a straight UI for Hardware, then it makes sense. Personally, I would always start with a “Hardware” actor running by itself, for initial debugging in isolation. For that, Hardware needs a UI (preferably simple, low-overhead, and one that has no overhead if Hardwares Front Panel isn’t loaded). Often this UI can serve as a part of the application UI by being in a subpanel. Ask yourself this: if you reused Hardware in a new application, would you reuse Plotter as is? If so, maybe it would be simpler to combine them. If thing’s got worse when you reduced the UI update rate then you did it wrong. No. Though you can do the equivalent thing with messages by having them flag the need for a UI update, but not do the update till later (after many messages have arrived. Do you batch signals? Or send a separate 30+ messages/sec for each of 50 signals? 30 messages per second containing all signals can’t have THAT much overhead. Oh, BTW, make sure your not using “Build Array” anywhere as that can be slow.

Why is your Call Parent Method AFTER your “state machine”? It needs to be in parallel to handle messages (such as “Stop”).

I don’t know where the bottleneck is, but you’ll have problems pushing 50k to 200k messages per second between actors. For display operations you should definitely have a flush queue in there somewhere, so updates can run at a slower rate than arriving messages. If you do go with a shared reference, I wouldn’t use a DVR; instead share a data queue like the one you use in your Plotter Actor Core. Create that in Plotter and pass it by message to Hardware. Then you have a direct, low-overhead stream that you flush a few times a second. — James BTW, I don’t know the details of you application, but I would be tempted to make basic plotting of raw data a feature of the Hardware Actor itself.

Could you not have the Hardware Actor batch up measurements, rather than the Controller? Does your Plotter Actor always do slow display updates (Property nodes) for each message? You can write it to only do display updates a few times per second even if new data messages arrive faster.

Bonus question: My screenshot of the Debug window seems to have inadvertently demonstrated a problem with my message-publishing “Observer Register” system; can anyone spot it? Hint: look at the last five messages.

For discussion, here are shots of the “Debug Option”, where I’ve added some extra comments. First the “Debug Option Dialog” case in the Main actor: This is an asynchronous action; the Main code continues while the dialog is displayed. When the User dismisses the dialog (or the 30s timeout occurs) a message is sent in “reply”. Here we are sending the result back to the Main actor, and are relabeling the reply as the command “Dialog::Start Debug Option” (the message contains the label of the button the User pushed). Effectively, this is an asynchronous request-reply to the User. The Main actor receives the “Dialog::Start Debug Option” message: Note that because of the "two-queue" nature of the JKI “state machine”, this message cannot be received before all the initialization cases execute (this is a potential race condition in the original NI example). Now the code triggered if the User clicked the “Yes” button, “Start Debug Option"): Note how we drop the address of the Message Display actor! We don't trace the actor wire outside of this case. This violates the usual rule of always cleaning up references that you create. But it also means we know exactly what this actor will do by just looking at this limited code section. This messaging setup is thus "static", in the sense that once started it will continue until the Main actor stops (the Message Display actor is an "Autoshutdown Slave", meaning it automatically shuts down when the code that launched it goes idle). We can, of course, choose to store the Message Display actor address in the shift register, and thus modifiy its interaction at a later point. But personally, I think being able to drop the wire refering to something improves readability because one can see that something is not being modified elsewhere. Note added later: of course, we don’t truly drop the Display actor’s address, as it is sent off in registration messages to the three other actors. But in this form the address can only be used to send the specified published messages (in this case, all published messages, but with an added prefix), and there is no ability for the other actors to send an arbitrary message to the Display actor. Thus we have fully specified the messaging interaction in the case that launches the Message Display. The ability to create limited-use versions of an “address”, such as causing the addition of a prefix, or wrapping it in a registration message, is an important part of the philosophy of this framework. And this is for code readability; if I pass a bare, unrestricted, address to another code module, I have to inspect that module to verify what that address is used for. But if I pass a limited-use address, then I can be sure of how it might be used, and it greatly reduces that amount of code knowledge I have to fit in my poor brain at one time. Finally, heres the Message Display debug window: Good debug tools are critical in working with asynchronous communication. There is also a custom probe that displays message history in a similar way. Comments? — James

I don’t know enough about your architecture to follow the issue. My “Reply” method is a public method of my message class. If you looked at the “reply address” of a message received through my TCP client server, you would see that it points to a “TCP Connection actor” spawned to handle specific TCP connection. As there is one TCP Connection actor for each client connection, this effectively routes replies to the right destination. As for errors in making a reply, let me offer an alternate philosophy: ignore them. I impose a design constraint that a Request-Reply transaction is the responsibility of the Requestor. The Replier is responsible for attempting to reply to the address provided, but is not concerned with a failure of that address. That is outside it’s scope.

I posted it here. Unfortunately, I feel in that presentation I spent too much time on the inner workings (some of which are complicated), rather than on the use of the API (which I hope is simpler).

You don't need a getter; you need a Reply method.

Though "leave them all running" is a simple option, I prefer the "have the publishing system remember the latest value" option, similar to Paul's shared variables.

Why? You can still have the replies routed back through your connection process. Attach to the original message whatever info is needed to direct the reply.

A simple option is to just keep the UI components running when they aren't in use. Personally, the publishing-type system I use distinguishes between "Event" and "State" messages, with the latest value of all "State" messages being stored, so that newly registering components can be sent the most recent info without the need to implement "queries" in all the publishers. It's additional overhead, but it greatly simplifies things. -- James

Here's an updated JSON package. Please give it a try. lava_lib_json_api-1.1.2.19.vip

Mixed up precision and significant figures. Now proposing: SGL: %#_7g (seven figures) DBL: %#_15g EXT: ?!? (I can't seem to get more significant figures for EXT than for DBL using the format as text functions).

Here is a topic suggesting an increase in the number of digits precision used in formatting floating-point numbers.

Googling other JSON implementations, I think we should change the format to the following: SGL: %#.6g (equivalent to the %#g we have now) DBL: %#.14g EXT: as many digits as the LabVIEW functions to make text from numbers give us, which seems to be only %#.17g from my limited testing This is deliberately less than maximum precision, so as not displaying decimal numbers like 0.1 as 0.10000000000000001.

The set variant VI would need the same input, either "numeric format" or "numeric precision".

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.