EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Force TCP/IP reconnect from Asyn/Streamdevice
From: Christoph Schroeder <[email protected]>
To: Mark Rivers <[email protected]>, Torsten Bögershausen <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 6 Jun 2017 15:55:39 +0200
Hi Mark,

sadly that is not possible because I had other problems with the I/O
Intr record of Streamdevice. When I set a higher ReadTimeout at higher
data rates (50+Hz), e.g. 1000ms, the data can be seen on the shell
setting the IO trace mask but the I/O Intr record does not process
despite properly setting MaxInput. I set ReadTimeout and PollPeriod to
the minimum of 1ms (higher data rates might be possible). At these
settings everything worked as expected.

Best regards,

Christoph

On 06/02/2017 10:42 PM, Mark Rivers wrote:
Hi Christoph,

In thinking about a similar question today I realized that there may be a simpler solution for your problem.  You may be able to just use the asynOption disconnectOnReadTimeout to force the connection to reset on a read timeout.  This assumes you are reading the device with a timeout longer than you expect the time between periodic messages from the device.  Look at the drvAsynIPPort documentation (http://www.aps.anl.gov/epics/modules/soft/asyn/R4-31/asynDriver.html#drvAsynIPPort) for details.

Mark

-----Original Message-----
From: Christoph Schroeder [mailto:[email protected]]
Sent: Wednesday, May 24, 2017 3:53 AM
To: Mark Rivers; Torsten Bögershausen; [email protected]
Subject: Re: Force TCP/IP reconnect from Asyn/Streamdevice

Hi Mark,

that actually worked. I am using 3 records, one counter that is
processed each time data is received, a record to save the old counter
value and a calc that compares both values which is processed every
other second. I monitored the calc and it shows me that the connection
was reset 2 times since yesterday. The device is working fine right now,
thanks a lot!

Best regards,
Christoph


On 05/23/2017 01:50 PM, Mark Rivers wrote:
If you load an asyn record on this asyn port then you can use the CNCT (connect) field to force drvAsynIPPort to disconnect and reconnect the device.  This should be equivalent to restarting the IOC.  Have you tried this?  If it works then you just need to figure out some logic to tell when the device is hung up and write to this field twice, first with Disconnect and then with Connect.  Detecting when it has hung could be done with a longin record that increments each time you receive a message and then a calc record that processes periodically and checks to see if the longin record has stopped incrementing.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Christoph Schroeder [[email protected]]
Sent: Tuesday, May 23, 2017 6:22 AM
To: Torsten Bögershausen; [email protected]
Subject: Re: Force TCP/IP reconnect from Asyn/Streamdevice

On 05/23/2017 12:26 PM, Torsten Bögershausen wrote:
On 23/05/17 12:19, Christoph Schroeder wrote:
Hello,


On 05/23/2017 11:40 AM, Torsten Bögershausen wrote:
On 23/05/17 10:53, Christoph Schroeder wrote:
Hi Torsten,


On 05/23/2017 10:40 AM, Torsten Bögershausen wrote:
Which side does the retransmission ?
The IOC ?
The device ?
The device retransmits a package that the IOC already received
again and
again until it gives up. The IOC sends duplicate ACK. It seems the
acknowledge is ignored on the devices side.
Now, well, it looks as if the reset was not processed by the IOC ?
At least it didn't cause the TCP connection to be terminated, right ?
Right, netstat tells me the connection is still established, but there
is no flow of data anymore and the buffers are empty. The last
package I
reveived from the device is the TCP RST.
Which OS are you using ?
Which version of asyn ?

My tests where done with Debian 7 and Debian 8. The asyn version is
R4-30. The problem seems to be caused by a lower layer. I got the same
problem with a simple TCP client I wrote and even with netcat, so Asyn
isn't at fault here.
You should be able to use the CONNECT_PER_TRANSACTION feature from asyn
by using
drvAsynIPPortConfigure("xx", "<host>:<port>[:localPort] http",0,0,0)

(But I wonder if this helps, when your device seems to have such
problems)
Thanks I will try this.

Another question:

Is the IOC sending anything more to the device?
And wait the response ?
Why is it so quite on the line ?
When the IOC polls the device, there should be some traffic coming out,
I think.
If there is nothing to be polled from the IOC, then it doesn't matter,
if the underlying TCP connection is not working, half-broken or
whatever.
The instrument sends unsolicited data starting directly after the
connections is established. There is no active communication from the
IOC to the device.
That is sad to here, because then the "http" trick doesn't help us:
The IOC will not send anything to the device.
So there is no need to re-open the connection.

Is there a chance to poll the device at all ?


And/or:
What does the device do, if you use your netcat test setup.
and the connection is closed ?
Will it accept a new one and behave better then on the old one ?
No chance for polling, communication on this port is read only. The data
is only send to the first client connected to the port. Closing the
connection and opening it again resp. rebooting the IOC or restarting
the client / netcat works fine until the error happens again. I observed
that the time until the error occurs depends on the number of TCP
packages send by the device which can be increased by configuring a
higher scan rate on the device. I think it's some kind of buffer or
counter overflow on the device which is reset with a new connection.


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Replies:
RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers
References:
Force TCP/IP reconnect from Asyn/Streamdevice Christoph Schroeder
Re: Force TCP/IP reconnect from Asyn/Streamdevice Torsten Bögershausen
Re: Force TCP/IP reconnect from Asyn/Streamdevice Torsten Bögershausen
Re: Force TCP/IP reconnect from Asyn/Streamdevice Christoph Schroeder
Re: Force TCP/IP reconnect from Asyn/Streamdevice Torsten Bögershausen
Re: Force TCP/IP reconnect from Asyn/Streamdevice Christoph Schroeder
RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers
Re: Force TCP/IP reconnect from Asyn/Streamdevice Christoph Schroeder
RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers

Navigate by Date:
Prev: Re: How to deal with LINK_ALARM Pilar
Next: RE: How to deal with LINK_ALARM Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers
Next: RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024