Re: Asyn GPIB proto file exception @writetimeout

[Dirk Zimoch <dirk.zimoch@psi.ch>]

> a) Disable error handlers during @init. This is the easy way out.
In StreamCore.cc method finishProtocol(ProtocolResult status)
find the line
    if (runningHandler)
and replace it with
    if (runningHandler || flags & InitRun)

Then @writetimeout will not be called during @init, only later during 
periodic processing. But at least it will not crash.
Maybe it is better not to use @init for this purpose but instead set 
field(PINI, "YES") in the record. @init was meant to read start values 
for output records because this needs a different protocol than normal 
processing.
Dirk


On 20.10.2017 11:39, Dirk Zimoch wrote:
> Hello James,
>
> I could reproduce your problem with an Agilent E5810A Lan/GPIB gateway
> and no device connected.
>
> The crash happens only when @writetimeout is triggered during @init and
> executes dbpf. If one of the three prerequisites is not fulfilled, it
> does not crash.
>
> Thus I guessed calling dbpf before iocInit finishes is the actual
> problem. I checked that theory by simply adding the following line to
> the startup script before iocInit:
> dbpf HEBT:SCOPE1:ALIVE.A 1
> It crashes.
>
> Thus the crash is not directly related to StreamDevice but to the fact
> that dbpf is called on a not yet fully initialized database.
>
> I need to investigate how I can fix the problem. I have two options in
> mind:
> a) Disable error handlers during @init. This is the easy way out.
> b) Run @init later. At the moment, it is run during init_record. Other
> records may not have been initialized at this time. Maybe I can move
> @init to a later time using initHooks.
>
> Dirk
>
>
> On 20.10.2017 10:52, Dirk Zimoch wrote:
> > Hi James,
> >
> > How is your GPIB device connected? Do you have a GPIB card or do you use
> > a LAN-GPIB box (which model?) or does the device itself have a vxi11
> > (GPIP over TCP) interface? In your mail I could not see how the asyn
> > port is created. Do you use vxi11Configure?
> >
> > If you use a LAN-GPIB box, is the box running when the device is offline?
> >
> > Dirk
> >
> > BTW: When I replied on your first tech-talk mail on Oct 6, I got an
> > error from your mail server: "<jlarsson@triumf.ca>... Account disabled
> > 05/Oct/2017"
> > Seems to be fixed by now.
> >
> > Dirk
> >
> >
> > On 19.10.2017 21:02, jlarsson@triumf.ca wrote:
> > > Hey there,
> > >
> > > Thanks for taking a look.  The theory and practice I use the ASYN /
> > > StreamDevice for is as follows.  I use the an IDN record and function to
> > > query the device name, once every 10 seconds. In an Agilent WFG for
> > > example. I have a separate periodic scan record that queries/sets the
> > > device qualities.
> > >
> > > In the IDN portion of the proto file I execute a 'dbpf SOMERECORD 1'
> > > and a
> > > reply timeout exception of 'dbpf SOMERECORD 0'.  It acts like a ping. I
> > > then use that bit in epics to drive the DISV / DISA / SDIS, of a common
> > > scan record.
> > >
> > > So if my Agilent WFG is turned off, then I stop trying to read/write the
> > > device qualities. But the IDN still checks.  So if someone comes and
> > > turns
> > > the WFG on, epics starts reading and writing the qualities again.
> > >
> > > It's nice because it cleans up unnecessary (and polled typically)
> > > network
> > > traffic as well limits the number of error messages generated, and
> > > lastly
> > > stops an IOC from processing things unnecessarily.
> > >
> > > I tried this with GPIB devices, but I don't get exception code called in
> > > the proto file.
> > >
> > > Here is the record text that is relevant, I can send you attached
> > > complete
> > > ones if you like.  The ALIVE record referenced below in the proto is a
> > > simple calc record.
> > >
> > > [ the record .... ]
> > > record(stringin,"HEBT:SCOPE1:IDN") {
> > >     field(DESC,"string input record")
> > >     field(SCAN,"10 second")
> > >     field(PINI,"YES")
> > >     field(PHAS,"0")
> > >     field(EVNT,"0")
> > >     field(DTYP,"stream")
> > >     field(DISV,"1")
> > >     field(SDIS,"0.000000000000000e+00")
> > >     field(DISS,"NO_ALARM")
> > >     field(PRIO,"LOW")
> > >     field(FLNK,"0.000000000000000e+00")
> > >     field(VAL,"string")
> > >     field(INP,"@tektds8000.proto IDN(HEBT:SCOPE1) GPIB0 10")
> > >     field(SIOL,"0.000000000000000e+00")
> > >     field(SIML,"0.000000000000000e+00")
> > >     field(SIMS,"NO_ALARM")
> > > }
> > >
> > > [ the proto that fails to call the exception exec.... ]
> > > IDN {
> > >
> > >     InTerminator = LF;
> > >     @init {
> > >         out "HEADER OFF";
> > >         out "*IDN?";
> > >         # in "%s %s";
> > >         in "%64c";
> > >    }
> > >     out "*IDN?";
> > >     # in "%s %s";
> > >     in "%64c";
> > >
> > >      # Added by James Larsson Oct. 5 2017 to throttle ASYN Error
> > > Messages
> > >      exec "dbpf \$1:ALIVE.A 0";
> > >      @replytimeout
> > >      {
> > >         exec "dbpf \$1:ALIVE.A 1 ";
> > >      }
> > > }
> > >
> > > [ the proto that crashes the IOC (just a @writetimeout delta).... ]
> > > IDN {
> > >
> > >     InTerminator = LF;
> > >     @init {
> > >         out "HEADER OFF";
> > >         out "*IDN?";
> > >         # in "%s %s";
> > >         in "%64c";
> > >    }
> > >     out "*IDN?";
> > >     # in "%s %s";
> > >     in "%64c";
> > >
> > >      # Added by James Larsson Oct. 5 2017 to throttle ASYN Error
> > > Messages
> > >      exec "dbpf \$1:ALIVE.A 0";
> > >      @writetimeout
> > >      {
> > >         exec "dbpf \$1:ALIVE.A 1 ";
> > >      }
> > > }
> > >
> > >
> > > [The script portion that configures the GPIB device: and the '.....'
> > > are mine
> > > .....]
> > > asynSetOption("GPIB0",10,0x0c,0)
> > > .....
> > > asynSetTraceIOMask(GPIB0,10,0x0005)
> > > asynSetTraceMask  (GPIB0,10,0x001f)
> > > .....
> > > dbLoadRecords("asynRecord.db","P=HEBT:SCOPE1:,R=ASYN,PORT=GPIB0,ADDR=2,IMAX=0,OMAX=0")
> > >
> > >
> > > ....
> > > asynSetTraceMask  (GPIB0,10,0x0000)
> > > asynSetTraceIOMask(GPIB0,10,0x0000)
> > >
> > >
> > > Cheers and Thanks again!
> > >
> > > James Larsson, P.Eng.
> > > Triumf Control Systems Engineer
> > >
> > >
> > > > Hello James,
> > > >
> > > > I am back from ICALEPCS, thus I can start debugging your StreamDevice
> > > > problem.
> > > >
> > > > In order to reproduce your problem, I need some more information from
> > > > you.
> > > >
> > > > Please send me:
> > > > * The part of your startup script where you configure the GPIB device
> > > > * The record that causes the crash
> > > > * The protocol file used by this record.
> > > >
> > > > Best regards,
> > > > Dirk
> > > >
> > > > On 06.10.2017 17:40, jlarsson@triumf.ca wrote:
> > > > > Hey hey!
> > > > >
> > > > > I have a device on my Linux IOC, using Asyn GPIB.  The device works on
> > > > > the
> > > > > IOC and, connected with EDM - is controllable.
> > > > >
> > > > > When the device is turned off I get an error message:  asynError in
> > > > > write:
> > > > > GPIB0 writeGpib failed ENOL 2: No listeners
> > > > >
> > > > > The function in the proto file uses exception @replytimeout, but that
> > > > > never executes,  which I would expect (I queried a device, it's not
> > > > > there,
> > > > > I should have a timeout). This works on TCP/IP devices, just not GPIB.
> > > > >
> > > > > Does anyone have any thoughts, or hacks, or updates on getting GPIB
> > > > > exceptions to run the proto file exception commands?
> > > > >
> > > > > Also when I try using the @writetimeout exception to more closely
> > > > > mimic
> > > > > the error message, the IOC crashes on boot, not even an IOC command
> > > > > prompt, which looks like a separate problem, any help on that would
> > > > > also
> > > > > be appreciated.  Error message is:
> > > > >
> > > > > A call to 'assert(dbLockIsInitialized)'
> > > > >     by thread 'cbLow' failed in ../dbLock.c line 239.
> > > > > EPICS Release EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$.
> > > > > Local time is 2017-10-06 08:13:40.495885987 PDT
> > > > > Please E-mail this message to the author or to tech-talk@aps.anl.gov
> > > > > Calling epicsThreadSuspendSelf()
> > > > > Thread cbLow (0x9a12518) suspended
> > > > >
> > > > >
> > > > > Cheers
> > > > > James Larsson