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 2017 2018 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 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort |
| From: | Mazanec Tomáš <[email protected]> |
| To: | Mark Rivers <[email protected]>, "[email protected]" <[email protected]> |
| Date: | Thu, 10 Apr 2014 11:24:20 +0000 |
|
In synApps 5.7, if the usb-serial device is physically disconnected, while the IOC is running, the command: asynReport(10, PORT) says the asyn port is still connected: PORT multiDevice:No canBlock:Yes autoConnect:Yes enabled:Yes connected:Yes numberConnects 1 nDevices 0 nQueued 0 blocked:No asynManagerLock:No synchronousLock:Yes exceptionActive:No exceptionUsers 2 exceptionNotifys 0 interposeInterfaceList asynOctet pinterface 0x7fbbfb51f6a0 drvPvt 0x1489670 interfaceList asynCommon pinterface 0x7fbbfb51ca80 drvPvt 0x1486740 asynOption pinterface 0x7fbbfb51caa0 drvPvt 0x1486740 asynOctet pinterface 0x7fbbfb51ee40 drvPvt 0x1486740 Serial line /dev/ttyUSBPIC: Connected fd: 5 Characters written: 164 Characters read: 287 What also happens, and I didn't noticed, is IOC's process takes 100% CPU usage and traceFlow bit within traceMask in Asyn reports hundreds of these lines in a second: 2014/04/10 13:06:39.575 /dev/ttyUSBPIC read. 2014/04/10 13:06:39.575 /dev/ttyUSBPIC read. 2014/04/10 13:06:39.575 /dev/ttyUSBPIC read. 2014/04/10 13:06:39.575 /dev/ttyUSBPIC read. 2014/04/10 13:06:39.575 /dev/ttyUSBPIC read. However, an attempt to reconnect asyn port with asynRecord ends with no success and this messsage output: 2014/04/10 13:04:32.374 EEE:asynrec: special queueRequest timeout Thanks, Tomas Od: Mark Rivers [[email protected]]
Odesláno: 8. dubna 2014 18:47 Komu: Mazanec Tomáš; [email protected] Předmět: RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort In synApps 5.7 what happens if you use an asynRecord to force the asynPort to reconnect. Does StreamDevice then start working?
When the device is disconnected does asyn report that it is disconnected? Use the following command when the device is disconnected:
asynReport 10 ASYN_PORT_NAME
Mark
From: Mazanec Tomáš [mailto:[email protected]]
Od: Mark Rivers [[email protected]] Hi Tomas,
There were no substantive changes in the drvAsynSerialPort code between asyn 4.18 and asyn 4.21. SVN tag 1917 is asyn 4.18 and tag 2203 is asyn 4.21.
Here are the differences:
corvette:asyn/asyn/drvAsynSerial>svn diff -r1917:2203 drvAsynSerialPort* Index: drvAsynSerialPort.c =================================================================== --- drvAsynSerialPort.c (revision 1917) +++ drvAsynSerialPort.c (revision 2203) @@ -103,12 +103,12 @@ if ((ioctl(tty->fd, FIOBAUDRATE, tty->baud) < 0) && (ioctl(tty->fd, SIO_BAUD_SET, tty->baud) < 0)) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "SIO_BAUD_SET failed: %s\n", strerror(errno)); + "SIO_BAUD_SET failed: %s", strerror(errno)); return asynError; } if (ioctl(tty->fd, SIO_HW_OPTS_SET, tty->termios.c_cflag) < 0) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "SIO_HW_OPTS_SET failed: %s\n", strerror(errno)); + "SIO_HW_OPTS_SET failed: %s", strerror(errno)); return asynError; } #else @@ -116,7 +116,7 @@ tty->termios.c_cflag |= CREAD; if (tcsetattr(tty->fd, TCSANOW, &tty->termios) < 0) { epicsSnprintf(pasynUser->errorMessage, pasynUser->errorMessageSize, - "tcsetattr failed: %s\n", strerror(errno)); + "tcsetattr failed: %s", strerror(errno)); return asynError; } #endif @@ -253,12 +253,12 @@ } if(cfsetispeed(&tty->termios,baudCode) < 0 ) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "cfsetispeed returned %s\n",strerror(errno)); + "cfsetispeed returned %s",strerror(errno)); return asynError; } if(cfsetospeed(&tty->termios,baudCode) < 0 ) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "cfsetospeed returned %s\n",strerror(errno)); + "cfsetospeed returned %s",strerror(errno)); return asynError; } } @@ -452,7 +452,7 @@ tcflush(tty->fd, TCOFLUSH); #endif #ifdef vxWorks - ioctl(tty->fd, FIOCANCEL, NULL); + ioctl(tty->fd, FIOCANCEL, 0); /* * Since it is possible, though unlikely, that we got here before the * slow system call actually started, we arrange to poke the thread @@ -509,14 +509,14 @@ */ if ((tty->fd = open(tty->serialDeviceName, O_RDWR|O_NOCTTY|O_NONBLOCK, 0)) < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "%s Can't open %s\n", + "%s Can't open %s", tty->serialDeviceName, strerror(errno)); return asynError; } #if defined(FD_CLOEXEC) && !defined(vxWorks) if (fcntl(tty->fd, F_SETFD, FD_CLOEXEC) < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "Can't set %s close-on-exec flag: %s\n", + "Can't set %s close-on-exec flag: %s", tty->serialDeviceName, strerror(errno)); close(tty->fd); tty->fd = -1; @@ -578,7 +578,7 @@ asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s write.\n", tty->serialDeviceName); asynPrintIO(pasynUser, ASYN_TRACEIO_DRIVER, data, numchars, - "%s write %d\n", tty->serialDeviceName, numchars); + "%s write %lu\n", tty->serialDeviceName, (unsigned long)numchars); if (tty->fd < 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, "%s disconnected:", tty->serialDeviceName); @@ -672,7 +672,7 @@ } if (maxchars <= 0) { epicsSnprintf(pasynUser->errorMessage,pasynUser->errorMessageSize, - "%s maxchars %d Why <=0?\n",tty->serialDeviceName,(int)maxchars); + "%s maxchars %d Why <=0?",tty->serialDeviceName,(int)maxchars); return asynError; } if (tty->readTimeout != pasynUser->timeout) { @@ -775,8 +775,8 @@ data[nRead] = 0; else if (gotEom) *gotEom = ASYN_EOM_CNT; - asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s read %d, return %d\n", - tty->serialDeviceName, *nbytesTransfered, status); + asynPrint(pasynUser, ASYN_TRACE_FLOW, "%s read %lu, return %d\n", + tty->serialDeviceName, (unsigned long)*nbytesTransfered, status); return status; }
So the changes are removing “\n” from the end of epicsSNprintf formats, and some other minor changes to avoid compiler warnings.
Is this on Linux?
Have you upgraded the OS?
I think any change in behavior is likely due either to a change in StreamDevice or a change in the OS, and not due to any change in asyn.
Mark
From:
[email protected] [mailto:[email protected]]
On Behalf Of Mazanec Tomáš
|
- Replies:
- RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mark Rivers
- Re: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Dirk Zimoch
- References:
- Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mazanec Tomáš
- RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mark Rivers
- RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mazanec Tomáš
- RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mark Rivers
- Navigate by Date:
- Prev: EDM - where to find widget "Variable Scale Bar" Joachim Rahn
- Next: RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort 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 2017 2018 2019 2020 2021 2022 2023 2024
- Navigate by Thread:
- Prev: RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort Mark Rivers
- Next: RE: Streamdevice 2.6 autoconnection failure using drvAsynSerialPort 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 2017 2018 2019 2020 2021 2022 2023 2024
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·