I need to implement a proprietary network of various devices connecte over the RS-485. No third party device needs to be interfaced, all th devices will contain the firmware written by me.
Is there any specification which tells me how the devices can b addressed over the network and messages can be accepted by them ? Also are there any error correction methods recommendable for this network.
I have read that may be ModBus protocol could be used. Can communicate directly to the RS-232 send and receive routines from th Modbus module or do I need more layers of software in between ?
I can't tell you if the ModBus protocol will work for you or how many layers you need. You have not defined your requirements at all. But I can tell you that one fundamental difficulty in working with RS-485 or any half duplex protocol is knowing when the bus is free.
I once worked on an RS-485 bus where the designer of the bus did a poor job of defining how to turn the bus around. The result was that there were collision problems. Typical UARTs will tell you that the buffer register is empty (useless for this purpose) or that the transmit register is empty (the stop bit is still being timed) but they won't tell you when the stop bit has finished timing out. So most systems have to use timers and other means external to the UART to control the transmit/receive output to the driver chip.
There are a few MCUs with UARTs that can directly control the RS-485 driver enable. Be sure to use one of these. The slave will also have to pad at least a bit time to make sure it does not turn on its driver before the master has disabled its driver. This is purely a software issue.
There is no specification as such; how you use it is up to you. However a typical scenario would be as follows:
- Each device on the bus has an address in the range 1-32 (typically set in hardware with e.g. DIP switches or a rotary switch - or in Flash so long as you have a means of setting the address before connecting to the bus).
- Each transmission from the master includes the device address as part of the packet. Each device checks the address, and responds only to its own address. (You could also have a broadcast mode if you need it, so long as none of the devices are expected to reply.)
- The architecture is master/slave; i.e. all comms are initiated by the master, and slaves respond only to messages addressed to them.
- All messages include a checksum or CRC field to allow error-detection (not necessarily correction). You could either allow for a NAK-type response, or simply timeout (assuming the master will retry).
Sorry, I don't know. Bear in mind that RS-485 differs from RS-232 in that you need to take care of releasing the bus (i.e. enabling/disabling the transmitters). The above scenario is effectively half-duplex, so you could use either the usual 3-wire RS-485 or the 5-wire variant a la RS-422 (but still using RS-485 transceivers - they're superior to RS-422 devices in all respects).
(I have used Modbus over RS-485, but it was too long ago to remember the details...)
Please note that there are several "fractional load" transceivers on the market which allows over 100 devices to safely co-exist on an RS-485 network, so an addressing scheme should accomodate that...
Yes, ModBus is a workable solution. You will need to be able to sense when the last bit of a message has been sent so you can switch the transmitting device over to receive mode. In the past I have done RS-485 ModBus using a variant of the 16550 serial device which could generate an interrupt on "last bit sent". It all worked just fine.
You must be joking. A protocol that relies on inter-frame times for delimiting the frames is a major PITA. It is much easier to either use escapes for frame delimiters or a 9th bit to flag an address- and end-of-frame byte. Most controllers offer a 9 bit scenario and often with automatic address recognition as well.
It is not that bad. Point to point connections using RS-232/422 connections can be easily implemented by just monitoring the contents of the message. The traffic is half duplex after all.
The multidrop master can also be implemented this way, however, when using the stupid 16550 UART series, you really have to poll the Tx shift register empty bit before turning off the RS-485 transmitter.
Slaves in a multidrop network with inaccurate pause detecting will communicate reliably, as long as the master communicates with the same slave using multiple transactions. However, when the last response from slave 1 is transmitted and then the master starts to send the next command to slave 2, if slave 2 does not detect the pause between response from 1 and the next command to slave 2, it will not detect the command addressed to it. However, the master will timeout and send the command again. This kind of problems with some slaves can be avoided, if the master exaggerates the pause before sending the next command to a new slave.
Some Motorola/Freescale processors contain the QUICC I/O processor, which has a nice Rx idle timeout interrupt feature and it is quite easy to get nearly perfect pause timing with it.
The 9 bit system is a mess, if you want to monitor the traffic on a typical PC hardware or communicate with such networks. On simple 5-8 bit UARTs, you would have to fiddle with the odd/even parity setting on a character by character basis, to select the parity bit in such a way that you get the wanted 0 or 1 into the parity bit i.e. address/data bit. On receive, you would have to detect the parity error on a character by character basis, thus making both the Tx and Rx FIFO useless. Since most UARTs have a common parity for Rx and Tx, full duplex operation would be unthinkable.
Well I have no strong feelings either way about ModBus. The product demanded it so I implemented it. Having said that, the bandwidth loss was maybe one or a few percent with our typical message sizes. The timer was free (not otherwise being used) on our micro. And the processing overhead to deal with the timeout processing on each received character was maybe a microsecond.
Which is just to say (for the OP's edification) that none of these issues are deal-killers. Any serial protocol has to deal with (devote HW and/or SW to) the same issues such as what signals a new message, where is the end of the message, and is it a valid message?
Can you let me know of some other workable solutions which are easier t implement. I just read about Modbus being used for RS485 and asked. I don know of it's advantages and disadvantages. Also if you know of an controllers which offer RS485 support, please let me know.
It burns a lot of CPU at high baud rates since you've got to run an interrupt-per-byte. If you've got to do multiple interfaces at high baud rates, it starts to seriously suck.
Most of them are a lot lower overhead than Modbus. If you've few interfaces, plenty of CPU time and timers to burn, then Modbus isn't too bad.
--
Grant Edwards grante Yow! MERYL STREEP is my
at obstetrician!
visi.com
Don't let the details here put you off. A roll-your-own RS-485 system isn't hard - yes, there are a few pitfalls for the unwary, but nothing really hard. I've dealt with this stuff a lot, as have others here. If you have specific questions, ask away.
RS-485 is a hardware standard, so it's nothing really to do with the controller as such. Beyond what you'd need for RS-232, you'd need a line to turn the bus around (which you might have needed for h/w handshaking anyway), and you'll almost certainly need a timer. Otherwise, it's just plain-vanilla async serial NRZ comms.
Well, you have to compare the interrupt-per-byte loading with the message-processing loading. If you've got high-speed messages coming and going on multiple interfaces, you've got to devote more CPU time to processing these messages anyway. The interrupt-per-byte cost is going to remain nearly the same relative to the message-processing cost regardless of how high or low your baud rate, or how many ports you're running. So the key question is, how much processing time does the average message require? Once you attach a number to that, you can get an idea how much more your interrupt-per-byte will cost you.
One possibility is to use a time slot bus. The time slot bus consists of
a clock
a frame sync
data
Each device is allocated a time slot where it will drive the bus. A master will drive the clock and the time sync signal and the devices will then drive the data output during its allocated time slot.
A typical example are the E1 bus used in European Telecom equipment - also called 30B + D running at 2,048 MHz. The data is divided into frames of 256 bits (and you get 8000 frames per second) Each 256 bit frame is divided into 32 timeslots of 8 bits.
1 timeslot (T0) is used for sync, 1 timeslot for internal communication (T16) using the HDLC protocol and on top of the HDLC, a higher level protocol called SS7. The remaining 30 timeslots are for telephone calls using PCM coded Audio..
. The number of nodes and communication speed will determine if this is a useable approach. The SSC of the AT91SAM7 family and certain Telecom oriented PowerPC woudl be useable for this.
If you just want RS-485 over UART, then maybe the AT91 UART still can be interesting due to its H/W support for the RS-485 enable signal. It supports manchester encoding as well.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Doesn't this type of shared bus have at least a separate data and clock and often a separate frame sync signal?
Yes, but E1 is not a multipoint bus. The signal is unidirectional with multiple sources being multiplexed through a device, sharing a single bus to the destination where the bus is broken out into multiple signals again. This is way beyond the type of RS-485 application I think the OP is asking about.
How would you make this work with even just three nodes, each having a single serial port connected to a shared RS-485 bus?
On the other hand, while E1 would be very impractical to implement, a round robin approach could be used if you did not want to have a single bus master. Each node would have a unique address. The address is used at the start of a header for a message to be sent. Each node sends a message when it is their turn, even if it is a NULL message. If a node does not respond to its timeslot, the next node times out and sends a message. The node at time slot 0 would be able to recognize the size of the network and respond with its message when the last node in the system had transmitted. An enumeration scheme could be implemented at this boundary time to allow a new node to join the network and have a node number assigned dynamically. Even the assignment of a node number assignment "master" could be done when the system is turned on. Each node would wait a random amount of time (beyond some minimum) and the first one to query the network would be node 0. The next one would be node 1, etc.
I am sure there would need to be a bit more detail ironed out, but I think this would allow for nodes to be added and removed dynamically and automatically.
This is often a pain in "straight" RS-485 networks. Usually, the master has to be told the bus population, or have a start-up poll phase. Simply waiting for a node timeout on every possible address quickly stacks up to $stupid_time.
This may seem to be a problem from the application layer point of view, however, the application layer that will process the data must know what type of devices there are on the bus. This usually requires some configuration in the application layer, so the node numbers can also be decided in advance. Thus, you can simply set the address for each node (e.g. with DIP switches), before connecting the node to the line.
Polling all possible addresses would be useful only if all the possible devices respond with a type code or serial number which is available from a well known address in each slave. For PLCs and other programmable devices, you would also have to obtain the information of what software each devices are running and if multiple nodes with the same software, into which real word sensor cabling each device is connected. From this, the application layer can then build a map, which node number is connected to which external sensor cable. To be practical, this would require reserving some PLC input pins just for identification by wiring some jumpers differently in each sensor cabling.
While most fieldbus systems have a well specified way to identify the device type (usually device profile) by inquiring it on-line, for instance in Modbus RTU, devices have no standard way to identify the device type, so a lot of heuristics is usually needed to find out which device is which, even from a limited selection of types.
Thus, whatever you do, you have to configure the node information in one way or other. Thus, specifying the node numbers in the application and setting the device physical address accordingly is still a viable option and no polling for nev nodes is required.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.