Modbus / AeA / RS-485

[Spekkio]

I am making a device to communicate with Modbus and AeA protocol.
I have been reading for a few days, and from what I understand.
Both devices normally use RS-485 communication, and an RJ45 connector?


But where do I start, I have been looking around for information on RS-485, but I can't find a good spec.
I did a I2C program for PIC once, and that spec was easy to find.

I have found information on RS-485, but it is not enough to start programming a device that is compatible.

I was also thinking, to make sure that my MCU works correctly, I need a recieving/transmitting device that already works, a reference.
Something to test and debug against. I was thinking about the COM ports on my computer, but those only speak RS232 right?
Is it simple to build a converter of some sort?

[Hopasaurus]

rs-485 is a lot like rs-232 except instead of a ground referenced signal it uses a differential signal.  So instead of a line going hi-low-hi-low with respect to ground, you get two lines that move with respect to each other.  These lines are used for both transmit and receive, the devices take turns on the bus talking.  There can also be more than two devices on a single bus, you need to be careful with the bus layout and the upper layer protocols have to deal with bus contention. 

You can get a converter to go between rs-232 and rs-482.  These are what I have used before http://www.bb-elec.com/Subcategory.asp?SubCategoryId=9&Trail=2&TrailType=Top  That project had budget to support that (plus budget to let smoke out of a few) I am sure you can find cheaper if you want to look.  Both rs-232 and rs-485 may be more appropriately call eai/tia-232 and eia/tia-485, I think they have come out of "Recommended Standard". 

