Experimental Physics and
Industrial Control System

Bernd Schoeneburg <[email protected]> · Tue, 08 Jul 2008 09:16:12 +0200

Hi Andrew,

I am sorry not having understood everything last time. You did a lot of

work again - examples also, thank you for that. The solution that you

have implemented looks very nice to me, because I do not like

conditional compilation as well. It took some time, but now I

understood your new taskwd functions. taskwdMonitorAdd gives a maximum

of flexibility for adding redundancy, error loggers, restarter and so

on. Now there will be no redundancy-dedicated code in base, thats fine.

The additional field attribute (copy to partner ioc: yes/no) is not

implemented in this way. I have no good idea how to decide this without

base modification.

The interface between Epics and the RMT will be in a separate module,

because RMT has no Epics calls inside.

Is it possible to control the ioc (redundancy status) by just using the

top level functions iocPause and iocRun?

Bernd

Andrew Johnson wrote:

Hi Bernd,

On Thursday 03 July 2008 09:01:13 Schoeneburg, Bernd wrote:

I want to remind you that we are highly interested in base modifications
for IOC redundancy.

As I have said to you before, the next release *will* allow you to implement

redundancy without modifying Base, although not using the patches that you

developed.

The proposed model gives maximal freedom of usage.

-- If the define (REDUNDANCY) is not done, Episc runs as usual and no
additional object code is loaded.

I am less worried about adding a small amount of additional code than I am of

getting the plug-in interface wrong. I do not like your conditional

compilation solution because it makes the result hard to test (you have to

completely rebuild Base with the conditional in the other state to be

completely sure it compiles properly), and it requires me to ship a copy of

your rmtDrvIf.h file with Base (which makes it hard for you to make any

changes to that file).

I am attaching a file which should become part of the Redundancy Monitor and

hooks into the interfaces I am providing. You won't be able to use this yet

because I haven't committed the parallel changes that are needed to Base, but

it shows you that it will be possible to make an IOC redundant without adding

more code to Base. This source code compiles without errors on my system,

although it won't link because I don't have the rmtRegister() routine or the

rest of the RMT subsystem. It is likely that you'll have to make some

changes, but I think the majority of this code is correct.

I accept that you need to be able to control some of the internal threads

inside the IOC, and as a result I am adding a series of 'xxxPause()'

and 'xxxRun()' routines to the various internal subsystems, as well as adding

top level 'iocBuild', 'iocPause' and 'iocRun' commands (in a redundant IOC

you will use 'iocBuild' instead of 'iocInit' in the startup script, ensuring

that the server and scan tasks are not started). While doing that I have

also been cleaning up the startup and shutdown procedure for the IOC, so

there is some advantage in this work for others as well.

After some more tests early next week, I will be committing my changes to CVS

and you'll be able to try them out.

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System