IPASCII Response fails every other poll.

[haroldc_gtmc@sbcglobal.net]

IPASCII Driver object is used to retrieve (via Ethernet) data.

Request format works good.

My Request Format (RequestFormat):

"GET /data HTTP/1.0 \r\n\r\n" as per device manufacture Txt string and
(2) carriage return/line feeds

Response String looks good Object = (.Response)
Typical Response String

F|74.0|29.3|-999.9|74.0|29.3|-999.9|-999.9|-999.9|-999.9|-999.9|-999.9
|-999.9

Data is temperature from module, -999.9 are data inputs without temperature
probes attached...

RSV1.txt = (F)
RSV2.txt = (74.0)
ETC...


RSV1-13 data look good but fails every other poll

(Socket communications error 10053: Software caused connection abort).

[Doug M]

haroldc_g,
You probably need to make sure your ResponseFormat string matches exactly what you are receiving because it sounds like Lookout isn't recognizing the end of the response.  You may want to start with receiving the entire response into one datamember by specifying the RepsonseFormat as "%s" and seeing if that works first.  Then add things to your ResponseFormat string to parse the individual members.  The help file on the IPASCII object has some great examples on format strings.

[haroldc_gtmc@sbcglobal.net]

Additional to original help request

I have tried the "%s" string request as recomended,  returns the same data as my response format (shown below),  fails every other poll...

My response format is "%1s|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f|%6.1f".

The response string can vary in length depending on the actual temperature data returned, would this have an effect on the response expectations?

[Doug M]

harold,
If what you mean by length of response string is that the temperatures can be of different number of characters, then you should be ok because you are requesting a certain width, and even if the temperature is less than that width you should be ok, according to the parsing rules of the IPASCII object.  The main reason it is a good idea to just start with a responseFormat string of %s is that in case you are receiving a "\r\n" at the end of your response without seeing it, this would catch it and also eliminates the parsing as the cause of the problem. But it sounds like you already tried that.  According to the IPASCII help file:

 "Socket communications error

This alarm message is followed by a standard socket error message.  The most common reason you might see one of these errors is if an error has occurred on the socket after a valid socket has already been established."

It is possible that perhaps something else may be disrupting you socket connection, but I would continue experimenting with simplifying the responseFormat string as simply %s until you no longer receive that error message.  Is it possible that your device needs an additional request of some kind to reset itself for another request?

[haroldc_gtmc@sbcglobal.net]

I have received the following response from NI engineers.

To review this issue -- the IPASCII object has a problem in that if you use the IPASCII object to query a web service that closes the 

connection remotely after a request has been made Lookout will not close the local connection.  This results in a "CLOSE_WAIT" 

state for the local TCP port.   Since the port is not closed, Lookout is not able to make a subsequent outgoing connection on the 

same port.  Lookout does appear to close the port when after it tries to make repeated connections, but this means for every time 

you want to make a query you have to alternate between successful queries and comm failures. Most likely this was not found earlier 

because for many Ethernet based instruments, a TCP connection is persistent, however web servers using the HTTP/1.0 protocol 

close the TCP connection after every GET request and response.  A corrective action request has been filed with our Lookout R&D 

team and hopefully a fix will be available in future versions of Lookout.  Thank you for your patience with this issue.

[haroldc_gtmc@sbcglobal.net]

Update:

Wow! NI has repaired the problem with this driver.   You can download the new driver dated  12-13-2005 from NI.

Thanks NI for a fast solution to what would have become an expensive custom driver development.

[Doug M]

Here is the link for Lookout 6.0 updates.  As mentioned on this page, you must install Lookout 6.0.2 before installing the incremental patches, such as the one to fix this particular problem.

Message Edited by Support on 02-04-2009 04:48 PM

[neilius77]

Looks like there may still be an issue with the IPASCII object driver. With the update installed the device responds properly until you add another IPACSII object. Let the application run for four hours with no Com fails with a single device running. As soon as a second device is added to the process Com fails ensue every other poll on one of the objects. Please advise!

[Doug M]

neilius77,

This has been reported to R&D (#3V1ACMG0) for further investigation.  Thanks for the feedback!