Data Access on the cheap and easy

torekp · December 4, 2014

First off, thank all y'all for schooling me on Data Access Best Practices and FGVs, Action Engines and DVRs. Now let's dumb it down a bit. I want to ask about good(?) old-fashioned native Labview globals.

Here's a use case: A control program for an industrial process has 10-20 adjustable parameters (numerics and booleans) on its GUI. These parameters are written once at program start based on values in an INI file, and then an arbitrary number of times thereafter when the user changes them. It is not critical for the process to update the user-changed value at the exact millisecond. So: globals? Or what?

How lazy can I be, before the expected value of time and effort goes negative? Let's assume that the control program is subject to revisions such as adding more adjustable parameters. The additional parameters could represent new hardware that has been added, or simply taking advantage of more functions (that we had thought we could just set and forget) of existing hardware.

smithd · December 4, 2014

I'm somewhat biased but I'd use CVT (https://decibel.ni.com/content/docs/DOC-36858) or any of the numerous similar tools out in the world for that. Since the number and composition of the variables can also be loaded from the file alongside the data, it makes it easy to add new fields. Performance is slightly slower than a global, but not by all that much. Plus we already have a nice-ish library for copying data across the network so an HMI can update it (https://decibel.ni.com/content/docs/DOC-37226).

I'd use a global if the data I'm changing were more fixed, like a stop (except I'd use notifiers for that) or maybe some timing information.

For your specific situation, where the count is small and timing is really not critical, honestly shared variables would probably be OK. Probably. SVs can also be referenced programmatically, so all you'd need is some VI that reads your INI file, translates the token names into variable names, and writes the appropriate value into the SV.

crossrulz · December 4, 2014

I would also go the CVT route here. The API is really good and quite simple to use once it is set up. It allows for the application growth a lot more than using globals for a very small performance hit.

infinitenothing · December 4, 2014

It's really a risk calculation. You have to anticipate what are the odds that down the road you'll want some feature (programmatic access? in place editing?) that globals can't easily provide. If you think you have a 10% chance you'll need that and it would take your 40 hours to pull out all your global and put in a better data type, you'd need to save 4 hours of development time to justify using a global. Maybe you should put in a fudge factor for unknown unknowns. So you'll want to save 40 hours of dev time to justify their use.

smithd · December 4, 2014

It's really a risk calculation. You have to anticipate what are the odds that down the road you'll want some feature (programmatic access? in place editing?) that globals can't easily provide. If you think you have a 10% chance you'll need that and it would take your 40 hours to pull out all your global and put in a better data type, you'd need to save 4 hours of development time to justify using a global. Maybe you should put in a fudge factor for unknown unknowns. So you'll want to save 40 hours of dev time to justify their use.

For the use he described, what would be the superior alternative? I'm on board with what you're saying, generally, but in this case...

torekp · December 4, 2014

Thanks for the input. I already had installed CVT from reading those threads I mentioned, but I did not think to use it for this relatively simple case. Now that I'm looking at it, it does seem very easy to use. The only downside is the XML files. Usually I put my initialization info into an MGI_Read_Anything type file. The MGI format is much easier for a non-programmer to read (and modify).

The obvious solution is, I could write a few little VIs to use the MGI format. I think I will.

torekp · December 4, 2014

That was easy.

(Attachments are Labview 2011; dependencies: MGI Read/Write Anything. Also attached: XML and MGI-formatted files for comparison; I had to rename them in order to attach them.)

smithd · December 5, 2014

Yeah, XML was just a convenience but for some reason a lot of people get hung up on that. Sometimes I think it would have been better to include no serialization at all. I don't think I've ever used the XML format for anything. If I were selecting all over again in 2013, I'd pick the json parser instead (even if it is a bit of a pain to use for no real reason <_<).

Anyway, the MGI files look nice, simple enough format. Good luck with the rest of the CVT.