Shared variables are deliberately crippled

[Andromeda]

One of the nice features in the last few versions of LabVIEW is the Shared Variable. Unlike global variables, they can be programmatically created, which would appear to open up a range of new applications for LabVIEW.

Unfortunately, they cannot be assigned default values unless the customer purchases the onerously expensive DSC module. Making matters worse, there is a run-time license associated with distributed copies of an application which uses the DSC.

Naturally, this severely limits the usefulness of shared variables.

This is not the first time that we have seen NI take a key feature which a customer would expect to be part of the PDS, and put it into an optional module. I'm sure that this is intended to “encourage” customers to purchase optional modules.

Our corporate experience has been the opposite - we have seen one of our clients blacklist NI as a supplier, after they were burned by another instance of NI's callous feature bundling.

[altenbach]

Instead of composing a clear idea, you break out in a tirade. You need to be a bit more constructive! 🙂

So: What's the idea you want implemented???

[Andromeda]

Your point is well taken. I had originally intended to submit this to the product suggestion center, but NI has shut it down, in favour of the idea exchange (the old link to the product suggestion center now points to the idea exchange), and I was unable to find a more suitable home for my comments).

Rephrased as a suggestion, it would be to add shared variable initialization to the PDS or the developer suite, as it is a general purpose feature, more than part of datalogging or supervisory control.

Is this a tirade? To a certain extent, I'm afraid that it is the voice of frustration.

[viScience]

Just curious,  what is so special about being able to set a default value for a NSV?  In my case,  I programmatically set all NSV's to a known value via the SV API.

[Andromeda]

Thanks for your comment.

Shared variables are often thought of as being like a global variable, only better. Not only is there a mechanism for sharing data values over a network connection, but even single process shared variables tantalizes us by almost providing a mechanism for attaching properties (often called metadata) to a variable. For reasons which I'll elaborate on a bit later, I see this as being desirable. The version of shared variables which ships with the developer suite allows you to attach name, type, and description properties. Conspicuously absent is a default value property.  Other properties, such as alarming limits, I can see as belonging to the DSC module.

Global variables also have a number of desirable attributes, but their use is often discouraged, because the LabVIEW compiler still cannot generate code to read global variables without incurring the overhead of a data copy (the reasons for this have been documented elsewhere).

One of the desirable attributes of a global variable, is the ability to assign default values. The mechanism is so intuitive for end users, that it can often be used to store semi-static information in a way which our customers can modify themselves when necessary.

It's certainly possible to add configuration files & routines to initialize all global/shared variables, but in large applications, this can make the configuration files unnecessarily complex.

In order for shared variables to supplant the need for global variables, I would argue that they should be able to function as first class replacements for global variables. The two areas in which they currently do not, I believe, are inspection and default value assignment.

Safe default variables are desirable in any programming language, if only as a safeguard against failure of the configuration mechanism. So, even if we plan to assign a value to a data item as part of application initialization, our application should not fail if the configuration mechanism fails. Here I would argue that the default values of zero for numerics, and empty strings for text fields, are not sufficient.

As an example of where we might want to assign initial data identifiers and default values, let's imagine that we wish to communicate with an instrument from which we can extract several hundred, or perhaps several thousand data items, using a simple protocol such as Modbus.

For each data item, there are some properties which we need to keep track of. The volatility of these properties differs. Most constant is a token to refer to the data item, which we can pass the the various data handlers in our application. Other information is almost as constant: some datatype information, a register number or other access key, and probably some descriptive information. Some properties are dynamic, like the current or historical values of each data item.

Before shared variables, a common way to handle this was with global variables. Each variable could be a cluster in which some of the elements had default values. When the application wanted to get a fresh value for one of these variable, it could pass an array of these clusters to a communications VI, which would in turn examine each cluster to determine the register number, data type, etc, and replace the current value element of each cluster after obtaining it.

In this kind of application, the overhead incurred by having to make copies of the global variables in order to read them is mitigated by the encapsulation of all the properties of a variable into a something which could be passed around easily. This is where I see metadata as being significant, and desirable for all data elements. LabVIEW's class mechanism would seem to be a natural fit, but it is still fairly limited, and is almost impossible for end users to maintain.

With shared variables, the variable names and some of the attributes can be set programatically; a task which only has to be performed when major configuration changes are made. With the unfortunate omission of the ability to set default values to properties, a second pass is necessary every time the application initializes, which will set default values. It's clumsy, and breaks what should be an atomic operation into two parts. What's galling, is that the omission is driven not by engineering necessity, but by marketing.

[viScience]

