Click here to Skip to main content
15,867,453 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
Hi,

I have a simple question about a problem that surely someone has already encountered. I have a legacy device that communicates (communicated) with another device through RS-485. It does this with its own protocol, which is quite simple and embedded in there are raw ARP, IP, TCP, etc packets.
So, having gotten the cables all correct and stripping the respective (serial) headers off, I'm basically left with raw TCP/IP packets.
What it the most convenient way to have these packets handled, without having to write a complete tcp/ip stack?

If I understood correctly, I must substitute the layer 5 with the code I wrote to dismantle the serial protocol, but how to go on from there?

Thanks in advance,
Tony Bom.
Posted
Comments
Michael Melkonian 6-Apr-11 21:41pm    
This is quite an unusual setup. You would expect data proprietary protocol (e.g. over RS485) to be encapsulated in TCP/IP, not the other way around.

In addition, RS485 is a multidrop party line type arrangement, and not common for use with 2 stations only.

The key question is : what is carried inside the TCP packets?

Do the two devices establish a TCP connection and send some prorietary application data through it?
Sergey Alexandrovich Kryukov 6-Apr-11 22:29pm    
Are your saying you have the external device which already implement IP stack (or part of it) based on RS-485?

This is quite unusual. I would hope that company also has client-part (or what is it on you computer host) code where the same stack is also implemented. The situation looks tricky.
Technically, it does not require a special device driver, simply because a serial port communication code is already readily available, so some piece of software could bind the serial port with the socker. After all, I have a FireWire port, and Windows provides the stack for FireWire-based network...

Hm. Interesting question anyway, I vote 5.

--SA

One solution I can see is using some piece of hardware which would allow you to use Etherner port on you computer host instead of serial port device. (Many computers don't have a serial or parallel port anyway.)
For example, I've found the site http://www.industrialethernet.com/[^], see http://www.industrialethernet.com/net232.html[^] or some other products. Search in internet and you will be able to find relatively inexpensive device.

You may say I did not answer your Question. No, I did not yet, but think about it: you may spend much more money (read "working time", which is more expensive than money) for poor-software solution. If you give up and buy the converter device, you can make an additional benefit of using computers which do not have any serial or parallel ports.


If you still need a software (or different hardware solution) you can search some more.

I would suggest something like this:

http://en.lmgtfy.com/?q=serial+port+(IP+OR+TCPIP+OR+%20%22TCP%2FIP%22+OR+TCP)+stack+-linux[^]

or

http://en.lmgtfy.com/?q=serial+port+(IP+OR+TCPIP+OR+%20%22TCP%2FIP%22+OR+TCP)+stack+bridge+-linux[^]

—SA
 
Share this answer
 
v2
Comments
Michael Melkonian 6-Apr-11 23:38pm    
I think you misunderstand the devices you are describing, SA. They take serial data packets from a serial port, encapsulate them in an UDP/TCP/IP packet(typically TCP) and send it to another similar device via Ethernet/Internet. The receiver strips the packet off TCP/IP header, and shoves the raw data into the serial line of device #2. To the end devices the communications looks exactly the same as if the two were connected via RS485, or RS232 or TTL or whatever, they don't even know they are connected through Ethernet/Internet.

What Tony wants is totally different.
Sergey Alexandrovich Kryukov 6-Apr-11 23:52pm    
Yes, I see it now. Let me scratch it out from the Answer. I understand what Tony wants or think he wants (if you see my comment to the Question); I wonder if is there are some devices which would do it. I would not be very surprised if they don't exist, because the way Tony describes sounds very exotic and absolutely atypical for RS-232/485 stuff...
--SA
Michael Melkonian 7-Apr-11 1:14am    
I agree. Tony needs to explain a bit more - lets see what the real situation is - I am curious :)
Sergey Alexandrovich Kryukov 7-Apr-11 1:42am    
Me too.

I also have to work with very different hardware for this damn automation, and I'm permanently amazed by the ill fantasies of those people developing software for the hardware, especially of the industrial grade. Their brains are seemingly turned in a weird direction...

