drjdpowell

I know nothing about ARP, but why would this come instead of a UDP packet?

You can either use a transparent PNG (there is one in "<vi.lib>\JDP Science\Flatline Controls\Transparencies\Full Transparent.png") which, strangely, is not the same as colouring something transparent. But the best option, if you don't want the User to be able to click on those arrows, is just to make them very small and hide them behind the main body of the slider.

I investigated, and it is because you made the two incr/decr arrows transparent. I've had suspicions in the past that there is something buggy about colouring things transparent.

If you replace with an unmodified slider direct from Flatline does the problem come back?

BTW, the VIMs in JSONtext are all simple wrappers to make the API easier; you can use the Variant conversion functions available under the "more" menu to avoid all VIMs if needed.

That's inherited from the NI JSON function, which I used for fast array parsing. I may have to spend the effort to develop and alternate solution, or develope better guards for corner cases.. There are a lot of edge cases mapping LabVIEW's strict types to JSON.

Pretty Print is designed to keep small objects compact. Anything less than 40 characters. I think it's more readable, especially for arrays of small clusters.

Are you using 2018SP1f1? This sounds like the horrible compile bug present in 2018 before SP1f1 that tended to hit VIMs heavily (CAR 715018). The f1 patch fixed this.

You could consider a JSON header, followed by binary data. I strongly suspect the float representation in both languages is identical: IEEE standard.

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?