Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> · Wed, 2 Sep 2020 20:28:36 +0000

Hi Marcio,

> 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.

Using the new version of asyn would make it possible to use disconnectOnReadTimeout.  The problem was that StreamDevice does not call the pasynOctet->flush() method to flush the input buffer before a write/read operation.  Instead it repeatedly calls pasynOctet->read() with a timeout of 0, until it receives no characters.  It does this because it actually needs to save those "flushed" characters to handle I/O Intr scanned records.  Previously if disconnectOnReadTimeout was enabled, the drvAsynIPPort was disconnecting at the end of each of those pseudo-flush operations, because the read timed out with no characters received.  This was obviously not the correct behavior, it should only disconnect on normal reads with non-zero timeouts.  That was the fix made in R4-35.  StreamDevice does use non-zero timeouts for normal read operations, it only uses zero timeouts for the pseudo-flush operation.

Mark

________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Paduan Donadio, Marcio via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, September 2, 2020 3:04 PM
To: tech-talk at aps.anl.gov
Subject: Re: CAEN R1470ET HVPS - Asyn + Stream Device auto connect does

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System