RS485 Need some help

[nasr]

Hi Everyone:
I am implementing a project with one master PIC communicating with around 20 slave PIC. I tried to use max232 but it is not perfectly working, now decided to use RS485.
The master is initiating the contacts with each slave at a time, I will use MAx487 as a tranciever, I just need a starting point withe the code and speciffically what does ENABLE in the rs232 directive do?
I will not have any addressing for the slaves we want the code to be the same for all slaves.
Hope you can help/guide me a bit here.
_________________
Thanks in advance for your help.

[Ttelmah]

A lot of learning to do.

The standard way of using RS485, is to have one pair of wires (just one signal 'pair'). Hence to allow multiple devices to both send and receive on this one signal, the transmit driver on the one wanting to talk, has to be 'enabled'. Hence the enable line.

You have multiple choices.

If your devices don't need to acknowledge that they have received data, then the receive devices can just have their buffers all set permanently to receive, and only the master device has the buffers set to transmit.
Problem is that no link is ever 100% reliable, and this way the master can't tell if devices have received the message.

The first alternative is to have an address. Code doesn't have to change on the devices, you can have something like a DIP switch to set the address on each device. Then you can have the master send the message to each device in turn, and wait for it to turn the bus round, and acknowledge.

The next alternative is to have some form of time based acknowledgment, with each device waiting for the bus to release, then using a 'time slice' after this point to acknowledge. Designing this gets complex.

Then you have possibilities like implementing 'pass forward' messaging, with each device passing the message 'on' to the next device, and waiting for this to acknowledge. Needs two serial links.

An address is the _simplest_ way to get an acknowledgment.....

[temtronic]

also....
CCS kindly supplies an RS485 'driver' in the examples folder. It would be a very good place to start !
and...
start with say 2 'slaves' NOT all 20 !! It's a LOT easier to debug 2 slaves.....then add 1 or 2 at a time.
and...
be sure to follow proper RS-485 terminations! This consists of a 120r across 'A' and 'B' PLUS a pullup on 'A' and a pulldown on 'B'. Unless you've got the hardware right...software will never quite work 'right'.

hth
jay

[nasr]

Thanks for your post, just to clarify, the slaves are NOT recieving any data from the master. The slaves are only sending data to the master one at a time in order initiated by the master. I have enough pins to trigger each slave at a time.
_________________
Thanks in advance for your help.

[ezflyr]

Hi,

Well, in addition to being somewhat contradictory, your 'more clarification' post makes very little sense!

First the contradiction: If the Master is initiating data transmission by the Slaves, then the Slaves are in fact receiving 'data' from the Master. Parse the words anyway you want, but the key point is that it's not just a one-way exchange, it's two-way.

Next the silliness of your proposed design: So, all the Slaves are going to transfer data to the Master on some type of common 'bus', but each of the 20 Slaves is going to have a separate 'trigger' signal?? That makes no sense, and totally defeats the benefits of a network, which should be designed to easily & efficiently interconnect a collection of distributed nodes. Your 'hybrid-network' as described does not satisfy this definition.

If you are going to attempt to create a 'network', then do it correctly. Assign each node a unique address (each node can have the same firmware), and establish proper two-way communications on your bus.

John

[ezflyr]

Hi,

I'll add a little bit more to what I already posted. As Ttelmah has already said, giving each node a unique address is the way to go. All nodes have the same firmware, they just have a unique address assigned and stored in EEPROM. The address can be set with DIP switches, jumpers, etc., or to keep things really simple, just a switch or a jumper. I have two network designs that are in wide deployment. On one design, each node looks at a jumper on startup, and if it's closed, goes into address setting mode. The node has an LCD that displays an incrementing address that pauses at each unique value. When the desired value is reached, the jumper is removed, the address is stored and 'normal' operation resumes. On the other design, there is a pushbutton. When the button is pressed, the node goes into address setting mode. The Master then sends a 'Set Address:XX' command that is received by this node, which is the only one in address setting mode (the others ignore the command). So, it's pretty easy to implement a two-way network even with simple node hardware.

John

[nasr]

I did not say that the Master is sending data to slaves if you read carefully (which I doubt you do!!!) I said I have enough pins to trigger data transmission through pin B0 of each slave.
Second, we do not have a common bus to all slaves, each slave is connected to the master pic via cables. If you can not help with an answer, then kindly keep your SILLY comments to your self!!!
_________________
Thanks in advance for your help.

[temtronic]

nasr it's best not to 'flame' those who are trying to help you, especially those that have decades of using PICs in a network. There is a wealth of real world knowledge here, stuff NOBODY teaches in schools these days!

I do have a couple pertient questions
1) Which PIC have you chosen to be the 'master'? For your network, you'll need 20 'control' pins and some PICs may not have that many I/O pins that can be used as discrete 'output' only pins.

2) Cabling can be an 'issue' using a hardwired 'control' or 'remote access' to slaves. Additional wire (the 'control' wire) adds cost depending on distance you'll need a driver chip, as well as a receiver on the slave. Also the connectors need more pins. This does add cost to the project.

