Hello again.
Han and Mark, Namrata already answered some of the questions.
Mark Rivers => You said “Communication was ok, until it stopped and we set some masks to diagnose:”. But communication does not appear to have stopped before you set those masks? It had been less than 5 seconds since the last successful read, correct? Was there some other reason the asynTrace was turned on then?
Well, that I can't remember completely. What comes to my mind is that we were observing the system when the lack of communication happened and we turned on the masks. But 5 seconds seems really a too fast shot to believe.
Mark Rivers => That shows that it has connected 146 times. Did you connect manually 146 times? That seems unlikely, so it seems that perhaps disconnectOnReadTimeout was doing what it is supposed to do, i.e. getting a read timeout, disconnecting and reconnecting?
Yes, those 146 times happened after I turned disconnectOnReadTimeout on. From the messages on screen I believe this sequence that you've described is what it is happening.
Regarding Asyn R4-35: Fixed a problem with the disconnectOnReadTimeout option. Previously it would disconnect even if pasynUser->timeout was 0. This is not logical, and meant this option could not be used with StreamDevice, because StreamDevices flushes the input by reading with a timeout of 0 to support I/O Intr scanned records.
It is not clear to me if using a newer version of Asyn would make it possible for me to use disconnectOnReadTimeout or if a newer version of Asyn would ignore the option when it finds pasynUser->timeout = 0.
Thank you again for the help.
Márcio Paduan Donadio
Control Systems Engineer - SLAC
On 9/2/20, 12:02 PM, "Balakrishnan, Namrata" <namrata at slac.stanford.edu> wrote:
Hi Han, Mark,
> Is your ioc developed by your team or CAEN? I think CAEN has their own embedded IOC. I saw your model also in their EPICS support list.
Yes, we are using the database and protocol file from CAEN EPICS support but have the IOC modified for our environment.
> ? If we close and open the port again, communication is reestablished.
> What do you mean by that? How did you do it?
We tried the sequence of toggling Autoconnect (.AUCT), Enable/Disable(.ENBL) and connect/Disconnect(.CNCT) on the asyn record. The communication was re-established within 30 minutes ( immediately one time).
But as Marcio mentioned, once disconnectOnReadTimeout was tried, we have not been able to communicate with the device again. The system is still in this condition as we were not authorized to reboot the IOC, yet.
>Can you ping the CAEN device? Can you open a manual telnet connection to it on port 1470, which seems to be the port you are using?
We can ping the device. But telnet stays at 'connecting to the device' state. The IOC is online at this point but communication with the device is not established.
Thanks and regards,
Namrata
- References:
- RE: CAEN R1470ET HVPS - Asyn + Stream Device auto connect does Balakrishnan, Namrata via Tech-talk
- Navigate by Date:
- Prev:
Teledyne ISCO D Series pumps Wyman, Max D via Tech-talk
- Next:
Re: dbpf equivalent for V4 records Marty Kraimer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: CAEN R1470ET HVPS - Asyn + Stream Device auto connect does Balakrishnan, Namrata via Tech-talk
- Next:
Re: CAEN R1470ET HVPS - Asyn + Stream Device auto connect does Mark Rivers via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|