Read serial data from multiple machines via TCP/IP

[mattcg1]

Hi All,

Labview very newbie here. Background is very strong in AB and Siemens PLCs.

I have to read and log RS-232 serial machine data into a Labview PC via Ethernet.

Currently, I have six process machines on the floor, using AB SLC PLCs. We print locally to a serial printer via AB BASIC module serial port, ASCII mode, at 9k6 baud, no handshaking. There are plans to double the number of machines to 12 by end of '06. The goal is to eliminate the troublesome local printers and capture and archive all process report data electronically.

Each print line in the report can vary from 10-40 ASCII characters in length. Number of lines and print interval varies- start of process report may print 30 lines, in process report may print 1-3 lines at a time interval from 30 seconds to 5 minutes, 3 line alarm prints as occuring, and end of process report 40 print lines.

My plan is to use a RS-232 splitter to pick off the serial data to printer. I plan to then take the data into a serial-to-Ethernet converter (B&B Electronics or Lantronics -is either better?).

Labview must listen to PC port, and when a specific start of process control character is detected from the unique IP address, begin logging serial data to file. After a specific end of process character is detected, or data comms tineout, close file. Then, listen for next start of process character from that machine and repeat. Note: All machines may be running simultaneously.

My questions:

1. Is this a sound approach using Labview?

2. What is most effiecient way to configure a Labview TCP server to listen to a user-selected number of Ethernet devices; i.e. define the individual IP address from LV control panel as additional machines are brought on-line. Do I simply replicate the code, or can this be done programatically?

3. Beside "loss of comms timeout alarm", what are other commonly used error detections for this type of app?

4. Are there any big "gotchas" using the TCP Simple Data Server example as a starting point?

Any experience or guidance will be appreciated.

mark

[jpdrolet]

I think that the Lantronics has drivers to install the Ethernet-serial adapter as a local serial port so you keep using a serial port in your application. However, there was a silly problem that prevent it to work properly since it was parsing the sting output of some command and it didn't work with a non-English OS. Maybe they solve their problem now.

[Mike Ashe]

If you have a dozen or less machines/IPs at the data rates you mention, then you can probably get away with the simple data server example type, with a few small mods/enhancements. Longer term you might want to think about something a little more flexible and robust.

The semi-standard method to do that these days is to make a TCP Listener that waits for connections and then spawns off a copy/template of a single link handler. Each handler services the incoming data from one of your machines and feeds the data into a LabVIEW Queue. Elsewhere in your application you have a VI that takes all the data out of the queue and logs it, performs statistics, display, etc.

For the Handlers you have a choice of making physical copies of a re-entrant VI or using templates (*.vit) or GOOP instances.

For an example of the GOOP version and some nifty free code, look here on the forums for TCP server. I'll try to directly link OpenGOOP TCP Server Topic

Cheers, Mike

[WMassey]

Hi All,

I plan to then take the data into a serial-to-Ethernet converter (B&B Electronics or Lantronics -is either better?).

I don't know about either of those interfaces but I had had good experiences with National Instruments NI ENET-232/4 and it would only stand to reason that they (NI) would make an effort to make it compatible with the LabVIEW. After installation it just shows up in MAX as additional serial (COM) ports and you talk to it using the ordinary VISA serial routines. In one situation I'm using 6 ports (2 interfaces off of a hub on a private network) and it has been fast and trouble-free. I like it.

[mattcg1]

Thank you, jpdrolet, Michael, and WMassey. You've given me a good start with your comments!!

mark

[Rolf Kalbermatter]

I don't know about either of those interfaces but I had had good experiences with National Instruments NI ENET-232/4 and it would only stand to reason that they (NI) would make an effort to make it compatible with the LabVIEW. After installation it just shows up in MAX as additional serial (COM) ports and you talk to it using the ordinary VISA serial routines. In one situation I'm using 6 ports (2 interfaces off of a hub on a private network) and it has been fast and trouble-free. I like it.

They are very nice, but if you happen to have a Hyperthreading machine, you definitely need to install the latest drivers. We were having some problems begin of last year with those Enet-232/4 on a Hyperthreading machine after the older computer had died, and no matter what we tried we had to dust of some other non-Hyperthreading machine to run our application without intermittant crashes. It took about half a year before a new driver was available. However I haven't tested it until now, since the old machine is runnig just fine and I don't like to make modification to a running production system.

Rolf Kalbermatter

[WMassey]

They are very nice, but if you happen to have a Hyperthreading machine, you definitely need to install the latest drivers. We were having some problems begin of last year with those Enet-232/4 on a Hyperthreading machine after the older computer had died, and no matter what we tried we had to dust of some other non-Hyperthreading machine to run our application without intermittant crashes. It took about half a year before a new driver was available. However I haven't tested it until now, since the old machine is runnig just fine and I don't like to make modification to a running production system.

Rolf Kalbermatter

The drivers (NI Serial v1.7) that shipped with the units did have their problems.

This is the behavior I saw (in July, 2005):

Problem Description :

Using LabVIEW and a ENET-232/4 connected to a WinXP PC on a private

ethernet through a hub I can establish communications and continuously talk

to an instrument for as long as I want. But if I pause the exchange between

the PC and the instrument for more than about a minute then the "Port 1"

light(the port in use - no others used at this time) on the ENET-232/4 goes

out and the Labview VISA will generate an error when an attempt is made to

resume communication. I have to reinitialize the VISA serial port before I

can get the "Port 1" light back and communication can be re-established.

I complained to NI and they responded quickly with NI Serial v1.8 and that cleared up all the problems that I knew about and I'm running it on a system with a hyperthreading 3.2GHz Intel CPU.

I just did a quick check of the NI Serial download website and see that the drivers listed there jump from 1.8 up to 3.0. I have not tried 3.0.

Were the problems you were referring to fixed in the 1.7-to-1.8 change or the 1.8-to-3.0 change?

[Rolf Kalbermatter]

The drivers (NI Serial v1.7) that shipped with the units did have their problems.

This is the behavior I saw (in July, 2005):

Problem Description :

Using LabVIEW and a ENET-232/4 connected to a WinXP PC on a private

ethernet through a hub I can establish communications and continuously talk

to an instrument for as long as I want. But if I pause the exchange between

the PC and the instrument for more than about a minute then the "Port 1"

light(the port in use - no others used at this time) on the ENET-232/4 goes

out and the Labview VISA will generate an error when an attempt is made to

resume communication. I have to reinitialize the VISA serial port before I

can get the "Port 1" light back and communication can be re-established.

I complained to NI and they responded quickly with NI Serial v1.8 and that cleared up all the problems that I knew about and I'm running it on a system with a hyperthreading 3.2GHz Intel CPU.

I had this same problem starting in November 2004 and going on until February 2005 when NI told me that NI-Serial 1.8 would be going to fix it but won't be released before second half of 2005. It took quite some time to get a prelimenary fix which came with the warning that it "might" fix the problem. Unfortunately it didn't fully and no matter what I tried including disabling hyperthreading in the BIOS did not help so we had to find an older non-hyperthreading machine and install everything on there. I haven't since bothered with that machine.

Rolf Kalbermatter

[mattcg1]

Thanks for followup Rolf and Warren.

mark