3) The most common way to have master-slaves is RS-485 with unique addresses as it eliminates all of the hardware headaches in #1 and #2. It's simple, cheap, reliable and has good speed/distance ratio.

If you decide to stay with your original method, good old RS-232 will work 100%. I still have a couple of networks up and running after 15 years using MAX232 chips as both xmt, rcv and ctl signals using DE-9 connectors and PIC16F877s.

hth
jay

[notbad]

Dear "nasr". You are the reason we can't have nice things.

[Ttelmah]

The problem is that you really have no idea what you are doing.

You start with the statement:
"The master is initiating the contacts with each slave at a time".

That implies the master is sending data.

Now seriously, if you are using 20 sets of wires to signal this, you have more problems than you are solving. The number of pins involved, and what signal standard you use for these wires. A TTL signal from a PIC, is only useable for a few feet, and _requires_ protection. The whole point about sending signals distances is that the design gets more complex, requiring wiring that is noise immune (hence RS485 is differential), and with protection.

Then you say in your latest post:

"Second, we do not have a common bus to all slaves, each slave is connected to the master pic via cables.".

Not having a common bus, would imply the master having to receive on twenty separate lines. 20 separate software UART's (since no PIC has this many hardware ones). 20 bus receivers etc. etc..
No.
The whole 'point' of RS485, is it allows 'multi drop', so multiple devices on one common pair of wires. If you want to use RS485, then use it.

What you seem to want to do, is about the least reliable, and most complex way of handling things. Everyone here who has done anything involving sending data to boards, knows that the starting point, is a sensible design, with a bus designed (both in it's software and hardware) to survive electrical noise.

I suspect you have started with no idea about serial comms, and have come up with a 'design', that is roughly equivalent to semaphore (actually possibly worse), and then can't get this to work, hence the question here.
You need to actually do some research on busses and both the hardware and coding needed, and 'think again'.

[Mike Walne]

[newguy]

[nasr]

Hi Everyone:
I am not trying to be rude to anyone, I appreciate all your help, it is just not nice from some one to say my idea is silly. I actually have it partially working with three slave PIC using rs232 and not rs485.

The way to do it like this is the request of my client, they want and easy plug and play environment, meaning, we can have 10 slaves or 15 or any number up to 20. The slaves could be plugged to the master unit via Rs45 jacks. Yes, each slave can have its own tranciever on the master PC board. the master is initiating contact (through setting one pin high) to initiate an interrupt for a specific slave to send the data (just a string of 100 characters) after recieving data from this salve, the master then sets another pin high to communicate with next salve and so on. I really do not need 20 pins, just 5 I/O for a multiplexer but those details are not important for the problem I am having, it is the communication part I have problem in fixing, in fact, if I decide to use Rs485what does the ENABLE option allow me to do in the rs232 directive? I mean, if I write ENABLE=PIN_A03, then in my hardware where should I connect PIN_A03 of the master? IS to some pin of the tranciever IC or to where. Appreciate your help in advance.

[ezflyr]

Nasr,

Well, first of all you need to grow a thicker skin if you really expect to be successful on an open forum. Then you need to open up your mind a bit to the ideas of people that have experience in this area. As Ttelmah said "you really have no idea what you are doing"......

Remember, it was you that first mentioned 'RS-485', and 'MAX487' (an RS-485 tranceiver IC), and 'Enable' pins, so naturally we assumed that you were actually considering some sort of a multi-drop bi-directional network. Later, we find out that you are dead set on implementing some sort of an 'ill-conceived', poorly-designed, hybrid network. If 'silly' is not to your liking, then how about 'dumb'???

On an RS-485 network, the data flow in bi-directional. Of course, data can only flow in one direction at a time. The 'Master' and each 'Slave' control an I/O pin (the 'Enable') that controls the data direction of the individual bus interface tranceiver that ties them to the bus.

Edit - nasr, I wasn't calling YOU silly, I was calling your idea silly. Big difference. I was offering my comments as constructive criticism based on my own experience in this area. And, I'm not calling you dumb either, it's just that your proposed idea needs a lot of work. People here know how to help you solve your problem, but you need to be more open to these ideas!

John

[Ttelmah]

We are back though to the problem of signalling. Using a line from the processor to signal you want to do something, means you have a conventional TTL input on the receiving device to accept this. Such lines are _not_ suitable to connect to other devices on indeterminate cable lengths. No signal protection and very easy to damage from ESD.
Lines like RS485, are designed to withstand a significant amount of ESD. TTL lines are not.

Now unless your devices are a significant way away, normal RS232 will work _better_ than your TTL control signalling. That you were having problems with trying RS232, to me says you were probably running into signalling problems, quite probably with this latter. This is sending you strong warnings that you need to re-consider the approach. If the distances to the units are less than perhaps 100 feet, then RS485, is _not_ going to help. The primary advantages of RS485, are that it supports multi drop (which you are not using), and handles transmissions at distances over 1km.

Realise that things like network cards are 'plug and play', and _all_ have a unique address.

Then realise that we are warning you that people, many of whom have built crude designs like this years ago, _know_ the sort of problems you are likely to have, and are saying that your approach has fundamental problems.