drjdpowell

FYI, the DEV template is designed to be able to handle simple Events very quickly and easily, just like a more simpler Event-Structure loop. The follow-on actions output from the Event Structure is set to "use default if unwired", and the default action is just the error handler (and message reply). The "Next Action" and "Reply" subVIs that must execute are performance optimised to add negligible overhead in the default case of no actions and no message to reply to.

Can I encourage you have another look at the DEV template? You seem to have taken the DEV template and deleted the entire "Follow-on Action" handler, and are now trying to reinvent some of the very features you just deleted. At the very least, don't delete the error-handling case which already makes a Notification of any error. Have you seen the Youtube instructional videos on Messenger Library? The DEV template looks complicated, but is designed to support both high-performance use, like a simple Event-structure (with error handling) and more complex use, like a JKI State Machine. Since even simply-running things often require complex initialisation operations, I would suggest that starting with a "simpler" structure will led to less simple real-world programs.

What JSON file are you using? You've just given me a VI that expects JSON, and a YAML file. I note that your YAML contains no arrays, yet your JSONpaths treat "Configuration" as an array.

Different applications can have different config needs. In fact, a single app can have multiple different needs requiring different styles and thus different config files. So it is hard to give general advice other than "JSON is flexible and easy". Re your questions: 1) saving and loading files isn't complicated, so I've never seen value in a separate "config" actor. 2) I usually use just "LabVIEW Data", but see also this blog post. 3) I've done similar systems. Here configuring the system involves reading (from the config file) what actors are needed and launching them before sending them there config subJSON. This can involve dynamic loading of the actor class (from the lvclass name in the file). Your max of 96 messages second doesn't sound that much to me. Using a standard message will be simpler. But this is something you should test as soon as possible. It is ok to introduce something more complex if needed, but only if needed.

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?