I certainly agree that the cost of the DSC module is prohibitive and for those of us that would just like a few basic features like default values or SV value change events I do not think it should be so expensive.  But in your case, I think you can do without the DSC if you can get over your prejudice on the use of configuration files.  In my case I use excel to create some very user friendly workbooks that specify everything about the system (Channel Names, Physical IO mapping, Scaling, Initial Values, Zero Offsets, Filtering, Deadbanding, Comments, etc)  these XLS files get compiled down to a GXML equivalent that is essentially an array of clusters of 2D arrays of strings which maps directly to the excel workbook metaphor.  I have vi's that manage these GXML files deploying and parsing on RT as well as windows targets.   I consider an RT targets ability to load a GXML config file to be an essential part of its initalization.  Initilization failure as well as many 'health' monitoring mechanisms can place the RT system in a fault state.  This state commands all outputs to a known safe state and is broadcast as a syslog event as well as a RT scan engine fault that is visible from my HMI's and the Distributed System Manager.  I also have tools that allow a user to view and deploy on the fly changes to the configuration files.

[Andromeda]

Thanks for your thoughts. They are particularly apropos, as they came just as I was deciding whether to make the configuration files for this application be XML files, or whether to parse an Excel workbook!

Excel files are easier for our users to configure, but have nothing by way of validation other than programatic parsing at run time. XML files have the advantages of structure, XSLTs, and schema validation. You've taken a nice approach by combing the two, which I like.

I don't mind configuration files, but I prefer to define the relatively non-volatile parts of a configuration separately from the more volatile aspects. So, for instance, I prefer to define and deploy shared variables in a relatively static way, since programatically creating, deploying, and destroying shared variables each time an application runs is fairly time consuming, and usually unnecessary.

I had mosty wanted to be able to initialize shared variables, so that I could impose some structure on them which would be persisent. So, each shared variable is a cluster. In each of those clusters there is an enumerated variable which specifies the type of the value property (it's more complicated than the standard LabVIEW types, so I can't rely on that bit of built-in functionality). This is part of the configuration which users should never see or touch, so I would have ideally defined it up-front along with other fairly static things like the name of the variable.

In the past, NI has occasionally kindly agreed to allow us to use small portions of an add-in toolkit for a project. Despite the helpful and good intentions of our sales reps, this hasn't always worked out as well as we had hoped, because our customers would keep running into difficulties with the license manager, which wants to be linked to one particular machine.

In this particular project, I could almost certainly justify the cost of the DSC, but I won't. Disregarding any personal feelings on my part, the addition of a licensed component to every run-time instance of this application, even if there were no cost involved, would burden deployment of the application to an unacceptable degree.

[viScience]

I do not really understand the value in making your SV's a custom datatype.  If you take the workbook approach then each target will have a GXML configuration file that gets loaded into memory and from where you can easily derive groups of data types (AI, AO, DI, DO) and then handle the processing uniquely, for example AI's have filtering.  In my case all my NSV libraries are predefined in the project and for HMI's are deployed as part of the exe.  For RT targets, this is not possible so they have to be manually deployed from the project but images of the RT targets are maintained and put into SCC so that targets can be reimaged easily without the LV development tools.  Here is a screenshot of one of my configuration worksheets.  I have some simple tools that I could share with you that parse into GXML and compile into searchable channel groups.

[Andromeda]

Thanks for the offer!

Not surprisingly, your configuration spreadsheets look very similar to mine. I have a bit of extra information which is related to the way live variables are retrieved from a remote computer (data type, access level, Modbus register, etc.), but they are otherwise almost twins.

So I'm curious about how you store all of the information related to a particular tag. I store everything in a cluster which is the custom type of the NSV, so it's all available either programatically, or by dragging the NSV to a block diagarm. How do you store the properties for each tag?

[SteveChandler]

Default values would be nice but my only use for DSC would be shared variable value changed events. I don't use shared variables for anything but I sure would if I could trigger an event off of them. I can not justify buying DSC just for that.

Maybe off topic but not by far.

[Andromeda]

I agree that this would be a useful addition to the base functionality, although it's easy enough to create a polling loop which checks for value changes and generates suitable events.

I suspect that it would be in NI's best interests to take things like initial value creation, event generation, and any other features which are general-purpose in nature, and move them out of the optional cost model.

When I look at LabVIEW at a developer, even though I've been using LabVIEW for over 20 years, I also have to consider alternatives such as Java, C#, or C++. Here I see NI's business model putting them in danger of having LabVIEW customers adopt alternative technologies.

If NI is using a marginal cost model to make decisions about whether to try to push customers to added cost products such as DSC, I would suggest that they may be falling into the common trap of assuming that customer purchasing decisions follow a linear cost-benefit model. In fact, we have seen any number of instances where this is not the case. Once a customer moves from LabVIEW to an alternative platform, a linear drop in NI prices will not produce a corresponding increase in sales revenue from that customer - it will take something dramatic to bring that customer back to LabVIEW.

I suppose that there is an alternative explaination for a policy which seems to be intended to push customers toward added-cost modules, at the potential cost of annoying existing LabVIEW developers. If NI believes that LabVIEW's heyday is more in the past than in the future, it might be that NI is trying to maximize LabVIEW revenue before it is superceeded by other technologies. As a long time LabVIEW developer, I would be sorry to see it decline, but I have to acknowledge that other development technologies are eroding what was once a huge gap between LabVIEW and everything else.