MaximIC probably has a "Line Driver" that will work for the PIC side of things.  (this might work: http://www.maxim-ic.com/datasheet/index.mvp/id/1111 but look close, I only spend a few minutes looking at it and I don't know your application)

I have seen them use a rj45 for the connector, but do not count on a certain pinout.  I have also seen screw terminals and even db9 stuff.  Watch out if you use shielded cable, only terminate the shield on one side also study the docs on resistors terminating the network.

The Modbus protocol is well documented, it can be used over a variety of communication links.  rs-232, rs-485, ethernet, laserbeam, tin cans with string, the protocol does not know or care.  I got to implement over rs-232 and rs-485 used the exact same software, just different hardware. 

There are (at least) two flavors of Modbus: Modbus RTU which is a binary 8 bit Modbus used for links that can do 8 bit transmission,  There is also Modbus ASCII which uses all 7 bit ASCII characters, used over links that will not do 8 bit (Modbus is really old).  If I have a choice, I will only impliment Modbus RTU, it is easier and more efficient.  Adding Modbus ASCII functionality is not that hard but do not bother unless you have to.  You will need to consult the documentation of the device you are trying to talk to to find out what it is expecting. 

Here are a few links to some Modbus information:
Technical information about Modbus
http://www.modbus.org/tech.php

A PLC simulator:
http://www.plcsimulator.org/
This is a PLC simulator, I have not tried this one, I used something like it to debug things when I was working on my implementation a while back.  You can use this to establish communication between a PC and the device you want to talk to.  This way you have something to fall back on when you are trying between the PIC and the device, you can't blame the device because you know it works.

I have not heard of the AeA protocol, and 30 seconds of Google did not help, if you would be so kind I am wondering what is ti please post a link to a little more information on it.

I would be glad to help with any more rs-485 or Modbus questions you have, just let me know.  I am also unsure of your overall familiarity, perhaps I have just regurgitated what you already know, if so please let me know what you are having trouble with, I love to help.

David H

[Spekkio]

Thank you very much

That was my thought, that the signaling scheme of RS-485 was like 232. But the only difference was the wiring, so the 485 specification only had information about TP wiring and line drivers. But it said nowhere how the signals looked anyway, not even if they were supposed to be exactly like the RS232 or not. It made me so confused.

If that is the case, I can make a RS232 connection to my computer. Program a MODBUS protocol on it and maybe run
http://www.focus-sw.com/fieldtalk/modpoll.html
to check if it works correctly. Then just add a Line Driver, (invert the signals?) when I need RS-485...
But it doesn't seem to be that simple, since 485 has support to a network and need to detect signals that is being transmitted and devices has ID's and etc.


I have a spec on the AeA protocol that I got, it is not public. Looks much like modbus.

AeACom2 is a data link layer protocol, according to the ISO / OSI standard model. That is the explanation of the number two in the protocol name. It is designed to be used on the physical layer of RS485.

[Spekkio]

btw, I am making a Modbus RTU slave. I have lots of information on modbus and also lots of code examples.
But I dont really know where to begin.
I was thinking today about setting up a PIC, code it for RS-232 and try to communicate with the modpoll program.
What confuses me most is how to I get RS-485. I have read that a line driver is needed, and you have linked me to the Maxim IC's that are recommended also from others.

Googling for "Recommended Standard" helped me.
This cleared out some question marks for me

As standard, RS-485 only describes the physical layer data exchange procedures, the all the problems of exchange, synchronization and handshake, assigned to a higher protocol. As we have said, most often, a standard RS-232 or other upper protocols (ModBus, DCON, etc.).

   1. RS-485 only performs the following actions: Converts the incoming sequence of "1" and "0" in the differential signal.
   2. Sends differential signal in a symmetrical line of communication.
   3. Connect or disconnect the transmitter driver to signal higher protocol.
   4. Accepts differential signal from the communication line.

If you connect an oscilloscope to terminals A-B (RS-485) and contacts GND-TDx (RS-232), then you will not see the difference in the form of signals transmitted in communication lines. In fact, the shape of the signal of RS-485 is the same as the form of an RS-232 signal, except for the inversion (in the RS-232 logic unit is transmitted voltage -12 V, and in the RS-485 +5).

[tecman]

RS-485 is based on RS-422.  It uses 5 volt differential signaling.  RS-485 goes beyond RS-422 with the ability to tri-state, or in other words go to high impedance, so that multiple nodes can exist on one line.  In operation all nodes have their transmitters turned off.  One station will transmit by enabling the transmitter and sending a message.  All stations can listen.  The transmitting station normally turns off the transmitter after the message is sent.  It is a single duplex system, with only one station talking at a time.  The normal configuration is that one station is a master, and all others are slaves.  This is how MODBUS 485 works.  To prevent contention, the master is in charge.  The master sends a message and one node can answer.  Usually the master relinquishes the line (xmit off) and the slave can transmit a reply.  If more than one node tries to transmit, the lined will be in contention and the message is lost.  Messages can be for all nodes (broadcast) but normally no node will reply.  Software controls the message flow, and one control line is required in addition to TX and RX.

RS-485 can support up to 128 nodes and distances up to 2000'

I have designed many products using RS-485 with various protocols.  Simple to implement, but timing is critical in enabling the transmitters, if you want high data rates.

Paul

[Hopasaurus]

Sounds like you are well under way, and have done a good bit of research already. 

What I would do next is use the modpoll program to get the PIC development started, with a max232 between the PIC and the PC.  This will take rs485 out of the picture to start.  This will also give some time for rs485 parts to be ordered and arrive.

Start really slow, just open up a terminal on the PC and make a PIC program to send characters to the PC, then you have that working, save that project so you have something to fall back on and add features to turn on an LED when the PIC receives a specified character, play with different ways of getting that to work.  Then move on to the Modbus protocol, before you know it, you will have it done.  Be sure to look around, there are a few public Modbus implementations to go from, not sure if there is one for pic or not, maybe.

[Spekkio]

Thank you very much for your help

[neoone]

good idea for checking RS232 communication with PC is to implement "echo" function in your PIC program. Just make it resend whatever byte it gets or the same byte+1 to be sure that it's not working due to some short circuit. So then on PC terminal when you send 'a' yoy'll get 'b' back from PIC, '1' => '2' and so on.

[johnwa]

Hi,

I have been using RS-485 in my latest project. I used the RS232-RS485 converter circuit at http://www.airborn.com.au/layout/232to485.html for the master node. Note that this circuit uses the RTS line to enable the transmitter, which requires special software on the PC. The enable is also connected to TXD for auto enable. I couldn't get this to work, so I permanently enabled it for my initial testing. This enables a standard terminal program to be used for communication. Note that RS-485 is half duplex, so as soon as you connect the converter you should see characters echoed back.

I discovered (after I had built the circuit!) that premade converters are available quite cheaply on dealextreme.com, though I don't know if these are any good.

It is pretty easy to interface to a microcontroller - you just need a level translator chip, and you are right to go. I used the 75HVD3082 (which can also be used in the above circuit) I have included a schematic to give you the idea.

Once you have got communication up and running, you can then implement a protocol such as Modbus, or develop one of your own. I made up a simple ASCII command protocol for my application.

[monpjc]

Just to make clear a few point for anyone else coming in and reading this:

RS-485 and RS232 are both used for serial communications as too is RS-422. However as a standard they talk about the physical layer in the communications - i.e. how the voltages are applied and basic format of data, the frame (Number of bits, start / stop bits).

ModBus - is a protocol and the spec talks about how the data is packaged and sent over RS-xxx or over any other physical media (Ethernet for example).

ModBus RTU - is one flavour of the Modbus protocol. Its also time critical. That is the time between bytes sent have to fall inside set rules. NOTE: that USB to serial (RS-232 and RS-485) adaptors do not always understand these rules (that don't need to) and you can find the ModBus RTU does not work. If possible use a real RS-232 / 485 port on your PC when testing or an approved adaptor.

Other comments:
RS-485 can handle any number of slaves - this is dependent only on driver 'cost' or 'load' on the bus. RS-485 only carries data not spec number of devices.

ModBus under the Johnson Controls will allow for 127 devices, were as ModBus can talk to 254 devices if JC is ignored (common practice now days).

Don't use the CRC generator inside a Microchip PIC for checksum checking / generation - it don't work as per the ModBus spec even if it looks like it will - use code to do this, examples are available on the web, or I can post on request.

Don't ignore termination resistors and transmission line loading on RS-485 - its makes a so-so good system rock solid.

RS-485 line drivers can have high surge currents (spec says to drive into a 60R load from what I can remember!) so make certain your circuit can handle this.

Thanks
Paul