AsynInt32 SCAN=I/O Intr response

[Eric Norum via Tech-talk <tech-talk at aps.anl.gov>]

I have an IOC that reads a bunch of system monitor values from an FPGA in a single UDP packet and then pushes the values to a bunch of SCAN=“I/O Intr” records (some ai, some longin).

Here’s a fragment of the .db file associate with this:

record(ai, "$(P)$(R)EVR:freq") {

    field(DESC, "EVR recovered clock")

    field(DTYP, "asynInt32")

    field(INP,  "@asyn($(PORT), 0x2008, 0)")

    field(SCAN, "I/O Intr")

    field(TSE,  "-2")

    field(LINR, "SLOPE")

   .

   .

   .

}

record(longin, "$(P)$(R)Marble:PIO_") {

    field(DESC, "Marble port expanders")

    field(DTYP, "asynInt32")

    field(INP,  "@asyn($(PORT), 0x2003, 0)")

    field(EGU,  "")

    field(SCAN, "I/O Intr")

    field(TSE,  "-2")

}

This all seems to work properly — I see the values updating as they should.

The issue is that the asynReport output shows the longin records as disconnected (“KD1” is the PORT in the INP fields of the records shown above, “KD1_CMD” is the UDP/IP port communicating with the FPGA).

epics> asynReport

KD1_CMD multiDevice:No canBlock:Yes autoConnect:No

KD1 multiDevice:Yes canBlock:Yes autoConnect:Yes

    addr 8195 autoConnect Yes enabled Yes connected No exceptionActive No

    addr 8201 autoConnect Yes enabled Yes connected No exceptionActive No

 KD1_CMD communicating

epics> 

If I run the asynReport with interest level 1, all the records show up.  Here’s the report for the ai record shown above:

    addr 8200 autoConnect Yes enabled Yes connected Yes exceptionActive No

        exceptionActive No exceptionUsers 0 exceptionNotifys 0

        blocked No

This isn’t a big deal since things do seem to work, but I wonder why this difference between asynInt32 callback handling for ai and longin records.

— 

Eric Norum

eric at norum.ca