drjdpowell

Why not just use JSON as your message format? Python will have JSON libraries. Both JKI JSON and the OpenG Variant Tools are very slow, BTW. Try JSONtext, which I developed partly just to get reasonable performance.

Looks good, Bob. Can I link to it from the Wiki?

Wow, 47 pages is more than I've ever written on Messenger Library. Please post it.

I also use 2013 as my base for most reuse packages. It has the new tunnel options including the valuable "conditional" (fixed over 2012 to have good performance) and Variant Type VIs that are about 100 times faster (than in 2011 at least). The next really useful feature is VIMs in 2017.

A note on the discussion about LabVIEW refunms, such as Queues and the like. These are "owned" by the Top-level VI that created them, and are cleaned up when that Top-level VI goes idles. This could be the whole App, but async-called VIs are all their own "Top Level", so if your app is made up of many async called VIs ("modules", "actors" or whatever) then refnums have a quite reasonable defined lifetime, the lifetime of the creating module/actor/async-thing. This behaviour is reliable; I know because I routinely rely on it to trigger automatic shutdown of async running things when their callers stop for any reason.

You should kudo this then: Means to register a DVR-cleanup callback for use when DVR released when VI goes idle. This would allow DVRs to wrap all dll pointers, with proper cleanup regardless of how the VI stops.

I've never looked at rti-dds, but could you implement a "reply address" with it? Instead of a blocking command-reply, you could do an async command-reply-continuation. I talk about this messaging pattern in this GDevCon talk: https://youtu.be/HIuzY_Bs7BI (staring at 7:38). Regarding Event support, you can always write a reusable forwarding loop, which listens to an rti-dds whatever-they-call-it and posts the messages to a User Event. I'm a believer in not cobling together different communication methods, and if I had your use case I would try and use only one package to implement it, adding capability if needed (though in my case that package would be Messenger Library, of course).

You're certainly using the TCPMessengers in an unanticipated way. Why are you not just using your RTI-DDS stuff for everything? Mixing multiple different communication systems can be problematic.

What's wrong with 52 clones? That's not a large number.

This is very useful behavior, as it simplifies initialization code quite a lot, and eliminates almost all worries about "who starts first" among communicating modules. I have a similar feature in Messenger Library; I call it a "State Notification" as distinct from an "Event Notification", as the type of data where one needs the most recent value is state data.

I've never even tried them on an debugged executable. But it is likely the same issue that causes crashes on RT: use of a pane resize event to detect when the User resizes the probe. I now conditionally disable that on RT. I'll investigate when I get a chance.

I'm afraid I have no answer as how to test actual UI code, other than an actual set of tests done by a person. That is quite a big problem. However, I commonly do have business logic in some kind of subVI or class method, and that can be unit tested. So for example, I can test if the "Save Data" and "Load Data" methods properly write/read the data, but I can't test if the "Save" and "Load" Menu items actually call those method correctly. One can, though, test the message-interaction of an actor in a Unit Test. And one can use Queries to help do this quite easily, even if the actor, in actual use, is interacting much more asynchronously. Below is a part of such a test of a ModbusTCP Server. I included a diagram of the actor interactions at top (a secondary value of unit tests is that they allow one to demonstrate the use of a component in a simplified setup). Note that I quickly made a simple message loop to stand in for the "Device", needed to handle some of the commands sent over Modbus (the actual actor that is the Device in the application is much more complicated). Not shown, off the bottom of the screen, I use the Plasmionique Modbus Library as a test Modbus client to run a series of communication tests with the server. Note, though that this is an example of an Actor that involves no UI at all. If it had UI elements, I could not test that automatically.

Do you have the Desktop Execution Trace utility? The first thing I would do if I had an out-of-memory would be to use this to look for "leaked" references. I once had a failure after 4 weeks of running that was caused by an unclosed .NET reference in a once-a-second loop.

Thanks Elmar. Issue 27.

Just several seconds, but with fewer actors. I will try and investigate when I next see it.

I have noticed that, though not enough to bother me much. I've assumed it was a LabVIEW bug in the edit environment. I haven't investigated it because it can't affect executables (they only run once). BTW, is that 60 actor types, or 60 running instances?

Can you explain your use case, and why the public API is inadequate for it?

Hi Osamu, This is not an Actor Framework thing. "Actor" is a computer-science term that is used by dozens of frameworks it multiple languages. This example uses "Messenger Library", available on the LabVIEW Tools Network or here on LAVA.

Here's a minirant to NI I made in May: Rounded corners on icons could be useful, if it indicates something, but rounding every single graphic element is silly.

That was my impression; changing everything for no good reason rather than retaining continuity with the past but changing a few keys things where there is real benefit.

They need a killer feature, some great thing not in regular LabVIEW. So far I haven't identified such a feature.

You're a bit late for this conversation, though the topic is still very relevant today.

Tried inserting png, jpg, and bmp images (by solution 1) and they can be viewed by SQLite Expert Personal, which I use.

I think your issue is the multitudes of "image" formats. There are many formats, and many conversion functions, and it is difficult to get things to work by trial and error. The webpage for "SQLite Administrator" indicates it understands JPG format, yet your attached code is converting from JPG to a LabVIEW-only flattened image format. You need to read that JPG image into a LabVIEW string, without converting it into some other format, and insert it. Look into the "Read form binary file"... (I see smithd has beaten me to it).

"Seems not to work" is the vagueous description you could give, but I wonder why you aren't just saving your bmp image as a blob, rather than turning it into a LabVIEW image format (and then only storing part of that).