(Off Topic) RS232 <> Ethernet

  • Thread starter Michael R. Batchelor
  • Start date
M

Thread Starter

Michael R. Batchelor

Hi gang, I need a little bit of advice that's Off Topic, but this a good group to ask about industrial controls. I have a customer with a line which has 19 RS232 devices, some test instruments, others material handling devices. Currently we control everything from a NT4.0 box that has a 24 port serial card in it. The actual line is handled by an AB PLC5/40E, but we use a KTX card to get to the PLC via DH+. They are about to do a major product upgrade, and we need to add about a dozen serial devices, which blows the doors off the serial card. What I want to propose is converting all of the serial devices to TCP/IP and move everything to Ethernet. Besides cost, I also see that as a way to have a backup supervisory computer that doesn't require swapping a bunch of cables. The main has only failed once, but it takes a *LOT* of time to get switched over. I've seen a few serial to Ethernet convert modules on the web, but not many. I also see things like the ucsimm and TINI boards. I'm a little reluctant to use a "roll your own" solution like the TINI board because I don't have facilities to fab the finished units. (And we're trying to run a profitable business here.) The devices are not necessarily near each other, so something like a terminal server with lots of serial ports isn't really a good choice. Does anyone have any experience, or observations, about a good path to take here. Or should I just tell the customer to fork up the bucks for the extra serial ports. (In the overall cost of the plant upgrade the serial ports a cheap, but next year if you have to buy one in isolation it's REAL expensive.) Thanks, Michael -- Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc. Linux is like a wigwam... No windows, no gates. Apache inside. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M
You could look at the EM1000, or OP6700 from ZWorld. The EM1000 is a standalone serial<->ethernet modem. The OP6700 can do the same (with a small bit of programming), plus it includes a 4x20 LCD for status info and a 6x2 keypad. Oh, they also supply an http server (for an embedded system? !!), ftp client and server, and smtp. Mark _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Micheal I have done this sort of thing in the IS environment many times for much the same reasons, the server becomes simply one more node and it's much easier to do ADC's (Adds Changes Deletes) or failover. The devices are out there, off the shelf and fairly reliable. To simply replace the multiport serial cards with terminal concentrators is a good and easy first step. You already have the serial lines run to your central location and the cost per port is quite a bit less as the number of serial ports per net node goes up. This would accomplish the one cable replaacement goal you need. Later you can move the concentrators closer to the devices and group them logically. Single and small port count devices are available. I would suggest for sanity's sake you find a single vendor that has the full line. The reason for this is that unlike the UNIX world which supports standard protocols for this, there is no guarantee that for NT any two vendors will use the same proto. Protos are available for standard services like telnet, lp, lpr, etc. but what you will require for transparent replacement of attached serial ports is more along the lines of permenant virtual circuits. This is easy to find or failing that, relatively easy to write for UNIX or Linux as they were designed to support multitudes of serial devices from the very beginning. I'm not sure of the depth of support on NT for this type of service as I don't do NT so be careful that the product software is intended to work like attached serial ports. In my environment I would look very hard at using Linux boxes with Rocketport boards in place of embedded type concentrators as the cost is favorable and the workings would be less occult and any little glitches, (there will be glitches) can be attacked with the full breadth of tools provided. Surprises you can't do anything about have a way of creating nightmares. Having the source at both ends goes a long way to assuring me that I can avoid or at least fix this. If using OTS software you must make sure it is intended or at least well suited for doing what you propose. Stuff that kinda works will haunt you forever. Don't ask me how I know. Things that may be problematic from my experience are that timing is critical for some automation protocols. They would need to be tested on a network that carries some traffic. Many, many devices tend to send each character in a whole packet, indeed this is about the only way you can be truly transparent and this can cause some stacks and devices fits. The network you use for this may want to be isolated from peer to peer NT connections as they talk a lot for no obvious reason. As the cost is very little more I would use 100 mbit ethernet and switches to keep segments collision free. Don't let me dissuade you, doing this succesfully once will give you powerful problem solving and cost saving tools for the nightmare world of large RS232 plants. RS232 and friends are the single most universal "go-between" in an industry that works to prevent "go-betweens". It seems that everyone who is doing a lot of it is doing so for that reason. This is not off topic in my view and is of interest to all in automation and especially those who wish to provide choice. Feel free to continue the thread. Regards. cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Michael R. Batchelor

