drjdpowell

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.

JSON is an interchange format. Reducing coupling between components is what it’s meant for, so it’s sad that we worry about unwanted dependancies. The “variants that contain only strings and numerics as basic datatypes” that you are asking for are a much less flexible substitute to JSON text. I would not be happy if I had to do lots of manual type conversion on everything that isn’t a simple string; that’s an undesirable dependency to me. Really, the best solution would be for NI to realize the value of a JSON-like datatype and build that into LabVIEW, replacing this library entirely with a much faster solution that can be widely used in interfaces between modules without worrying about unwanted dependancies. As an alternative, have you considered using the JSON text itself as the thing to pass on, rather than a variant? Try this: replace your “data” Variant with a string labeled “<JSON>data”. That tag indicates to the library that you want your “data” subitem as JSON text. Pass that string across your subVI boundary. If you are just using strings and numerics, then your Caller can use the inbuilt JSON primitives to convert very quickly into data, so it isn’t dependent on this JSON library. Personally, I solved this issue by deciding to make this JSON Library a standard component always used in all cases where complex structured data is passed between modules. But then I did write the library.

The attached VIPM contains an extension of Messenger Library that is intended to add extended functionality to controls/indicators, via a background process that is launched and which registers for the events of the control (the background process is a Messenger-Library “actor”). This is meant to be an alternative to XControls. Included are two “Augments”, both with examples. See <examples>/drjdpowell/UI Augments/Examples/EXAMPLE Twin Cursor Graph Augment. This takes any graph with two cursors and draws a line between the two and displays summary info of the data between the two cursors: There is also a cross-section plotting for a 2D intensity chart: This package is in LabVIEW 2015, and requires Messenger Library (latest, in the LAVA-CR) and JSON LabVIEW and Shortcut menu from Cluster (both in the LAVA-CR). drjdpowell_messenger_ui_augments-1.0.0.8.vip

I quickly tried this string and I didn’t get any error.

I tend to use subVIs one layer lower down from the loop actions, as explained in this post. One can have subVIs that represent actions of the loop itself (as the AF does, for example), but I usually find that to have (minor) disadvantages.

I agree, but the JKI “state queue” is not an external interface. It cannot be accessed from outside the loop (it’s by-value, not by-ref). Requests from external sources enter via the Event structure, which is only consulted when the “state queue” is empty. “Macros” are multiple actions based on a single request/event. Added later: my talk at the 2016 eCLA Summit was on how to handle actions like a subVI, though I forgot to mention that the JKI “state queue” can be used that way.

I tested back-saving a significant feature that I want to add the Messenger Library, the "Graph Augment" UI stuff mention above. Going to 2011 gave a long list of problems due to missing features (such as "Get Control Values by index"), but going to 2013 gave no error.

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011). So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

Bit of both. My work code is 2015 (except for one 2013 client that I'll soon upgrade), and when I think I want to incorporate some of it into Messenger Library I am inconvenienced by the lack of some features I have used (such as the Concatenating-tunnel indexing option, or the "VI Deactivation" Event). Spending time recoding to support LabVIEW versions that I don't intend to use doesn't make much business sense. I don't think there is anything that 2015 has over 2013 that matters much, so I'll probably go to 2013. BTW, did you finish your big comparison of frameworks? If so, care to give Messenger Library a review on LVTools?

I am considering changing the LabVIEW version I develop Messenger Library in from 2011 to either 2013 or 2015. Does this cause a problem for anybody? Older versions would still be available through LAVA-CR.

Past versions are all archived on LAVA.

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015. What versions do people need?

How do they manage not to (implicitly, at least) queue up "events" that affect a serial-access resource? Real-world events do have time-ordering (pick up the ball, throw the ball, catch the ball) so I'd be surprised if it would be useful to be agnostic about this. Other LabVIEW features, like parallel calls on non-reentrant subVIs or DVRs, are all implicitly queued.

JKI State Machine “states” are actions that are executed internally by the loop. Unless one deliberately calls the “idle” state, “macros” of states execute in an atomic and isolated manner. That is not the same as sending a set of messages to another process, where you have no control over what other messages are executed intermixed with yours.

If a component doesn’t have a UI (including a “debug UI”), and doesn’t use DAQmx or IMAQdx (which interface with Events), and doesn't have a reason to want multiple incoming message channels (you can’t wait on multiple different Queues like you can with Event-registrations), then I often use a Queue. Though the benefits of using a Queue are, to my mind, very minor even in that case. Queues are slightly faster, and have extra features that I either usually don’t really need or I actively think should never be used with interprocess messages (like enqueuing on front or flushing).

Just an aside, but I almost never use User Events as 1:N. I use both Events and Queues as N:1 message carriers. Each receiver creates the communication method it prefers, preloads any initial messages, and then passes it to the sender(s). For 1:N I use arrays of these Events/Queues.

My two thoughts on this were: 1) is this actually a bug? Having the top end of a range be exclusive is not unusual, I think (if unintuitive at first). and 2) who uses this function? I can’t think of a use case.

Latest version has an improved Object Cyclic Probe that uses XML flattening to display the contained data in arbitrary objects. An example is below, where I am debugging the command pattern in the Cyth SQLite Logger: