Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Wed, 19 Jun 2013 09:56:08 +0200

Hi Mark,

StreamDevice as such is not an asyn device driver. Only the

AsynDriverInterface is. The core of StreamDevice deliberately does not

depend on asyn (not even on EPICS). The idea was to be able to attach

other bus drivers than asynOctet (though there is none). (And also to

use it on other control systems or even stand-alone).

But I was thinking of a redesign of the error (and debug) messaging

system anyway. I want to be able to switch on and off errors and

debugging even per record and not only per bus (i.e. asyn port).

Therefore I have anyway to delegate message printing to the classes

which know what a record or what a bus/port is. So if

AsynDriverInterface became responsible for printing the message, it

could as well use asynTrace for it. But this is a major work and I have

to find time for it.

I am also thinking of a @connect handler to address the "EPICS device

disconnects and reconnects" problem. Unfortunately there is no 1:1

relation between a connect event and a device in need for

re-configuration. First, as Bruce already mentioned, disconnect of

serial devices is typically not recognized. Second, only that the

network cable is drawn and later reconnected does not mean that the

device needs to be re-initialized (But maybe it is a good idea to update

the output records to the device status at that time.) I will try to add

@connect soon.

Dirk

On 19.06.2013 05:00, Mark Rivers wrote:

Hi Dirk,

StreamDevice is primarily (exclusively?) used as device support for asyn drivers with EPICS.  As such, however, it does not follow the asyn "rules" for device support.  This is from the asynDriver Manual at http://www.aps.anl.gov/epics/modules/soft/asyn/R4-21/asynDriver.html

*******************************************************
In order for the trace facility to perform properly; device support and all drivers must use the trace facility. Device and driver support can directly call the asynTrace methods. The asynPrint and asynPrintIO macros are provided so that it is easier for device/driver support. Support can have calls like:
     asynPrint(pasynUser,ASYN_TRACE_FLOW,"%s Calling queueRequest\n",
         someName);
*******************************************************

StreamDevice does not use the asynTrace facility for error messages.  This has unfortunate consequences.  This is the output from an EPICS IOC that talks to a TCP/IP device with StreamDevice.  In this case the device happens to not be connected to the network.

2013/06/18 20:57:01.529 PACE5000 13PACE5000:PC1:Effort_RBV: Protocol aborted
2013/06/18 20:57:07.541 PACE5000 13PACE5000:PC1:Error_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host
2013/06/18 20:57:07.541 PACE5000 13PACE5000:PC1:Error_RBV: Protocol aborted
2013/06/18 20:57:10.547 PACE5000 13PACE5000:PC1:Effort_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host
2013/06/18 20:57:10.547 PACE5000 13PACE5000:PC1:Effort_RBV: Protocol aborted
2013/06/18 20:57:13.553 PACE5000 13PACE5000:PC1:Vent_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host
2013/06/18 20:57:13.553 PACE5000 13PACE5000:PC1:Vent_RBV: Protocol aborted
2013/06/18 20:57:16.559 PACE5000 13PACE5000:PC1:Slew_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host
2013/06/18 20:57:16.559 PACE5000 13PACE5000:PC1:Slew_RBV: Protocol aborted
2013/06/18 20:57:19.565 PACE5000 13PACE5000:PC1:Error_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host
2013/06/18 20:57:19.565 PACE5000 13PACE5000:PC1:Error_RBV: Protocol aborted
2013/06/18 20:57:22.571 PACE5000 13PACE5000:PC1:Vent_RBV: pasynCommon->connect() failed: Can't connect to 164.54.160.26:5025: No route to host

So there is a constant stream of error messages.

If StreamDevice used the asynTrace facility I could very easily turn these messages off with the following command:

asynSetTraceMask PACE5000 0 0

I could also turn them off with an EPICS GUI like medm by setting the ASYN_TRACE_ERROR bit for that port 0 with an asynRecord.

However, I've looked at the documentation for StreamDevice, and also the source code for StreamError.h and StreamError.cc, and there does not appear to beany way to turn off the error messages in StreamDevice.  There is a global variable StreamDebugFile which should allow one to route all StreamDevice error messages to afile.  But that is not what I want, I want to route just the messages for this disconnected device PACE5000.  Furthermore StreamDebugFile appears not to be availble in the iocsh shell?

I looked to see if it would be easy to convert the StreamError class to use asynTrace, and it is not as easy as I hoped because the required pasynUser handle is not available outside the AsynDriverInterface class.

Is there a way to make StreamDevice use the asynTrace facility, so we can get its advantages like enabling/disabling error messages on a per-port basis, routing debug output to a file on a per-port basis, etc.?

If not, then the changes I am considering to asyn to automatically turn off error messages on a disconnected port won't affect StreamDevice messages.

Thanks,
Mark

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System