Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 03 Mar 2005 14:42:09 +0100

Benjamin Franksen wrote:
On Wednesday 23 February 2005 19:18, you wrote:

On Wednesday 23 February 2005 14:40, Marty Kraimer wrote:

Benjamin Franksen wrote:

On Wednesday 16 February 2005 20:42, Marty Kraimer wrote:

If all that is desired to to make the record not be in alarm
after initialization then just set
  field(SEVR,"NO_ALARM")
  field(STAT,"NO_ALARM")
  field(UDF,"0")
In the record instance definition.

And it did so because fields STAT and SEVR have no promptGroup
attributes, thus are not recognized as DCT fields and thus get
eliminated by dbDumpRecord from dbStaticLib. This routine has a 3rd
argument 'level', which is documented as follows
0 - write only prompt fields that are different from the default values
1 - write only the fields which are prompt fields
2 - write values of all fields
So there is no way to write all fields that that are different from the
default values, regardless of whether they are prompt fields or not.
Note that dbst is used to eliminate default values from the db file,
which is very useful for capfast generated db files. Thus, one cannot
use level=2 to circumvent this problem.
There are two solutions:
(1) Add promptGroup attributes to the field definitions of STAT and
SEVR, effectively making them into DCT fields.
(2) Split argument 'level' into two boolean arguments
'non_prompt_fields' and 'non_default_fields'. Or add a 4th level
3 - write values of all fields that are different from the default
values
I prefer solution (1), because it's the least intrusive and easy to
realize. I think we'll make this change locally.

I agree.

Adding promptGroup attributes would also make Marty's suggestion
available for users of vdct or similar tools, who due to the missing
promptGroup do not see STAT and SEVR as fields that can be set.

Generally spoken: Maybe every record field should get a promptGroup
attribute as long as it is not completely ignored at boot time. Not
commonly used fields could appear in a special group ("GUI_MISC"?) to
allow tools to hide them in a sub-menu.
Nevertheless - for dbStaticLib's dbDumpRecord() routine: Shouldn't
avoiding defaults and avoiding non-prompt fields be options that can be
set independently? As these two features of a record field are perefctly
orthogonal, it seems awkward that you're not able to set them
individually as dump filters.
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System