mp49 / parker6k

EPICS support for the Parker 6K controller
1 stars 2 forks source link

Cannot enable TLIM polling on IOC start #9

Closed mark0n closed 10 years ago

mark0n commented 10 years ago

For some reason enabling TLIM polling on IOC start does not work for me. Here is what I have in my DB:

record(bo, "$(PREFIX):motorRadPistonEnableTLIM")
{
   field(PINI, "YES")
   field(DTYP, "asynInt32")
   field(OUT,  "@asyn(ParkerGT6Krad, 0, 1)P6K_C_TLIM_ENABLE")
   field(ZNAM, "No")
   field(ONAM, "Yes")
   field(VAL,  "1")
}

The record's status after IOC boot is:

epics> dbpr SFTB:motorRadPistonEnableTLIM 4
ACKS: NO_ALARM      ACKT: YES           ASG:                ASP: (nil)          
BKPT: 00            COSV: NO_ALARM      DESC:               DISA: 0             
DISP: 0             DISS: NO_ALARM      DISV: 1             DOL:CONSTANT        
DPVT: 0xa3a450      DSET: 0x7f80ed256e60                    DTYP: asynInt32     
EVNT: 0             FLNK:CONSTANT 0     HIGH: 0             
IVOA: Continue normally                 IVOV: 0             LALM: 0             
LCNT: 0             LSET: 0xa3d2e0      MASK: 0             
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00               
MLOK: e0 0f a3 00 00 00 00 00           MLST: 0             
NAME: SFTB:motorRadPistonEnableTLIM     NSEV: NO_ALARM      NSTA: NO_ALARM      
OMSL: supervisory   ONAM: Yes           ORAW: 0             ORBV: 0             
OSV: NO_ALARM       OUT:INST_IO @asyn(ParkerGT6Krad, 0, 1)P6K_C_TLIM_ENABLE     
PACT: 0             PHAS: 0             PINI: YES           PPN: (nil)          
PPNR: (nil)         PRIO: LOW           PROC: 0             PUTF: 0             
RBV: 0              RDES: 0x988fc0      RPRO: 0             RPVT: 0xa39e40      
RSET: 0x7f80ec51b7e0                    RVAL: 0             SCAN: Passive       
SDIS:CONSTANT       SEVR: NO_ALARM      SIML:CONSTANT       SIMM: NO            
SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: (nil)         STAT: NO_ALARM      
TIME: 2014-11-14 09:07:17.048122343     TPRO: 0             TSE: 0              
TSEL:CONSTANT       UDF: 0              VAL: 0              WDPT: (nil)         
ZNAM: No            ZSV: NO_ALARM

So it did process but it has a wrong value. Sniffing the connection to the controller I cannot see any TLIM commands, though. A caput with value "1" to this record at a later point in time works, though.

When I remove the PINI field from the record I get TIME which means the record never processed. But the VAL field is 0. Does the device support overwrite this value (maybe using the state of the controller object) on IOC start? Doing the same without setting DTYP and OUT works as expected (VAL==1)

mp49 commented 10 years ago

Yes, the asyn device support overwrites the default record value at iocInit. It's because I'm setting a default value in the controller constructor, like:

setIntegerParam(P6K_C_TLIMEnable, 0)

Using autosave on TLIM will solve it.

I could take a different approach and not initialize the parameters in the driver, which would allow setting default parameters via the database. But then my code relies on a database being there, otherwise I'm reading uninitialized values from the parameter list.

mp49 commented 10 years ago

It's probably best if I only initialize read-only database parameters. Then I let the database set the default value for the read/write params. Sounds ok?

mark0n commented 10 years ago

I still don't understand why initialization in p6kController::p6kController(...) does overwrite values set by records with PINI==YES. Isn't the constructor called before the record processes the first time?

mp49 commented 10 years ago

The constructor is called first yes, then the record is initialized during iocInit. Then in the asyn device support it decides to take the value from the driver as the correct value, rather than the database value. I guess it's an asyn design decision, but I've haven't looked into it that much.

There's a comment about it in one of the areaDetector base classes, about not setting default values for read/write parameters, which is why I think I should be doing that in the motor driver too.

mark0n commented 10 years ago

I see. AFAIK I do not use any of the other read/write parameters. Removing the init line fixes my problem. So I think you can go ahead and remove them.

mp49 commented 10 years ago

I removed some of the lines in the constructor that initialized parameters that should have default values in the database.