I bought this generic device for $79 plus shipping and customs. I followed the setup instructions and to my delight it worked--one computer was talking to another.
Legacy devices always will be a pain, and I was reminded of this during the past week.
My friend and Control Design Senior Technical Editor Rich Merritt also writes for our sister publication CONTROL. He recently wrote about how Tier-2 and 3 suppliers have been successful in product and market penetration in the processing industry.
Well, I've had two occasions to have to consider Tier 4 (read commercial) suppliers in the automation world,and actually try the technology for recent applications. They both deal in Ethernet connectivity and serial communications.
The application: a serial PLC is required to be connected to the building network for data access. What is one willing to spend to get it? I set out to provide an answer.
The first application involves a series of remotely located serial PLCs that must be connected via a broadband network. The PLCs interface with control apps such as lift stations and wells. Minimal input and output points are connected, so it's not a heavy-duty application. Cost is a big factor here.
To be fair, a PLC is not a passive device such as a barcode scanner. Real control is done via the protocols that travel in and out of the serial port, so data integrity and timing is an issue.
I could use a vendor-supplied Ethernet to serial device at a cost of more than $700 or a generic Ethernet equivalent for less than $100. If I were an industrial OEM and that worked, I'd be smiling all the way to the bank with the savings I'd accrue over the months and years ahead.
So I bought this generic device $79 plus $33 for shipping. I followed the setup instructions, and to my delight, it worked. One computer was talking to another using telnet (Ethernet side) and hyper terminal (serial side).
Talking to any ASCII device would be a breeze, or so it seemed.
Enter the PLC. It uses a serial protocol that only talks through a serial port. Ummm, seems to me I need a ComPortReDirector (software that looks like a com port, but sends stuff out using TCP to the target device).
I had a copy of a Lantronix COM port redirector, but it seems that it only talks to Lantronix device servers. In the industrial world this is common practice and another reminder about the definition of open.
I found that TalTech has such a product and I downloaded a demo. I set up the virtual COM port and tried to connect,but no dice. It seems I could send normal ASCII data, but to communicate with this PLC, uh-uh. I decide it might be a port control line issue,PLCs are weird that way. That's when I bought the breakout box. This device allows you to view the hardware of the serial port(s) to see what control lines are set.
Fifty bucks and I'm up and running. Well, I can see the control lines anyway. And they are different than if I was directly connected to the PLC front port. I think I'm home free now.
My jubilation is short-lived. That DH-485 light still blinks, and no connection is made.
I've spent the better part of a week trying to get things to work. I enlist the help of Lynn Linse, a tunneling, serial, Ethernet, device server guru with Digi Intl., but I still can't connect.
However, he did mention that some protocols such as the one that I am trying to use are timing-dependent, and that some hardware solutions for Ethernet-to-serial may not strip off everything (non-protocol bytes) so that the target device is convinced it is talking to the right source.
Without a scope and more time, I have to stop. I've always believed I can get anything to work, but this time I'm toast. I've spent far too much time trying to save $300, the cost of com port software.
Tier 4 supplier hardware doesn't work in this case. Tier 2 solutions do, but there are minimal cost savings.
Application #2 requires a similar approach, but is more time critical. Guess what I'll recommend? As much as I would like to provide a lower-cost solution, I can't.
As the tutorials on the Digi website say: There's magic in them thar device servers.
Jeremy Pollard, CET, has been writing about technology and automation software issues for many years. Publisher of The Software User Online, he has been involved in control system programming and training for more than 20 years. E-mail him at [email protected]
