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: TCP to LabVIEW TCP VI using Stream Device. |
From: | Daniel Cuneo via Tech-talk <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 21 Jul 2020 15:37:46 -0700 |
> 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>
Sent: Tuesday, July 21, 2020 2:03 PM
To: Mark Rivers
Cc: Hu, Yong; 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>> 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>> on behalf of Hu, Yong via Tech-talk <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>> on behalf of "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>>
Reply-To: Daniel Cuneo <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>" <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