Experimental Physics and
Industrial Control System

Ned Arnold <[email protected]> · Thu, 30 Mar 2000 10:52:06 -0600 (CST)

> I've run into a strange problem with a database.  In working with the scan
> record, I need to have Wait records that poke the PROC field in the scan
> record.
> 
> When I do so directly with OUTN in the Wait record, it works as expected.
> If I forward link the Wait record through some other records to a CalcOut,
> all the intermediate records process successfully, but the Scan record does
> not respond when the CalcOut processes.  If I point the OUT field of that
> CalcOut at somewhere else, it behaves properly, so the problem seems
> somehow due to the Scan record.
> 
> The only difference I can see is the the OUT link in the Wait record is a
> dynamic link, while the CalcOut has a standard CA link. 
> 
> Why do they behave differently ?
> 
> ----
> Brian McAllister                 Application Programmer/Beam Physicist
> [email protected]                        MIT-Bates Linear Accelerator
> 

The short answer :

The WAIT record uses the equivalent of a channel access link (implemented in
recDynLink) when it processes the output link specified in the .OUTN field. 
The CALCOUT record uses a conventional link (DBF_OUTLINK) for its output 
PV (.OUT) which can be specified via the link attribute to be a database 
link (PP) or a channel access link (CA). Due to an inconsistent implementation
of the Forward Link concept in the SCAN record, a database link to the PROC
field of the SCAN record does NOT process the SCAN record (well, sometimes 
it does). To make the CALCOUT record work like the WAIT record, specify
a CA link in the .OUT field of the CALCOUT record .

       (e.g.  my_calcout_record.OUT = "my_scan_record.PROC CA NMS")

The long answer :

When the "put_notify" feature was added (which provides a callback to the
originator after an entire database chain has finished processing), a 
mechanism was needed for the chain to know when a record was completely 
finished with its processing (including any asynchronous device support). 
Since no one wanted to modify every record support module ever written, a
clever solution was to add this notification in the routine recGblFwdLink(),
which every <well-written> record already called when it was done processing.
The assumption was that the record support would call recGblFwdLink()
EVERY TIME it finished its processing.

When the SCAN record was written, the author decided that it made sense 
for the forward link to be processed only after the entire scan was finished.
This means the SCAN record gets processed hundreds of times during a scan
without ever calling recGblFwdLink(). This, of course, violates the assumption
made for the put_notify code. Therefore, database link requests to process
the SCAN record are ignored (until an entire SCAN finishes).

I still believe this is the best implementation of recGblFwdLink() for the 
SCAN record. If the SCAN record was part of a put_notify chain, you
would only want the chain to complete after the entire scan finished (which
would happen now). This, of course, inhibits the use of database links
to force the processing of the SCAN record at each point (as described above). 

Since there is a simple work around that mirrors the way the WAIT record did
it, I am inclined to leave things alone. 

As mentioned on this list before, Tim Mooney has re-written the SCAN record 
to take advantage of the put_notify concept. This eliminates the need for
CALCOUT records (or WAIT records) to determine when "positioners" are done
or "detectors" are finished acquiring. His code probably has more users
than the "base" SCAN record. If you are expecting to implement extensive 
scanning in an ioc, I would recommend Tim's version.

	Ned

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System