RE: Utilizing StreamDevice in conjunction with sockets

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Ø  My startup file does not contain those two commands. If my understanding is correct, aren’t those for instruments containing serial ports? Unfortunately, the instrument in question only has an ethernet.

Ø  I am using 15 s for my timeout.

 

The asynSetInputEos and asynSetOutputEos commands are not just for serial devices, they are for any devices that use the asynOctet interface, including TCP/IP, GPIB, etc. 

 

Did you specify an input or output terminator in your protocol file?

 

The large string you are sending to your device may include terminators within it (CR or LF), so you may not need asyn to add terminators.

 

However, input is a different story.  You have used this as the protocol for reading the response.

 

in “:%s”;

 

Because you have set noProcessEos=0 in drvAsynIPPortConfigure() then you are using the asynInterposeEos interface to read from the device.  That means it will continue to try reading from the device until one of the following is true:

-          It gets the specified terminator.  Because you have not specified a terminator in your st.cmd, then this will not happen unless perhaps you specified an input terminator in your protocol file.

-          It gets the requested number of input bytes.  You have not specified a number of input bytes, so it will be the size of the array, and this condition won’t be met.

-          It times out

 

It seems to me that it is probably timing out waiting for the response.  That could explain why it is taking 20 seconds compared to 5 seconds with a C program: 15 seconds of the 20 is the timeout.

 

Mark

 

 

From: Wang, Andrew <wang126 at llnl.gov>
Sent: Monday, May 17, 2021 6:42 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

HI Mark,

 

My startup file does not contain those two commands. If my understanding is correct, aren’t those for instruments containing serial ports? Unfortunately, the instrument in question only has an ethernet.

 

I am using 15 s for my timeout.

 

Thanks,

Andy

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Monday, May 17, 2021 3:53 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

Does your st.cmd contain these commands?

 

asynOctetSetInputEos

asynOctetSetOutputEos

 

What timeout are you using in your protocol file?

 

The output of asynTrace is likely to be more useful than perf.

 

Mark

 

From: Wang, Andrew <wang126 at llnl.gov>
Sent: Monday, May 17, 2021 5:24 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

Hi Mark,

 

That is correct. It is a string, which contains information that the instrument needs such as what user input the command is directed at, checksum, etc.

 

The response from the instrument will either be OK or ERROR, which will happen if the format of the command is wrong.

 

Thanks,

Andy

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Monday, May 17, 2021 2:54 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

Hi Andrew,

 

Ø  setCmd

Ø  {

Ø                out "%s";

Ø                in ":%s";

Ø  }

 

So the very long command you are sending is a null-terminated ASCII string, and not binary data?

 

What is the response from the device?

 

Mark

 

 

From: Wang, Andrew <wang126 at llnl.gov>
Sent: Monday, May 17, 2021 4:40 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

Hi Mark,

 

Thanks for the reply. Here are some clarifications.

 

1. The network interface speed of the instrument should be around 1 Gb/s.
2. The asyn command I used to create the port was drvAsynIPPortConfigure, which I had in the startup script named st.cmd. Priority, noAutoConnect, and noProcessEos are all set as 0.
3. The waveform record looks like this except I had to modify the record names.

 

record(waveform, “inst_long_cmd")

{

              field(DTYP, "stream")

              field(SCAN, "Passive")

              field(FTVL, "CHAR")

              field(NELM, 1970000)

              field(INP, "@inst.proto setCmd $(PORT)")

              field(FLNK, “another_rec”)

}

 

I have an asub record that creates the command which “inst_long_cmd” sends to the instrument via StreamDevice.

 

4. This is what the protocol for setCmd looks like.

 

setCmd

{

              out "%s";

              in ":%s";

}

 

5. I’ll try perf and asynTrace.

 

Thanks,

Andy

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Monday, May 17, 2021 2:24 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: Re: Utilizing StreamDevice in conjunction with sockets

 

Hi Andrew,

 

> There is one command that I need to send to the instrument occasionally that has a length of around 2000000 chars. 

> Based upon my observations, it takes about 20-30 seconds to send that command through a waveform record and receive a response back through StreamDevice. 

 

We need more information.

 

What is the network interface speed on the device (100 MBit/s, 1 GBit/s, etc.).

 

What is the asyn command you are using to create the asyn port?

 

What does the definition of that waveform record in your database file?

 

What is the Stream protocol you are using to send the waveform record data?

 

> I was wondering if anybody has experienced similar behavior with StreamDevice for very long commands and how to potentially speed it up. 

 

I have used large waveforms with Stream on a few occasions, and I have not seen that Stream was slowing things down.

 

> Should I investigate utilizing asyn or some other drivers, and if so, can it be run in conjunction with StreamDevice? 

 

If you are using Stream then you must already be using asyn as the underlying IP driver. 

 

You should turn on asynTrace to look at the communications with the device, which will include timestamps.

 

asynSetTraceIOMask myPort 0 HEX

asynSetTraceMask myPort 0 DRIVER|ERROR

 

You could easily write a little asyn port driver on top of that driver to send the data.  But that is basically what Stream does, so it is surprising that it is slower than a C socket program. 

 

If the above suggestions don’t offer a hint then you can run the IOC in a profiler like “perf” and see where it is spending its time.

 

Mark

 

 

 

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wang, Andrew via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, May 17, 2021 1:38 PM
To: EPICS tech-talk
Cc: Pogge, James Robert
Subject: Utilizing StreamDevice in conjunction with sockets

 

All,

 

I’ve been using StreamDevice to interface EPICS with some of our instruments and I’ve noticed something interesting for quite some time now. There is one command that I need to send to the instrument occasionally that has a length of around 2000000 chars. Based upon my observations, it takes about 20-30 seconds to send that command through a waveform record and receive a response back through StreamDevice. However, when I use sockets in my C program, it takes about 3-5 seconds.

 

Originally, what I wanted to do was somehow utilize sockets for just that command, while using StreamDevice for the rest of the commands. However, it doesn’t seem to work out since once StreamDevice starts running, I am unable to use sockets in my asub record.

 

I was wondering if anybody has experienced similar behavior with StreamDevice for very long commands and how to potentially speed it up. Should I investigate utilizing asyn or some other drivers, and if so, can it be run in conjunction with StreamDevice? Ideally, it would be nice if I don’t have to migrate from StreamDevice since all the other commands work just fine.

 

Thanks.

Andy