Curt Wuollet wrote: > > I have done this sort of thing in the IS environment many times for > much the same reasons, the server becomes simply one more node and > it's much easier to do ADC's (Adds Changes Deletes) or failover. That's exactly one of my goals. > The devices are out there, off the shelf and fairly reliable. To Got any recommendations. Send private email if you prefer. As for the code on the supervisory node, we are in complete control of that and can do anything we want. Ergo, the devices do not need to be "transparent serial port replacements" even though this mogt be easier to understand for a new person. My real preference would be a small controller at each device which can download and run a module from a bootp server based on it's mac address. The downloaded code would handle all the necessary handshaking for that particular local device, and broadcast to the server it's IP address so the supervisory node can then attach to a port and establish the channel. Let the embedded controller cook the data for me so that all of the comm between the supervisory node and the embedded device are real data and not stuff like parsing the stream to see that the light curtain is still waiting. That would remove all of the serial port management from my SCADA system, and satisfy all of my needs. In reality, there are a dozen little boards and projects out there that can do this, but then I'm the one in the manufacturing business. Something that's a lot less robust, but will move the physical serial ports onto the ethernet is what I will probably have to settle for. Most of the serial devices are listeners. I.e. they speak only when spoken to. So they really don't ever need to know that there is some device between them and the supervisory node. They just answer the request for action or data made to them. And all of the code on the supervisory node is written by us, so there's no problem modifying it to meet the new needs. In other words, we're the ones doing all of the initiating. The idea of a linux box with a multiport card is appealing in a way, but would probably not be accepted by the end customer. Despite the fact that his IS group is probably more capable of configuring that, he's going to want to see something that comes in a box from a vendor. No matter how much more expensive it is, or how much more real trouble it is. That's just life. > Things that may be problematic from my experience are that timing > is critical for some automation protocols. They would need to be > tested on a network that carries some traffic. Many, many devices > tend to send each character in a whole packet, indeed this is about > the only way you can be truly transparent and this can cause some > stacks and devices fits. The network you use for this may want to > be isolated from peer to peer NT connections as they talk a lot > for no obvious reason. As the cost is very little more I would use > 100 mbit ethernet and switches to keep segments collision free. > These things are true. The network for the line will be completely isolated from the regular plant network. Frankly, this is the only plant I've ever worked with that bought this point without a fight. The overhead is another reason I like having a small device to cook the data at the source rather than send everything and parse it at the supervisory node. Michael ([email protected]) -- Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc. Linux is like a wigwam... No windows, no gates. Apache inside. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jeff Thurman

Michael: I'm not sure what your cost constrainst are in the case but you may want to consider using 232>485 converters as an alternative. There are several 232>ethernet converters that I have seen advertised, but I have never tried one. Sounds like your running a lot of devices off of their own rs232 port. What ever approach you take, you may want to consider latency in a control situation. jeff _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Curt Wuollet wrote: >In my environment I would look very hard at using Linux boxes with >Rocketport boards in place of embedded type concentrators as the >cost is favorable and the workings would be less occult and any >little glitches, (there will be glitches) can be attacked with the >full breadth of tools provided. In the environments my group works in moving parts (hard disks and fans) are not reliable and not wanted. The embedded devices I mentioned are all flash based, low power and have no moving parts. > Having the source at both >ends goes a long way to assuring me that I can avoid or at least >fix this. Yep. ZWorld gives you the _complete_ source. Mark -- an open source believer _______________________________________________ LinuxPLC mailing list Linu[email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Michael Chase Research and Specialix are vendors I've dealt with in the past. I would check out Comtrol and DigiBoard too as many of the multiport serial board vendors see the handwriting on the wall. The remote access people would be good also as many are network connected. I did one of these with diskless linux boxes that are cheap and don't look like PC's. If it does the bootp thing and loads across the net I guess it's a terminal server. I'll bet a lot of the commercial offerings are x86 SBC's under the cover. The savings in development time using Linux made the whole thing work. Even a 486 and a small distribution will handle 32 ports. The problem with most small devices is that they don't offer a lot of 232 ports and they don't interface with standard multi port boards. If someone makes a PC104 or CPCI port board, that might be an option. OF course, what this country needs is a cheap way to accomplish this. Make it and they will come :^) Regards cww PS Have you looked at ucLinux and the uCSimm? or MachZ from ZFLinux Systems? _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wayne Johnston

There are quite a few companies making off-the-shelf devices like this. A search for "terminal server" or "device servers" will turn up several companies. You may also want to consider using RS232 to RS485 converters to share the communication port. The downside is that only one field device can communicate at a time. It's likely to be cheaper than the RS232/Ethernet converters though. &lt;BLATENTLY COMMERCIAL PART> We make a RS232/Ethernet Converter. Check out the 5905 Module at http://www.controlmicrosystems.com/pages/hard-ser5000.html (bottom of the page). &lt;END BLATENTLY COMMERCIAL PART> Let me know if you can't find other manufacturers and I'll dig up a list. I don't have one at this point, but I've done the searches a few times so it shouldn't be too hard to create one. Regards, Wayne Wayne Johnston Software Group Leader CONTROL MICROSYSTEMS http://www.controlmicrosystems.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Mark Going embedded certainly doesn't mean you can't use Linux. In fact it should be easier and much cheaper to get your IP stack free, etc, etc. I'll bet that's why zworld gives you the source. There have been many epiphanies since Linux got in the game. It's good to have choice. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top