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