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: Asyn/StreamDevice for HP3458A through Agilent E5810 LAN/GPIB Gateway |
From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
To: | "'Hu, Yong'" <yhu at bnl.gov> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Wed, 8 Jul 2020 14:12:45 +0000 |
Hi Yong, Ø
PS: I had difficulty finding the exact version number of asyn/streamdevice since I built my IOC against Michael Davidsaver’s Debian packages (https://epics.nsls2.bnl.gov/debian/
) and the packages provide everything under /usr/lib/epics/ The Debian packages must also install the asyn header files, probably in /usr/include/epics. Look at asynDriver.h, it should contain lines like the following: #define ASYN_VERSION 4 #define ASYN_REVISION 39 #define ASYN_MODIFICATION 0 Let me know what version it is. Since your streamDevice is more than 7 years old I suspect that asyn is very old as well. If so, there have been quite a few fixes to the asyn VXI-11 support
since 2013. I suggest you build a test IOC with the latest version of asyn and streamDevice and see if he problem still occurs. You should probably enable all of the asyn trace flags on that driver, i.e. set the trace mask to 0xFF. There may be some hints as to the timing issues if you do that. Mark From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Hu, Yong via Tech-talk Hello everyone, I have a simple StreamDevice protocol for an old GPIB-based device HP3458A which is connected to Agilent E5810 LAN/GPIB Gateway (100 Mbps) talking to a softIOC. Here is the record to read the voltage data
at 0.2Hz (5 second). #only showing the must-have fields record(ai, "SR:C03-BI{DMM:1}V-I_") { field(DTYP, "stream") field(INP, "@hp3458a.proto ReadData L0 6") field(SCAN, "5 second") } #StreamDevice protocol ReadData { out "DCV 10, 1E-6"; in "%f"; } And this is the EPICS shell output after I turn on the Asyn trace.
2020/07/07 17:55:46.280 L0 6 vxiWrite DCV 10, 1E-6 2020/07/07 17:55:49.630 L0 6 vxiRead -4.016502336E+00 2020/07/07 17:55:52.396 L0 6 vxiWrite DCV 10, 1E-6 2020/07/07 17:55:55.756 L0 6 vxiRead -4.015675668E+00 2020/07/07 17:56:00.680 L0 6 vxiWrite DCV 10, 1E-6 2020/07/07 17:56:04.030 L0 6 vxiRead -4.014579704E+00 I get the expected response (i.e. -4.016502336E+00) after the command (DCV 10, 1E-6) is sent. However, as you see from the timestamps for each vxiWrite, the command is not sent at every 5-second. It takes
more than 5 seconds and it has a pattern: 6.116, 8.284, 6.116, 8.284, …. ; the response time (vxiRead – vxiWrite) is consistent at 3.35 seconds although it seems ridiculously slow.
So, the system is slower than expected. However, I am surprised that there is no any alarm for the record and no any warning message from the EPICS shell output when that record can not keep up its scanning
rate. Is this kind of silence supposed to be? Just to be clear, the softIOC itself and the physical server are perfectly fine: I added the classical “dbExample1.db” and its calc record can be scanned at exactly 5-second. This system used to work as expected at 0.2Hz (5 second) despite it is ridiculously slow. Now it becomes even slower after our ITD upgraded the network switch. If anyone has experience on these old devices
(HP3458A, E5810), please advise what I should do next. If the version of Asyn/StreamDevice matters for this case, here we go: epics> dbior Driver: drvAsyn L0 multiDevice:Yes canBlock:Yes autoConnect:Yes vxi11, host name: 10.0.132.67 Driver: stream StreamDevice 2.6.0 built May 29 2013 18:45:57 registered bus interfaces: DebugInterface DummyInterface AsynDriverInterface PS: I had difficulty finding the exact version number of asyn/streamdevice since I built my IOC against Michael Davidsaver’s Debian packages (https://epics.nsls2.bnl.gov/debian/
) and the packages provide everything under /usr/lib/epics/. I am sure there are many ways (ldd, strings, configure/RELEASE, etc.) to find out the version number of EPICS support module. I just found “dbior” seems a handy tool for reporting EPICS driver’s
version. I am not sure if Mark Rivers has added this kind of report in his latest Asyn release. Best regards, Yong Hu NSLS-II Controls Group |