Experimental Physics and
Industrial Control System

On Jul 8, 2020, at 1:57 PM, Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> wrote:

You might get some clues about what (else) is going on by turning
on more asyn debugging detail and setting TPRO.  I'd be interested
to know where exactly the time is being spent.  (probably a recv() )

If anyone has experience on these old devices (HP3458A, E5810), please advise what I should do next.

As it happens, this combination is in use at LBNL.  It's a weird
old device (in firmware at least) with some odd defaults.  eg.
by default it ignores the EOI line (cf. the "END" command).
You might also want to read about "INBUF ON".

When setting up, I also had a problem with latency.  In this case, when
trying to coordinate fast readout of two DMMs.  (it seemed to work fast
enough with one)

Unfortunately, I didn't spend the time to identify a root cause.
This was for a single measurement, and I was able to write a short
python script to cycle through the necessary commands in sequence.
This script ran fast enough (~5-10Hz I don't remember exactly)

My python was strictly single threaded, so my impression is that
this slowdown was due to contention of some kind.

This script is

https://github.com/mdavidsaver/dmm_hp3458a/blob/devel/take2/scan.py

If you want to use the IOC, you might start by looking at Wayne's
subsequent changes.

https://github.com/waynelewis/dmm_hp3458a


On 7/8/20 6:38 AM, Hu, Yong via Tech-talk wrote:

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