drjdpowell

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.

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.