Re: Initialising an ao record from a constant DOL

[Andrew Johnson <anj@aps.anl.gov>]

Bob Dalesio wrote:
> It could be made to work that way - but it doesn't work that way now. I 
> believe that the DOL field is ignored if it is a constant. It seems so 
> from what you've described.

Actually Bob, the code says you're wrong there, it probably changed since 
you wrote it.  This is from the AO's init_record routine (R3.13.x, but 
should be the same in R3.14.x):

    /* get the initial value if dol is a constant*/
    if (pao->dol.type == CONSTANT) {
	if(recGblInitConstantLink(&pao->dol,DBF_DOUBLE,&pao->val))
	    pao->udf = FALSE;
    }

However you erre right about it doing the read on initialization, and that 
gave me the hint to what I think is happening.  This code appears lower 
down in the same routine:

        status=(*pdset->init_record)(pao);
        switch(status){
        case(0): /* convert */
	    value = (double)pao->rval + (double)pao->roff;
	    if(pao->aslo!=0.0) value *= pao->aslo;
	    value += pao->aoff;
            if (pao->linr == menuConvertNO_CONVERSION){
		; /*do nothing*/
            }else if (pao->linr == menuConvertLINEAR){
                     value = value*pao->eslo + pao->eoff;
            }else{
                if(cvtRawToEngBpt(&value,pao->linr,pao->init,
			(void *)&pao->pbrk,&pao->lbrk)!=0) break;
            }
	    pao->val = value;
	    pao->udf=FALSE;
        break;
        case(2): /* no convert */
        break;

It looks to me like Pete's device support is returning a 0 from its 
init_record routine, when it should be returning a 2 as it hasn't properly 
set the RVAL field.

I think that explains the problem and where the correct solution needs to 
go - in ornlSerial.  I'd suggest checking all of its output device 
supports which I believe should all do the same thing.

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro