Read data from instrument that sends XML files via ethernet?

[Bronte02]

Regarding the protocols, this is the reference I was given:

https://ludlums.com/images/product_manuals/M375_Webpage_and_Supervisor_Service_Software.pdf

It's the user manual of a software sold by the company appositely to communicate with the detector and display data, so it doens't tell you everything step by step, but I was told by customer support that it should be possible to do everything with LabView, and I would find information about data format here.  The XML part is the only "data format" information I was able to find here, and it is in Section 11 - Troubleshooting at page 116.

Thank you for any suggestion you may have

[Mark_Yedinak]

No, just because ping works that does not mean that there aren't firewalls blocking specific traffic. Ping just let's you know that you have connectivity between the two devices on the network. Ping uses the ICMP protocol which is generally not blocked by firewalls. In some cases it is though but that is more the case for external networks, not internal ones. Firewalls work to block specific protocols and specific ports on those protocols. Default security on PCs will often only enable a few of the most common ports such as port 80 (HTTP). I would venture to guess that if you can ping but cannot establish a connection (assuming your are using the correct IP address and port number) then it is a firewall issue which is blocking the traffic.

From the looks of the document above you may need to get creative with your reading. What I have done in the past when there is an unknown number of bytes expected is to create a VI which would read a single byte from the TCP connection with a longer timeout value. Once a byte has been received I read larger chunks of data with a short timeout. I continue reading until I get a timeout and then I assume that is the end of the data. It appears this device will send data every 2 seconds so this approach would work nicely. It looks like you will need to parse the XML yourself which is pretty straightforward using some of the existing XML toolkits or the basic processing string VIs. Using Match Regular Expression would be pretty easy on this data.

[Bronte02]

Ok, I asked for help to the customer service of the device, and I finally got it: I had to set the Supervisor Primary and Secondary IP addresses correctly in the ethernet settings page of the instrument.   

Also, they told me that the proper LabView function to use would be "listen", as I originally guessed, and not "open connection".

I did this and it works just fine.  Now I only have to figure out how to get the data I need from the file, but I guess I can do it thanks to your previous suggestion.

Thank you very much for your help, I will let you know if I have any other problem 🙂

[wiebe@CARYA]

---

@Bronte02 wrote: 

<?xml version="1.0" encoding="us-ascii" ?>

<area_monitor rev ="1.0" serial="12345">

  <status>

    <rate>9999.9</rate>

    <raw>9999999</raw>

    <units_code>99</units_code>

    <audio>1</audio>

    <alarm1>1</alarm1>

    <alarm2>1</alarm2>

    <over_range>1</over_range>

    <monitor>1</monitor>

    <error_code>9</error_code>

  </status>

</area_monitor>

---

With 'simple' XML strings like this, you don't need to go full XML parser.

A simple Reg.ex. will get you those numbers, and very likely a lot faster (in both dev. time and execution time). And it's much less prone to memory leaks...

For instance, "<rate>([^<]+)</rate>" will return the string of the rate in the first capture group. Note that this will not work for every XML string, as nodes with the same name can in general be nested, but in this situation, it's OK.

Note that the second option will parse faster, but is less flexible. For a HW device, I'd not be too concerned about the order changing, but if there's no need for speed, you could go for safety.

[Bronte02]

Thank you, that's exactly what I was thinking about. The file I'm getting from the TCP Read function is a string, so the easiest thing I can do with it is treat it as plain text and get what I need from it.

The only doubt that I have is how I can do it if the string is continuous, as it seems to be my case. Is the solution that you suggested feasible anyway, putting it into a while loop, or do I have to look for something else?

[Omar_II]

---

@Bronte02 wrote:

Thank you, that's exactly what I was thinking about. The file I'm getting from the TCP Read function is a string, so the easiest thing I can do with it is treat it as plain text and get what I need from it.

The only doubt that I have is how I can do it if the string is continuous, as it seems to be my case. Is the solution that you suggested feasible anyway, putting it into a while loop, or do I have to look for something else?

---

Are your reading a file or reading TCP packets as the just transmitted?

If you are reading a file that is automatically updated from your instrument, that is not an easy task to update in LabVIEW on the fly without getting new data mixed up with old data from an ever growing text file.

Or you could just wait until it is all done and then loop through the complete text file just once.

If your goal is the update in LabVIEW on the fly as it is happening reading the packets one at a time is the way to go. Read a Packet parse it. Read the next packet parse.

From the start of your question I thought that was the goal and not use a file at all.

Skip the file and read the TCP packets directly in LabVIEW. No file.

[Omar_II]

Post an example of the file

[wiebe@CARYA]

I assume with "file" you mean "data" or "record", not a file in the OS's filesystem? That would need some explaining in the current context.

---

@Bronte02 wrote:

The only doubt that I have is how I can do it if the string is continuous, as it seems to be my case. Is the solution that you suggested feasible anyway, putting it into a while loop, or do I have to look for something else?

---

The provided solution will still work, on the backend.

First, I'm thinking the same as Omar_II. The device will send TCP\IP packages, and I'd say each string is in one package. So when reading the data, set it to read packages (Immediate, I think OTOMH). That would give you each package one by one.

If that doesn't work, you'll need to get all data. Then attach that data to previous remaining data. Then clip the first package(s) from the data. Use the last package for most current values. Pass the remaining data to the next iteration... Something like this is often needed (and succefully used) for RS232 devices.

[Bronte02]

Yes, by "file" I meant just "data", I wrote that answer in a hurry and used the wrong word, sorry for the misunderstanding! 🙂

Thank you for your kind replies. Actually I know only these 2 facts regarding the data format: 

-On the manual they say that "when the area monitor establishes a connection, a data message will be sent every two seconds in the form of an XML document".

-In LabView I'm using the TCP Read function to read the data from the instrument, and this function ony gives a string as "data out". So when I assign an indicator to this terminal, what I see on the display is a continuous text with no separation between the different "files". I don't visually see any identificaton of different "data messages", as the manual calls them... Of course I know how to recognize them from the data format example I posted at the beginning of this thread, but I'm not sure whether LabView is able to perceive them as different packages or not. 

So my question is: if I enter a while loop after the TCP Listen, what does every iteration correspond to, in terms of data received? A generic amount of characters, depending on the connection speed, a precise amount of characters, or a whole "data message"?

For me it would be best to have a real-time reading of the data, so I can both save and display them, but also saving them first and reading them in a second time would be acceptable, as my priority is to keep a record of the data received during acqisition for further elaboration.

[Mark_Yedinak]

What I would do in your situation is have your code wait on the TCP Read with a timeout of -1 and a byte count sufficiently large enough to fit the complete data. Based on what you posted earlier 500 bytes would probably be enough. I would set the read to use immediate data, meaning as soon as some data is there it will return it. Since your device is only sending data every 2 seconds you will receive a complete XML package with each read. You then pass that off for parsing and processing.

Another way you can handle this is to have a TCP read with a timeout of -1 and read 1 byte. Once that read is satisfied do a second read with a short timeout, for example 50 ms, and a number of bytes large enough to fit your data. Again, when that read completes you should have your complete XML data set. Put all this in a loop and you will continue to read the data from the device. Use some error checking to determine if the device has disconnected and then you could go back to listening for a new connection.