Hi Ana,
I notice you have set the NELM field of the waveform record to 32000. That is larger than the default value of EPICS_CA_MAX_ARRAY_BYTES, which is 16K. You need to set the
value of the environment variable EPICS_CA_MAX_ARRAY_BYTES to a value larger than 32000 on both the IOC process and any EPICS channel access client process.
If that does not fix your problem then I would suggest the following:
- Create the drvAsynIPPort driver
- Open an asyn record to the driver
- Use the medm asynRecord.adl and asynOctet.adl screens
- Turn on ASYN_TRACEIO_ESCAPE and ASYN_TRACEIO_DRIVER
- Using the asynRecord send the command “GET /data”
- Look at the asynTrace output to see what was sent and what was received.
Mark
Thanks for the help - so I've tried both approaches (using pcaspy to set up an IOC, and alternatively using HTTP in IPPortConfigure for my streamDevice application) and am running into a stumbling block with
both.
The problem is that when I request the data I always get an array of 0's back. Here's the syntax I'm using in the streamDevice IOC (and I know the HTTP commands are correct because they work in a telnet session):
===device.proto file===
getData {
out "GET /data";
in "%\$1[^\r\n]";
ExtraInput = Ignore;
}
====device.db file===
record(waveform, "$(P)$(R)Data")
{
field(DESC, "Data array")
field(DTYP, "stream")
field(INP, "@devREDPITAYASTREAM.proto getData(20000) $(PORT) $(A)")
field(PINI, "YES")
field(FTVL, "CHAR")
field(NELM, "32000")
}
For the pcaspy version, I have taken the tutorial file pysh.py, which creates an IOC that processes shell commands (https://code.google.com/p/pcaspy/source/browse/example/pysh.py)
and modified the OUTPUT to be of datatype "char" with a large count. I have httpie installed, which is a library allowing me to run the command 'http
10.95.101.75/data' on the command line to retrieve the data. However, when I do 'caput MTEST:COMMMAND "http
10.95.101.75/data" and then 'caget MTEST:OUTPUT', I get an array of zeroes back.
Does anything pop out as immediately suspicious?
On Mon, Feb 9, 2015 at 12:58 PM, Kasemir, Kay <[email protected]> wrote:
What Mark suggests could work, but the HTTP protocol is somewhat verbose and the exact response of the server could vary.
To emulate
> curl http://10.95.101.75/bazaar?start=spectrum
you could try to send
GET bazaar?start=spectrum HTTP/1.1\n\n
.. and then ignore the response.
To emulate
> curl http://10.95.101.75/data
you could try to send
GET data HTTP/1.1\n\n
and then you need to be prepared to parse a response that looks like
HTTP/1.1 200 OK
Content-Type: text/html
Server: Whatever
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 97
.. the actual data..
You should try those GET commands from a plain telnet session to the server to see the exact response.
It might be easier to use for example python with urllib2 to communicate with the device, and then see the recent tech-talk discussion on how to get from python to EPICS:
* Use CA client library to write values from Python to a "real IOC"
* Use CA server library to serve the values from Python, i.e. it's like an IOC
* Serve data from python via a simpler TCP socket protocol, read into IOC via stream device.
Thanks,
Kay
On Feb 9, 2015, at 3:02 PM, Mark Rivers <[email protected]>
wrote:
> This command should be:
> drvAsynIPPortConfigure("L0","10.95.101.75:80 HTTP",0,0,0)
> The HTTP means that drvAsynIPPort will handle the fact that the server will disconnect after each transaction.
>
> You can’t use the “curl” command in your protocol. You need to send the actual commands that the HTTP server requires.
>
> It might be something like
> getData {
> out "get data";
> in "%\$1[^\r\n]";
> ExtraInput = Ignore;
> }
> Mark
>
>
>
> From: [email protected] [mailto:[email protected]] On Behalf Of Ana Malagon
> Sent: Monday, February 09, 2015 1:53 PM
> To: [email protected]
> Subject: using EPICS code with HTTP port
>
> Hi,
>
> I'm trying to use EPICs with a digitizer (www.redpitaya.com) which has a web interface - I can get the information using curl to download the website information:
>
> curl http://10.95.101.75/bazaar?start=spectrum
>
> curl http://10.95.101.75/data
>
> but I'm a little confused about how to integrate these commands in an ioc. I've set up a StreamDevice template, and I thought I might be able to just send the curl commands by putting them in a record:
>
> record(bo, "$(P)$(R)Start")
> {
> field(DESC, "Start App")
> field(DTYP, "stream")
> field(OUT, "@devREDPITAYASTREAM.proto startApp $(PORT) $(A)")
> field(ZNAM, "spectrum")
> #field(PINI, "YES")
> #field(VAL, "1")
> }
>
> record(waveform, "$(P)$(R)Data")
> {
> field(DESC, "Data string")
> field(DTYP, "stream")
> field(INP, "@devREDPITAYASTREAM.proto getData(20000) $(PORT) $(A)")
> field(PINI, "YES")
> field(FTVL, "CHAR")
> field(NELM, "32000")
> }
> with the corresponding entries in the .proto file being:
> startApp {
> out "curl
http://10.95.101.75/bazaar?start=%{spectrum}";
> }
> getData {
> out "curl http://10.95.101.75/data";
> in "%\$1[^\r\n]";
> ExtraInput = Ignore;
> }
> When I run st.cmd, the host is configured to be the IP address of the red pitaya itself, using the HTTP port of 80:
> drvAsynIPPortConfigure("L0","10.95.101.75:80",0,0,0)
> I'm not sure if this is the right thing to do? In any case, when running st.cmd with asynTraceMask enabled I get a continuous stream of "reads"
> 2015/02/09 11:48:23.530 10.95.101.75:80 read.
> but it doesn't seem to respond to the commands I've made.
> Does anyone have any feeling for using Epics with HTTP commands?
> Thanks!
> Ana Malagon
|