RE: asynPortDriver

["Szalata, Zenon M." <zms@slac.stanford.edu>]

Hi Mark,
In the first version of the device driver, I saw the effect that Kevin Tsubota described in his reply to my email.  This is what he said:

"At Keck we ran into a similar problem where we weren't seeing all the events we expected with a different driver and it turned out to be that ASYN only posts on change."

In all three version of the device driver The data is read out at interrupt level, which is needed to clear the interrupt.  Then I schedule a callback to continue processing the data.  This consists of unpacking the data words into various components.
In the case of the first version of the device driver, the callback requests to process the records are done in a for loop.  Perhaps I have abandoned the first version too quickly.
Anyway it was clear to me that it would be better to bundle the trigger number and data from all ADC channels and pass that to the db layer.

I will modify the C subroutine of the subroutine record to also print a message when the current gate number is less than the previous value.

Thanks,
Zen

> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Sunday, July 15, 2012 3:19 PM
> To: Szalata, Zenon M.
> Cc: tech-talk@aps.anl.gov; Williams Jr., Ernest L.
> Subject: RE: asynPortDriver
> 
> How are you passing the data from your interrupt service routine to the
> thread that is calling callParamCallbacks()?  Are you using a mechanism with
> a queue, like an epicsMessageQueue?
> 
> I'd like to understand why "the order of record processing is somewhat
> random" in method 1.  I would think that it would be deterministic because
> there is only 1 callback thread that is processing all the records in the order
> in which the callback requests were issued, which I assume your driver does
> in a loop like:
> 
> for (i=0; i<16; i++) {
>   callParamCallbacks(i);
> }
> 
> Mark
> 
> ________________________________
> From: Szalata, Zenon M. [zms@slac.stanford.edu]
> Sent: Sunday, July 15, 2012 12:15 PM
> To: Mark Rivers
> Cc: tech-talk@aps.anl.gov; Williams Jr., Ernest L.
> Subject: asynPortDriver
> 
> Hi Mark,
> I am trying to understand why my device driver for a CAEN VME gated ADC
> module, which is based on asynPortDriver class works incorrectly.  The
> module has 16 ADC channels and is setup to generate an interrupt for each
> gate signal.  The interrupt triggers data readout and record processing.  For
> testing, the trigger/gate rate is 100 Hz.  The device driver maintains a gate
> counter, which gets incremented each time the data is processed.
> So far I have three versions of the device driver.
> 
> 1. In this version I have 16 I/O Intr scanned ai records.  The gate counter is
> pushed to a longin record.
>     This version has the problem that the order of record processing is
> somewhat random and the IOC
>     using this VME module requires the processing to be deterministic.  To
> overcome this difficulty,
>    I wrote the second version.
> 
> 2. In this version I pack the gate counter and all 16 ADC channel values into
> an array and this array gets
>     pushed to a waveform record.  Then, the data gets distributed to ai records
> using  sub array records.
>    This part works fine.  I have subroutine record which is processed each time
> the data waveform record
>    is processed.  It checks for missing triggers, by expecting that the gate
> counter value for this data array
>    is larger by 1 than the previous one.  This is where the device driver code
> seems to fail.
>    I let the IOC run for a bit over 35 hours.  More precisely the time
> corresponds to 12700898 triggers.
>    During this time the subroutine record reported 42 missing triggers.  They
> occurred spread out
>    throughout the run nearly but not equally spaced in time. I have a simple
> print statement
>    in the C routine which prints a few numbers.  These numbers tell me that the
> trigger incremented by 2.
>    I just looked at the logic in the C routine and I see that I am not printing
> messages when the new gate
>    counter is less than the previous one.  So it is possible that from time to
> time the waveform record gets
>    the data out of order.  It is also possible, but I think unlikely, that from time
> to time the data is lost.
> 
> 3. This version of the device driver is non-asyn.  It consists of two parts,
> device support and record support.
>     I wrote it, by taking the second version of the device driver and replaced the
> asynPortDriver part with
>    device support.  Also, I created a new version of the IOC, by taking the IOC
> which used the second version of
>    the device driver and modifying the db files and the st.cmd file as needed.  I
> ran this IOC version
>   overnight, so far it has processed 4 and half million triggers and not a single
> missed trigger.
> 
> I wonder if the behavior observed using the second version of the device
> driver is to be expected?
> Does it mean, that for some applications the asynPortDriver approach to
> device driver implementation might be not appropriate?
> Zen