Experimental Physics and
Industrial Control System

"Liu, Gongfa" <[email protected]> · Fri, 23 Nov 2007 16:41:12 +0100

Hi, Andrew,

Andrew Johnson wrote:

**************
Modified
**************

# source files
(1) base-3.14.9/src/db/dbAccess.c
    dbPutSpecial() is added for CCE. This function is just a pipe to
    call the static function putSpecial(). dbPutSpecial() is written
    by John L. Dalesio and Bernd Schoeneburg originally.

Rather than add a new function, rename the existing static
putSpecial() function to dbPutSpecial() and remove the static
keyword.  All callers to the static putSpecial() routine are local to
this source file.

Yes, it's better.

(2) base-3.14.9/src/db/dbScan.c
    Register periodic scan tasks at RMT. When the IOC is SLAVE, these
    tasks are changed to be inactive.

The #ifndef vxWorks block will not be accepted.

We will remove this block and change the relevant codes.

The changes here that provide the ability to stop periodic scan tasks
represent functionality that should be part of Base, although I may
want to change their implementation somewhat.

The code that registers the periodic scan tasks with the RMT should be
replaced with a call through a global function pointer that the RMT
initialization code can set before iocInit().  By removing any need
for the scan code to perform the registration itself this also drops
the requirement for epicsFindSymbol() and for the rmtDrvIf.h header to
be included in Base.

See comments for Redundancy Patch: rsrv

(3) base-3.14.9/src/dbStatic/dbBase.h
    enum type "redUp" and the element of struct dbFldDes "red_update"
    are added for CCE. They are added by Bernd Schoeneburg originally.

(4) base-3.14.9/src/dbStatic/dbLexRoutines.c
    Deal with pdbFldDes->red_update for CCE, by Bernd Schoeneburg
    originally.

This change adds 2 bytes to the field description structure of every

field of every record type in every IOC (that's about 1.7 KBytes for all

the record types in Base, which will be completely wasted on IOCs that

are not redundant) and provides the means for these values to be set

from the DBD file that defines the record type. We might want to

include a switch in the site configuration to turn on/off whether this

structure should include the red_update field.

I note that you did not include any modified record.dbd files; was that

an oversight, or do redundant IOCs have to use a completely different

set of record types? If you have to add a redUp() line to any of the

base record.dbd files then those changes need to go into Base too — you

should never use a record.dbd file in an IOC if a different record.dbd

file was used to generate the record.h file.

This additional property of fields is dedicated to control the updating

of the slave IOC. Up to now we have done only some tests but do not

really know which fields are not to be updated. It is built-in that

fields which have NO_ACCESS set are not updated. Fields which are links

are updated only, if the update-mode is selected to be “Full” in the RMT

settings.

The set of record types is of course same as non-redundant IOCs. If the

red_update property is not specified, the default “RED_CONT_UPDATE” applies.

If the overhead of this feature is too big for some small systems a

compilation switch would be a solution. If a site has no problems with

memory in the IOCs, then the binaries compiled with the switch set, can

be used for redundant as well as non-redundant IOCs. If redundancy is

not needed, the switch can be left off.

In future, when we and others have learned which fields of the records

must not be updated between the redundant IOC nodes, the dbd-files must

be changed. The dbd-files can be the same for all because the additional

text inside will be ignored if the parser in dbLexRoutines has no

information about “red_update”. When the dbd-files are modified these

dbd-changes have to become part of the base of course.

**************
Added
**************
(1) base-3.14.9/src/db/rmtDrvIf.h
    The head file for RMT driver interface.

This header is not required if the task registration code is moved into

the redundancy application and hooked into the IOC by setting a global

function pointer before iocInit(). In any case it also appears in the

rsrv patch; only one instance of any header file should be included.

Yes.

- Andrew

Bernd Schoeneburg and Gongfa Liu
--
----------------------------------------------------------
Gongfa Liu                         MKS-2, DESY
phone:  +49-40-8998-1642           Notkestr. 85
fax:    +49-40-8998-4388           22607 Hamburg
e-mail: [email protected]         Germany
----------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System