Re: STAT=SCAN recover - Root issue SOLVED

[Isabella Rey <isa.hellen@gmail.com>]

Hi All,

Thank you for your help, the patch does the trick:

when the device dies, the record doesn't go in STAT=SCAN anymore, and keeps processing.

The connection also comes back automatically if the device is up again, which wasn't happening if there was the SCAN alarm.

Cheers,

Isabella

On 2 April 2015 at 11:48, Mark Rivers <rivers@cars.uchicago.edu> wrote:

Hi Isabella,

I have attached the original message with the patch (I think attachments don't get saved in the tech-talk archive).

The patch is the following.  Note that it just adds a single line (with + character) to AsynDriverInterface.cc.

corvette:stream/streamDevice/src>svn diff AsynDriverInterface.cc
Index: AsynDriverInterface.cc
===================================================================
--- AsynDriverInterface.cc    (revision 15960)
+++ AsynDriverInterface.cc    (working copy)
@@ -630,6 +630,7 @@
         int eomReason = 0;
         status = pasynOctet->read(pvtOctet, pasynUser,
             buffer, received, &received, &eomReason);
+        if (status == asynError) break;
 #ifndef NO_TEMPORARY
         if (received) debug("AsynDriverInterface::writeHandler(%s): flushing %ld bytes: \"%s\"\n",
             clientName(), (long)received, StreamBuffer(buffer, received).expand()());


Mark


________________________________
From: Isabella Rey [isa.hellen@gmail.com]
Sent: Thursday, April 02, 2015 4:56 AM
To: Jon Nielsen
Cc: tech-talk@aps.anl.gov; Mark Rivers
Subject: Re: STAT=SCAN recover

Hi again,

Sorry, where can I find the patch in question?
I went to the stream device 2 website http://epics.web.psi.ch/software/streamdevice/#download but it only has patches from 2012...

Cheers,
Isabella

On 2 April 2015 at 10:46, Isabella Rey <isa.hellen@gmail.com<mailto:isa.hellen@gmail.com>> wrote:
Hi Guys,

thanks for your replies.

Yes, we are using stream device 2.6 and asyn 4.21, both the same as in the other post!

I'll have a go at the patch and let you know!

Isabella

On 1 April 2015 at 22:11, Jon Nielsen <jon.nielsen@anu.edu.au<mailto:jon.nielsen@anu.edu.au>> wrote:
Hi Isabella, Mark,

The patch to StreamDevice that Mark mentions fixed exactly this problem for me with Ethernet communications to a LakeShore device.  Cheers,

Jon

On 2 Apr 2015, at 6:52 am, Mark Rivers <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>> wrote:

> Hi Isabella,
>
> What version of asyn and what version of streamDevice are you using?
>
> You should look at this tech-talk thread:
> http://www.aps.anl.gov/epics/tech-talk/2014/msg00605.php
>
> You will see that on April 11, 2014 there was a similar problem with serial ports, specifically USB serial ports which can be disconnected.
>
> There were actually 2 problems:
>
> -          A bug in the asyn drvAsynSerialPort driver
> -          A bug in StreamDevice
>
> You are using drvAsynIPPort, not drvAsynSerial port, so that fix does not affect you.  However, the fix in streamDevice might be important.
>
> The patch for streamDevice is in the tech-talk message referenced above.
>
> Mark
>
>
> From: Isabella Rey [mailto:isa.hellen@gmail.com<mailto:isa.hellen@gmail.com>]
> Sent: Wednesday, April 01, 2015 8:28 AM
> To: Mark Rivers
> Cc: tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>

> Subject: Re: STAT=SCAN recover
>
> Hi Mark,
>
> I'm using stream device, and I'm talking to a device via Ethernet.
> The record and protocol are as below.
> Note the SCAN field of the record is set to be greater than the ReplyTimeout.
>
> When the device is up and running, all is fine.
> But if the device shuts off unexpectedly, my record after a few seconds goes in the SCAN alarm status.
> I could bring the device up again and try re-establishing the connection, but I then need this record to start processing normally again.
>
> My understanding is that this happens when the record is found with PACT=1 for 10 consecutive times.
> But why is it happening in the first place here...? Shouldn't the record simply time out and keep processing every second?
> If the device is not there at IOC startup, the record does process every second, it just complains that it can't connect. Shouldn't it be the same when it looses an existing connection?
>
> So my question becomes:
> Why is the record going in STAT=SCAN, and if I can't avoid it, can I recover from it?
> Otherwise I'll have to restart the IOC.
>
> Thanks,
> Isabella
>
>
> **In the database:
> record(ai, "DEV:SOURCE_MODE") {
>   field(DTYP, "stream")
>   field(INP, "@my.proto source_mode() $(PORT)")
>   field(SCAN, "1 second")
> }
>
> **In the protocol:
> ReplyTimeout = 500;
> source_mode
> {
>     out "source_mode?";
>     in "%i";
> }
>

> On 1 April 2015 at 13:55, Mark Rivers <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>> wrote:
> The answer will depend on how the record got to the STAT=SCAN state.  Device support can set STAT and SEVR.
>
> What device support is this record using?  Do you know what went wrong to put the record into STAT=SCAN state?
>
> Mark
>
>
> ________________________________
> From: tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov> [tech-talk-bounces@aps.anl.gov<mailto:tech-talk-bounces@aps.anl.gov>] on behalf of Isabella Rey [isa.hellen@gmail.com<mailto:isa.hellen@gmail.com>]
> Sent: Wednesday, April 01, 2015 7:49 AM
> To: tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>
> Subject: STAT=SCAN recover
>
> Hi All,
>
> Is there any way to recover a record from STAT=SCAN without restarting the IOC?
>
> Thanks,
> Isabella

--
Jon Nielsen <jon.nielsen@anu.edu.au<mailto:jon.nielsen@anu.edu.au>>
Research School of Astronomy and Astrophysics
The Australian National University
Ph: +61 2 6125 8901<tel:%2B61%202%206125%208901>