Experimental Physics and
Industrial Control System

[email protected] · Fri, 15 Jul 94 09:33:41 -0500

A bug exists in the binary output record that can cause momentary binary
outputs to fail for asynchronous records.

Let's briefly review momentary binary outputs. The HIGH field specifies the
number of seconds to hold the binary output high. What happens is that
when a 1 is written to the record  and the record processed then the
record processing routine schedules a callback HIGH seconds later. The
callback routine does the following:

    dbScanLock((struct dbCommon *)pbo);
    pbo->val = 0;
    dbProcess((struct dbCommon *)pbo);
    dbScanUnlock((struct dbCommon *)pbo);

Thus the output is left high for only HIGH seconds.

Now consider what happens if the record is asynchronous, e.g. a gpib binary
output. In this case the following sequence of events occur:

1) The value 1 is written to the record and the record starts  processing
   Record processing calls device support which queues a request to the device
   and tells record support that it has started asyn processing.
   The 1st phase of processing completes. Record is unlocked but active.
2) Some time later the asyn completion phase occurs. Device support is called.
   It just checks status of previous request it sent to device. NO NEW
   message is sent to device. Because the value is still 1 record
   processing schedules the callback to occure HIGH seconds later.
   Record processing completes with record no longer active
3) HIGH seconds later the callback occurs. It sets val=0 and calls dbProcess.
   Record processing calls device support which queues a message to device
   and tells record support that it has started asyn processing.
   The 1st phase of processing completes. Record is unlocked but active.
4) Some time later asyn completion occurs. Device support is called and checks
   status. Because val is 0 no callback is scheduled. Everything is done.

Now lets discuss bug. Assume that between steps 2) and 3) another put
with the value 1 is given to the record and the record is processed. Lets
also assume that the time between asyn start and asyn completion is > 
the time until step 3) occurs. In this case the following happens:

2a)The value 1 is written to the record and the record starts  processing
   Record processing calls device support which queues a request to the device
   and tells record support that it has started asyn processing.
   The 1st phase of processing completes. Record is unlocked but active.
3a)The callback occurs. It writes the value 0 to the record. It calls
   dbProcess but because record is active the record is not propcessed.
4a)Some time later asyn completion occurs. Device support is called and checks
   status. Because val is 0 no callback is scheduled. Everything is done.
   BUT THE VALUE 0 WAS NEVER SENT TO DEVICE.

Because of the new feature of caching puts, it turns out that this bug is
much more likely to occur than before. The fix is to have the callback
routine (after locking) check to see if the record is active. If it is
it just reschedules itself again. It does this until it finds the record
not active and then sets the value to 0 and calls dbProcess.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System