--SA
DonTone 7-Apr-11 5:38am    
First off, thank you all for your comments. Small wonder that I couldn't find a fast & easy solution. I will elaborate...
It is a legacy Motorola device (a POS to be exact) which talks to its ticket-printer (with its own motorola board). For historical reasons (how many times I've had to hear that in this job upto now) through rs485. True, rs485 is multi-drop, but not in this case, there is just one master en one slave device, so comms is quite easy (actually it is done this way, because the same protocol is used for ticket validation devices on busses/metro, which do have more slave devices).
The point is that, yes they use their own tcp/ip stack, but it should be compliant with a standard stack.
So, it communicates through this serial protocol (rs485) and in those packets I find first the ARP stuff to agree on the (fixed) IPs, and after that IP and TCP packets (raw).
After stripping off the serial protocol I have pure TCP/IP from the ticket-printer to which I (or what piece of software for me) basically must respond - its those reponses I have to implement.
I agree that the logical way would be (have been) to use PPP or maybe SLIP, but unfortunately in its time it was done this way.
What is inside the TCP/IP packet is trivial data that gets exchanged between the master and the slave (polling, transport commands, ticket content information, magnetic encoding info, etc, etc - all quite straightforward stuff actually).
The scope of this project is to substitue the master part (ie the POS itself) with some windows thingy (or linux, doesn't really matter) to drive (eventually - apart from all the business logic) the printer, the ticket transport, etc, etc.
As for sources, yes, I have most of the sources, so theoretically I could take the stack and its device driver to implement something that simulates an ethernet card, but the porting of those sources would be quite a pain (all written for a specific embedded device - and written not quite that good). My honest initial thought was that once I had the TCP/IP packets it would be relatively simple to pass them on to some stack.
The whole point to do it this way was probably to have the simplicity of talking though sockets, and so it would have been easier to implement a network driver which is actually a rs485 link.

I hope I made it a bit clearer what I'm trying to do here.
Thanks again for your time,
Tony Bom
Okay, it looks like this may work:

The two stations will establish a TCP connection (that is why you are seeing ARPs in the beginning and you might see some BOOTPs and who knows what else. This will probably be unimportant if you only ever have 2 stations). Then the application data then flows through the TCP connection. What I would do in the Windows thingy that replaces your POS:
1) Strip the serial headers off (you have done that I think)
2) Monitor ARPs and TCP handshake process to detect a connection is established between master and slave. From this point, you will have one TCP connection to worry about
3) Monitor one connection e.g. TCP packets between the two and strip off (after stripping off RS85 headers) the TCP and IP headers (make sure to handle repeat packets and acks and so on)
4) After striping off TCP headers you get your raw app data and process it. Basically at this point you should present to your application data processor a contiguous stream of data

In effect you are implementing a small part of TCP/IP stack.
It will help if your two stations establish a permanent TCP connection and just keep it forever - job is easier that way.

And by the way, when you get a chance to see the original designers who arranged it this way in the first place, tell them that you run this past the most reputable software forum in the world and they all though the arrangement sucks big time :)
 
Share this answer
 
v4
Comments
DonTone 8-Apr-11 17:30pm    
Thanks a lot for all suggestions. So it really comes down to implement the stack partly. I feared that, but as you say, it shouldn't be *that* complicated (especially since it's only a subset, and at that over a dedicated reliable line).

As for the original designers, the only thing that can be said about that is that they were Belgians, which might explain a lot :)

Tony Bom
Rome, Italy.
XML
In Linux or OS X, you can use pppd for the TCP/IP part. Write a program which communicates with your device and converts between your device's protocol and PPP frames written to stdout and read from stdin. Then you would run pppd as superuser and "connect" to your program (e.g. "/home/joe/ppptranslator") instead of a serial line or a modem:

sudo pppd nodetach pty /home/joe/ppptranslator

PPP is easier than TCP/IP, but it's still challenging. Good luck!

Here is some reading:

PPP:
<a href="https://www.ietf.org/rfc/rfc1661.txt">https://www.ietf.org/rfc/rfc1661.txt</a>[<a href="https://www.ietf.org/rfc/rfc1661.txt" target="_blank" title="New Window">^</a>]

HDLC frames (PPP lowest level):
<a href="https://www.ietf.org/rfc/rfc1662.txt">https://www.ietf.org/rfc/rfc1662.txt</a>[<a href="https://www.ietf.org/rfc/rfc1662.txt" target="_blank" title="New Window">^</a>]

IP in PPP:
<a href="https://www.ietf.org/rfc/rfc1332.txt">https://www.ietf.org/rfc/rfc1332.txt</a>[<a href="https://www.ietf.org/rfc/rfc1332.txt" target="_blank" title="New Window">^</a>]

The TCP/IP Guide:
<a href="http://www.tcpipguide.com/free/index.htm">http://www.tcpipguide.com/free/index.htm</a>[<a href="http://www.tcpipguide.com/free/index.htm" target="_blank" title="New Window">^</a>]
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900