Experimental Physics and
| |||||||||||||||
|
The opc-callback handler - the "hardware access" - reads the hardware (the hardware is here a class that implements an OPC client), writes the data to VAL/RVAL field and initialises an epics callback: hwClass::HwCallbackHandler(void) { if( recDpvt->isCallback ) // for out-records and in-records with SCAN="I/O Intr" { readHw(); // read value if( recDpvt->isOutRecord ) // out-records are SCAN="passive" so scanIoRequest doesn't work { recDpvts->noOut=1; //prevent write value back to HW and cause a infinite loop callbackRequest(&(recDpvt->callback) ); } else // in-records use scanIoRequest { scanIoRequest( recDpvt->ioscanpvt ); } } } The epics callback causes record processing: static void outRecordCallback(CALLBACK *pcallback) { dbCommon *prec; callbackGetUser(prec, pcallback); dbProcess(prec); } and the write hardware function cares to the noOut-flag long opcSetScalar(OpcToEpics * pOpc2epics) { if(recDpvt->noOut ) { pOpc2epics->noOut=0; return 0; } ..write hardware and return } if there is an attempt to write the hardware from both sides at the same time it may be undetermined which value is realy written, but is this avoidable if there are no priorities defined? I'm not shure if this is a good way to solve this problem because i'm not very familiar with epics internals, but it works. My code is divided in a devSup.c which does the record dependant stuff - DSET, init and io routines and mask/shift vfor mbb records - and supports all records that have an INP/OUT field and VAL/RVAL. There is a drv.cpp which handles the hardware/OPC side - and allows all C++ features :-). It is intended to be reused for other "hardware" as OPC only, so you could try to use it - if you are interested in. Gruessle Bernhard
| ||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |