Style Question

[rharmon@sandia.gov]

I'm writing software for a laser energy meter. I need to write custom software for two reasons. I need to ensure the energy sensors are always setup the same way, and I need to collect the data in a specific way. That said I have a style question for all you labview pros...

 

The sensors allow me to query the current settings and modify the settings. There are about 11 configurable settings, but not all settings are available on all sensors.

 

When configuring the meter for the attached sensors would you:

 

1. Query the sensor and only modify the setting that are available on this sensor. Or just deal with the errors created when attempting to change a setting that is not available on a specific sensor..

 

2. Query the sensor and only modify the setting if the setting is to change.

 

3. Just change all the setting on the sensor wether they need to change or not.

 

Or would you take an entirely different tack?

[ensegre]

(3 implies 1b or?)

 

I think the answer is in part subjective (how much extra time would you spend for a diligent implementation?), in part dictated by constraints you don't specify. Like:

• Setting an unnecessary parameter causes an additional delay? Uses up some communication bandwidth?
• How are the capabilities of the sensors queried, or otherwise known? Does that take time or bandwidth?
• Is it safer to query always, because a sensor may have been changed without the caller knowing it?
• Are there risks connected with trying to set an unsupported parameter?
• In 1b the error is propagated elsewhere as error, or is just the sensor answering "sorry, I can't"? Squelching the 1b errors incurs in the risk of neglecting other real errors?

[rharmon@sandia.gov]

Time spent for a diligent implementation is important in the short term, but long term I think time spent up front almost always pays off.

There is not a timeout for setting an unnnecessary capability. that said there is of course some small about of bandwidth used.

I'm not aware of any risks trying to set an unsupported parameter

Good point on the error handling, squelching the errors may infact allow an important real error to be lost.

 

Thanks for the thoughts...

[ShaunR]

You are not really talking about "Style", rather "State".

 

There are two basic schools of thought. Try to keep state locally in a model or let the device keep the state. The former is fast but more error prone (desynchronisation between your model and the actual device) while the latter is slower but more robust and easier to recover.

 

There are also shades in between the two which tend to be dependent on the device itself. If a device has multiple programmable config memories then a single command to switch recipes and read a value continuously may be needed (e.g. motors with profiles). If you have 1,000 UI controls to turn an LED on, then you may have to selectively see what the user has changed and send the command appropriately and hope they didn't press the reset button on the device.

 

My preference is device 1st, local model 2nd (when performance becomes an issue). This is mainly because you usually end up re-inventing the wheel, that is, recreating the logic of the device firmware in a local model and some of them can be very complicated indeed. Some devices even have their own controllers so it becomes more of a distributed control system. Then I like to chop the hands off of operators and leverage advanced features of the device for configuration (recipes) if it has any.

Edited March 17, 2016 by ShaunR

[smithd]

For the state part of the question:

It also depends on how likely it is for someone to change settings from a different console. I've worked primarily on applications where this is a risk (HMI1 and HMI2 can both read from and change settings on DeviceA). As such, I tend to favor always always always storing the model on the device. HMI1 says "here is the settings I think you should have" and then DeviceA takes those settings and configures any attached devices appropriately. Ideally, you'd have some sort of subscription mechanism set up so that HMI2 knows HMI1 made a change, but...

 

This changes entirely in situations where a device talks to 1 and only 1 master (ie a cRIO configuring an embedded sensor). In this case I think its perfectly justified to maintain a local memory on the cRIO if there are performance concerns. I'd still tend towards letting the sensor maintain its own state, but for values which are accessed frequently caching makes sense.

 

For the energy meter situation, I'm guessing you configure it once on boot before you start running the system and then rarely touch it again. If that guess is right, I wouldn't bother with caching -- just always send the new cfg to the device.

 

However, I do think there is a design question in there (item 1):

How does your application distinguish between sensor types? If you have one big cluster with settings A,B,C,D,E, and F, and some sensors ignore F while others ignore C, you're left with a few questions:

-How advanced is your user? If you just ignore errors for settings that don't exist, will the user understand why the setting wasn't implemented as they expect? If so, I'd just send everything and let the sensor sort it out.

-If the user isn't advanced, how do you display different configuration screens to them...because if you have different configuration screens, then your application could simply not send settings that don't make sense for that sensor.

[drjdpowell]

Do you have specifications for the different types of units?  If so, you can query the unit for its type then load something specific to this type.   Could be a special INI file for each type, or a child class if you are using LVOOP.  The file/class would specify what settings are available.

 

Are you testing these units, or just using them?   With testing you should test to the spec, not query the unit for what it can do.  Otherwise you won’t catch a unit that fails to support a setting that it actually should.

[rharmon@sandia.gov]

Thank you all for the information. I truly appreciate the thoughts.

 

I've written several instrument drivers in the past, but most of the time i'm rushed to get the product out and don't spend the proper time on development. That has come back to haunt me in the past. That said I don't want to waste time (my todo list is always several pages long).

 

This paticular instrument allows me to querry the energy sensor for what parameters are available to be modified, and what the acceptable values are. That allows me to set up the user interface configuration vi for each sensor. That makes adjusting parameters by the user easy from within the software. However I'm using a text based configuration file that users could modify a value that is not supported by a sonsor. Most of the time users are not going to modify a setup configuration file... But they have been know to play around!!! So just ignoring an error message, or correcting it before the user sees it is a bad idea...

 

I'm using Messanger Library, but I'm a baby LVOOP user. a child class is probably a great idea but since the sensor can tell me what parameters are available I think that is the way to go. Although branching out a bit in LVOOP would be very beneficial to me... We're talking baby steps here.

 

So again I want to thank your all for your thoughts... It has been very good for me to see from what angles you guys attack these issues...