Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> · Tue, 21 Jul 2020 22:49:15 +0000

You can also load an asyn record and use the asynRecord OPI screens to send and receive messages for testing.

If you do these commands at the iocsh shell or in your startup script you will see all the traffic. port is the name you gave the drvAsynIPPort.

asynSetTraceIOMask port 0 TRACEIO_ASCII

asynSetTraceMask port 0 TRACEIO_DRIVER

This command will turn on debugging in StreamDevice.

var streamDebug 1

I should think that StreamDevice would work with the HTTP protocol specifier, but I can't say that I have tested it.

Can you send the IOC output when you get the timeout errors?  I would like to see where they are coming from.

Mark

________________________________
From: Daniel Cuneo <dpcuneo at lbl.gov>
Sent: Tuesday, July 21, 2020 5:37 PM
To: Mark Rivers
Cc: Hu, Yong; tech-talk at aps.anl.gov
Subject: Re: TCP to LabVIEW TCP VI using Stream Device.

Hi Mark,
Your HTTP protocol idea almost works.
I'm using Stream and not sure that stream is working with the HTTP feature properly, since I am still getting timeout errors.

However, if i do not load my records, and only create the port with drvAsynIPPortConfigure using the HTTP protocol,
I have success with asynOctetConnect(), asynOctetWrite and an asynOctetRead.

Perhaps using Stream will not be possible.

Cheers

On Tue, Jul 21, 2020 at 12:19 PM Mark Rivers <rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu>> wrote:
> It appears that the LabVIEW TCP server, is expecting the TCP connection to close after the command is sent.
> Only then does the server respond with the data for the query.

How does the IOC read that response if the socket has been closed?

The drvAsynIPPort driver has a protocol option HTTP: https://epics-modules.github.io/master/asyn/R4-40/asynDriver.html

HTTP -- Like TCP but for servers which close the connection after each transaction.

You could try that, rather than the default TCP protocol.  I think that closes the connection after it receives the response.

Mark

________________________________
From: Daniel Cuneo <dpcuneo at lbl.gov<mailto:dpcuneo at lbl.gov>>
Sent: Tuesday, July 21, 2020 2:03 PM
To: Mark Rivers
Cc: Hu, Yong; tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>
Subject: Re: TCP to LabVIEW TCP VI using Stream Device.

Gm and thank you Mark and Yong for your help.

My coworker has helped me to understand the differences between a working netcat and the IOC.
It appears that the LabVIEW TCP server, is expecting the TCP connection to close after the command is sent.

Only then does the server respond with the data for the query.

I'm going to ask the LabVIEW developer to fix this. However, it would be nice to get my IOC working with the TCP server as-is.

Is there a way to break the TCP connection after the command is sent ?
I think I would also need to disable autoConnection in the call to  drvAsynIPPortConfigure.

Cheers,
dpc

On Mon, Jul 20, 2020 at 3:58 PM Mark Rivers <rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu><mailto:rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu>>> wrote:
This is a good time to load an asynRecord into your IOC and open the OPI display for it.  You can then interactively send commands and look at the response, changes the EOS terminators, and turn the debugging on and off.

https://epics-modules.github.io/master/asyn/R4-40/asynRecord.html

Mark

________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov><mailto:tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov>>> on behalf of Hu, Yong via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov><mailto:tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>>
Sent: Monday, July 20, 2020 5:41 PM
To: Daniel Cuneo; Eric Norum via Tech-talk
Subject: Re: TCP to LabVIEW TCP VI using Stream Device.

Hi Daniel,

Add these two lines in your startup script or type them in the EPICS shell:

asynSetTraceMask("your-asyn-port",-1,0xff)

asynSetTraceIOMask("your-asyn-port ",-1,0xff)

And you will see what is really going on. Post more debugging messages so that other people probably can help you figure out the issue.

Good luck!

Yong

From: Tech-talk <tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov><mailto:tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov>>> on behalf of "tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov><mailto:tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>" <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov><mailto:tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>>
Reply-To: Daniel Cuneo <dpcuneo at lbl.gov<mailto:dpcuneo at lbl.gov><mailto:dpcuneo at lbl.gov<mailto:dpcuneo at lbl.gov>>>
Date: Monday, July 20, 2020 at 6:08 PM
To: "tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov><mailto:tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>" <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov><mailto:tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>>
Subject: TCP to LabVIEW TCP VI using Stream Device.

Hello all,

My co-worker has setup a TCP virtual interface in LabVIEW, that allows me to send commands

as strings of text, and get replies with data.

Testing in a Linux shell using netcat (nc on CentOS 7) works well.

echo "foobar\r" | nc -h hex.dump labview-host.foo.bar

However, when I attempt to use Stream / Asyn, I get only timeouts.

Stream and asynOctetWriteRead()  both timeout.

One would usually suspect that the line terminators are incorrect. To test line terminators, I turned on the netcat hexdump and can see both a CR and LF (0xD 0xA) being sent in a working netcat test. I put both in my stream protocol file and hard coded when using asynOctetWriteRead.

I'm beginning to wonder if there's a protocol difference between what netcat does and what a generic TCP connection does.

Does anyone have advice on what else I can try to tease out the problem ?

Cheers and TIA !

dpc

--

Daniel Cuneo

ALS Accelerator Controls

BLD 46-172G

desk: 510-486-5439

cell:   415-871-1909

--
Daniel Cuneo
ALS Accelerator Controls
BLD 46-172G
desk: 510-486-5439
cell:   415-871-1909

--
Daniel Cuneo
ALS Accelerator Controls
BLD 46-172G
desk: 510-486-5439
cell:   415-871-1909

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System