I need confirmation on the below architecture if it works.


The main communication is between Master and the 3 slaves, but to do some calibration during power on there is USB - RS485 converter and front-end software which i have developed to send the data to Master which in turn will send to slaves. So, i wanted to know if this architecture will work, i am concerned that suddenly while communication is going on between Master and 3 slaves someone interfaces the front end GUI software and starts calibration, does it create conflict? how can i avoid it, i have control of all the software's, so i can define all the timings etc. Please suggest the algorithm to avoid bus conflict. As of now my idea is once calibration initiated by pressing connect button, both the GUI and Master waits for 10 secs then disconnects.

 

I updated with the below architecture, request to please comment if this architecture works, it is updated like initially the PC GUI and other slaves also in slave mode, the master controller sends data irrespective of the GUI connected or not. Once the user connects and presses the connect button, the GUI waits for its turn then sends the response. From then onwards the GUI will be master and the master controller will be slave accepting calibration parameters till the disconnect button is pressed. The master controller then moves to Normal mode.

 

I need confirmation on the below architecture if it works.
View attachment 367443

The main communication is between Master and the 3 slaves, but to do some calibration during power on there is USB - RS485 converter and front-end software which i have developed to send the data to Master which in turn will send to slaves. So, i wanted to know if this architecture will work, i am concerned that suddenly while communication is going on between Master and 3 slaves someone interfaces the front end GUI software and starts calibration, does it create conflict? how can i avoid it, i have control of all the software's, so i can define all the timings etc. Please suggest the algorithm to avoid bus conflict. As of now my idea is once calibration initiated by pressing connect button, both the GUI and Master waits for 10 secs then disconnects.

Assume that your using half duplex it will work.
1: all units are in listing mode.
2:two possibilities
a: master keeps polling
b:each unit may start transmission.
in case a
** format [address remote unit ][ master address ][ data ][ checksum][ eol or eot]
wait n mS seconds ( n time needed to send receive data + safety)
all other units know 'its not for me' and block transmit.
if no ack/nack is received unit goes of the 'active units list'
els handle ack or nack.
repeat this n times and of the list with that unit. report dead unit.
format [address remote unit ][ master address ][ data ][ checksum][ eol or eot]
data = [header r/w][memory address output] [set or read pin]
data =[header r/w][memory address output] [ set or read address unit]
and so on ..................

case b: all in listing mode.
if one unit like to send data the sender should start when the line is free. (wait n mS after an eot detect from any other unit). work using **

build in each unit a broadcast address allowing to create a list of working devices.
( is the 'dead unit ' alive again). Or find a new connected one.
also build in a new unit address never to be used in an operational situation but
gives you the following information;
I am new so give me an address.
you can add functions like

That's all
Simple isn't it?

Picbuster

 

if one unit like to send data the sender should start when the line is free. (wait n mS after an eot detect from any other unit). work using **

Picbuster

But how do i know in the software if the bus is idle?


Do you mean the 3.5 Char time? How is this implemented in the code?

 

part 1 basics

part 2 implementation

 

You haven't said what your processors are or what they're capable of doing, but I think the easiest way of allowing communication with a computer is to use a master unit which has two serial ports. Then one of them can be used for the network, and the other one can be just for the computer connection, if the computer happens to be there.

If you want to allow the computer to use the main RS485 network, one way to do it would be to have the master make an inquiry to the computer, and wait for an answer. If the computer doesn't respond in some time interval, the master moves on and does whatever it needs to do with the network. Then after a while it can look for the computer again. This should work as long as you can tolerate some time being wasted while the master checks to see if the computer is there and wants to say anything.

 

The master is a PIC controller dspic33 family, the problem is there is only one serial port to which all the slave nodes and the computer is connected.
To simplify the things what i have implemented but not tested is, let us say the master is communicating with the slave nodes with command and response, in between the PC is connected and it started to send commands to the master. I am hoping that master will receive the command from PC without conflict. The master then will stop communication with slaves until the disconnect command from PC is received. So, only question mark is if the master can receive the command from PC while it is communicating with slaves?

 

This can't work reliably, because only one unit can transmit on the RS485 line at a time, and the computer might start to transmit at any random moment. But if the master node sends a message to the computer first, asking "Have you got any messages?" and then pauses to wait for an answer, that would solve the problem. But unless the network operates very slowly, there would need to be an automatic response from the computer when there is data to be sent. Responding manually to a prompt would be far too slow.

Your processor might have only one hardware serial port, but it's pretty easy to write code for a software-based UART. It wouldn't need to run at a high speed.

 

This can't work reliably, because only one unit can transmit on the RS485 line at a time, and the computer might start to transmit at any random moment. But if the master node sends a message to the computer first, asking "Have you got any messages?" and then pauses to wait for an answer, that would solve the problem.

Yes, this is one concern i have. But in one of the replies i found bus idle, i am curious to know is it possible for any node to know if the bus is idle? if that is the case the PC can send a command when the bus is idle.

But unless the network operates very slowly, there would need to be an automatic response from the computer when there is data to be sent. Responding manually to a prompt would be far too slow.

Sorry but I did not understand the statement.

 

Yes, this is one concern i have. But in one of the replies i found bus idle, i am curious to know is it possible for any node to know if the bus is idle? if that is the case the PC can send a command when the bus is idle.

1. The device must check that the bus is idle before attempting to send.
2. There is still a probability that two or more devices start sending at the same time.
3. Hence, while sending, the device must check if the data being sent was corrupted, hence a collision occured.
4. If a collision was detected, each device will back off the bus for some time delay based on an established priority.

 

Rs485 is just a transport layer.
its often used to drive long cables when using a serial output.
but simple serial from microcontrollers and pcs do not ensure the bus is free to transmit or whether the message was received. In fact simple serial assumes either one to one transmission, or one master and many slaves.
to ensure this you need to use a protocol. I’m not suggesting that you use it, but canbus uses rs485 as the transport layer for the protocol.
an alternative is to devise your own protocol that checks whether the bus is free and whether a message has been received.

 

... canbus uses rs485 as the transport layer for the protocol.

No it doesn't. CAN uses two wires, but it works differently.