Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 10 Jun 1997 11:54:07 -0600

William,

> You wrote:
> > The values are saved in the monitor queue only if the native 
> > database type of the field isn't string, and only if the native
database
> > element count is one (scalar). This is independent of the
> > DBR type used by the CA client.
> 
> Sorry. I'm confused here. I obviously jumped to the wrong conclusion
based
> on the following behavior:
> 

It turns out that some confusing (and incorrect) behavior is occurring. 
See below.

> I have a bo with ZSTR and OSTR set to NO and YES. When I set it to 1, a
> sequencer immediately resets it to 0. Hence two monitors are posted in
> rapid succession.
> 
> Here's what camonitor sees (always requests DBR_STRING):
> 
> hana:~ 688: camonitor k0:ao:sc:init
>  k0:ao:sc:init                  06/09/97 08:27:27.380 NO 
>  k0:ao:sc:init                  06/09/97 08:30:23.950 NO 
>  k0:ao:sc:init                  06/09/97 08:30:23.955 NO 
> 
> Here's what cau sees (always requests native type):
> 
> hana:~ 689: cau
>   cau:  monitor k0:ao:sc:init
>   cau:
>        k0:ao:sc:init 08:30:23.955           NO
>        k0:ao:sc:init 08:30:53.930          YES
>        k0:ao:sc:init 08:30:53.935           NO
> 

It does appear to work that way here also. This _is_ surprising 
behavior when you are attached to the .VAl field of a bo.
After closer inspection I discovered that the get_enum_str() entry point
in the bo record is not using the field pointed to by paddr. Instead it
always uses the val field. I would classify this behavior as a bug for the 
following reasons:

1) If another field in the bo record is of type dbr_enum and a client
fetches it as a string then it will receive the value of the wrong field.
Even if there isn't another field of type dbr_enum, we know that
new records are created by copying records in base and we dont
want to encourage this practice.

2) The dbr_enum values stored in the CA monitor value queue
are not used (because pfield is pointing at the monitor queue and 
not at the database)

Here is the code in question:

static long get_enum_str(paddr,pstring)
    struct dbAddr *paddr;
    char	  *pstring;
{
    struct boRecord	*pbo=(struct boRecord *)paddr->precord;

    if(pbo->val==0) {
	strncpy(pstring,pbo->znam,sizeof(pbo->znam));
	pstring[sizeof(pbo->znam)] = 0;
    } else if(pbo->val==1) {
	strncpy(pstring,pbo->onam,sizeof(pbo->onam));
	pstring[sizeof(pbo->onam)] = 0;
    } else {
	strcpy(pstring,"Illegal_Value");
    }
    return(0);
}

It appears that the bo record's put_enum_str() routine has the
same problem. Someone needs to go through all of the records in 
base and fix all problems of this type.

Jeff

PS:

Watch out for situations where several ca_put() requests occur while the
record is being processed. In this situation you can only assume that the 
record will be reprocessed for the last ca_put() requests that arrives from
any client while the record is being processed. The call ca_put_callback() 
can be used if you want every put to result in the record being processed.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System