Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 28 Apr 2009 06:03:18 -0400

Tim,

Thanks for taking an interest in this thread. Your last message was

especially helpful.

Andrew Johnson wrote:

On Monday 27 April 2009 09:44:41 Marty Kraimer wrote:

Note that when the request was made to implement put notify I was
horrified about what this would  take to implement. It is really a mess.

Note also that mrkSoftTest/iocBoot/iocput tests put notify.

I don't think this has anything to do with putNotify, it's simpler than that.

I dont understand this comment. The putApp test does test putNotify for

both synchronous and asynchronous records.

However after actually testing out my patch (thanks to Tim for prompting some

particular experiments) I realize that as written it just allows infinite

loops to be made without the need for even asynchronous processing.

I can see that setting RPRO in dbPutField() is essential to ensure that an

external put to a record that is waiting for the second half of asynchronous

processing will cause the record to be processed again to handle the new

field value. However I'm having trouble understanding why dbPutLinkValue()

ever needs to set RPRO.

Given this database:

record(ao,"$(user):lo1")
{
    field(OUT,"$(user):lo2 PP")
    field(TPRO,1)
}
record(ao,"$(user):lo2")
{
    field(OUT,"$(user):lo1 PP")
    field(TPRO,1)
}

the existing code does this when I do a caput to anjHost:lo1:

CAS-client: Process anjHost:lo1
CAS-client: Process anjHost:lo2
scanOnce: Process anjHost:lo1
scanOnce: Process anjHost:lo2
scanOnce: Active anjHost:lo1

It's rather hard to explain why both records should process twice, but they do

because of the PUTF sets RPRO test in dbPutLinkValue().

Tim's last message explains the problem. Let me repeat what he said.

Consider the following.

record(ao,"recB")
{
   field(OUT,"recA PP")
   field(TPRO,1)
}

record(ao,"recA")
{
   field(OUT,"<hardware>")
   field(TPRO,1)
}

a) putNotify to recA.VAL
b)  recA.VAL converted to RVAL and asynchronous support starts
c)  putNotify to recB.VAL
d) recB,VAL is written to recA.VAL

Unless RPRO is set true the VAL field of recA will be out of sync with

the RVAL that is written to hardware.

Marty

 withCould it be something to do with preventing external interference in

processing inside the database? I guess if you had two records A (periodic)

which processes B (async), and the user pokes B directly, you'd want the

periodic scan to be able to reprocess B if the period arrives while B is

still busy.

This needs more thought, but that might explain why.  Got to go now,

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System