From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can´t read page containing XML using GET HTTP Document

Hello forum users, 

 

I'm have a problem with the LabVIEW Internet Toolkit and I'm woundering if its me that is doing something wrong or if it is a limitation of the VI. 

 

I have a robotic application which comunicates with LabVIEW via internet. 

 

the robots sends and receives information via XML which is posted on a webpage. 

 

I've been trying to use the LabVIEW Internet Toolkit's GET HTTP Document. while I can obtain HTML data from any webpage when I try to access my webpage containing XML data  I get an Error 66 (connection closed by peer message).

 

What is even stranger is that on two distinct occasions the program returned the XML data 

 

The page is set up so that when accesed (for example http://192.168.0.102:4950/move.cgi?op=setVel&vel=300). It will define the robot's speed at 300 mm/s and return a page with a simple XML data such as

 

<result>true</result>

 

When I access the page in using the Get HTTP Document, the request is sent. the robot does the action required but the XML data I need isn't returned. 

 

 

I have applications that do this in C++, python, and MatLab, without a problem and I didn't want to have to resort to low level TCP/IP functions. 

 

 

 

any suggestions???

 

Is this a limitation of the GET HTTP Document VI (it only gets HTML documents)

 

Thanks in advanced

 

 

 

 

Bruno Noronha

Certified LabVIEW Associate Developer





Using LabVIEW 8.6
0 Kudos
Message 1 of 4
(3,209 Views)

Is it possible that the other side is actually terminating the TCP connection?

 

You could try using the Datasocket Read primitive (append [text] to the URL to get the data back as a string), but I don't know if that will work any better. You can also dig into the VI to see exactly when the error is generated or try using packet sniffers to follow the traffic and see exactly when the connection is closed.


___________________
Try to take over the world!
0 Kudos
Message 2 of 4
(3,182 Views)

I know for a fact that the connection is not being terminated on the other side.

 

I read here  that the Internet toolkit 6.0 has a known issue where the VIs don't function well when the web page contains CGI commands (which is my case).

 

I tried to run the patch for my Internet Toolkit 6.02 and it says that it wasn't installed properly.

 

 

Thanks for the help 😃 

 

Bruno Noronha

Certified LabVIEW Associate Developer





Using LabVIEW 8.6
0 Kudos
Message 3 of 4
(3,137 Views)

 

Hi, Bruno.
Maybe my case will help you. I've faced a problem similar than yours. I have a network camera whose API is HTTP based, I mean, I can control it using HTTP requests, i.e. http://myserver/axis-cgi/bitmap/image.bmp
takes a picture and returns it in bmp format.
There are other requests that can send data back, i.e.
http://<servername>/axis-cgi/com/ptz.cgi?query=position
retrieves pan and tilt degrees and zoom value (it is a PTZ camera or pan-tilt-zoom, it has two joints that rotate left-right and up-down, and a zoom). In this case, the information is sent in plain text. But I had like you an error 66 in TCP Read.vi.
After debugging "Get HTTP document.vi" I noticed this information is sent back, but due to the error in "TCP Read.vi", it's not transmitted to the remaining TCP functions in execution order, and finally is lost.
In order to debug "Get HTTP document.vi" you'll need to unmark "Reentrant execution" and mark "Allow debugging" in VI Properties->Execution.
The information string enters "TCP Read.vi" by the terminal "buffer in", and leaves it by "buffer out". The next function, "TCP Read Stream.vi" receives also this string, but it's lost in case there's an error in the entry error cluster. So I removed the wire the connects this two TCP VIs, and finally got the string at the "content" terminal.
It may not be the most orthodox solution, but at least it let me continue working. If anybody has fixed this issue conveniently, it'd would interesting to share it with us.
Regards,
Francisco
PS. I was with an internship in USP (Sao Carlos, Brazil) for three months in 2007. In this time I visited many times Campinas and its university. Nice place and really good moments :

Hi, Bruno.


Maybe my case will help you. I've faced a problem similar than yours. I have a network camera whose API is HTTP based, I mean, I can control it using HTTP requests, i.e.

 

http://myserver/axis-cgi/bitmap/image.bmp


takes a picture and returns it in bmp format.


There are other requests that can send data back, i.e.

 

http://<servername>/axis-cgi/com/ptz.cgi?query=position

 

retrieves pan and tilt degrees and zoom value (it is a PTZ camera or pan-tilt-zoom, it has two joints that rotate left-right and up-down, and a zoom). In this case, the information is sent in plain text. But like you I got an error 66 in "TCP Read.vi".


After debugging "Get HTTP document.vi" I noticed this text information is sent back, but due to the error in "TCP Read.vi", it's not transmitted to the remaining TCP functions in execution order, and finally is lost.


In order to debug "Get HTTP document.vi" you'll need to unmark "Reentrant execution" and mark "Allow debugging" in VI Properties --> Execution.


The information string enters "TCP Read.vi" by the terminal "buffer in", and leaves it by "buffer out". The next function, "TCP Read Stream.vi" receives also this string, but it's lost if there's an error in the entry error cluster. So I removed the wire that connects this two TCP VIs, and finally got the string at the "content" terminal.


It may not be the most orthodox solution, but at least it let me continue working. If anybody has fixed this issue conveniently, it'd would interesting to share it with us.


Regards,

Francisco


PS. I was with an internship in USP (Sao Carlos, Brazil) for three months in 2007. In this time I visited many times Campinas and its university. Nice place, nice people and really good moments 🙂

0 Kudos
Message 4 of 4
(2,994 Views)