Difference between revisions of "Team:Aachen/Notebook/Construction Manuals/Communication Protocol"

(→‎Slave to Slave)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Team:Aachen/Header}}
 
{{Team:Aachen/Header}}
−
 
+
__NOTOC__
−
How do the Master Control Program and the reactor controllers communicate with each other?
+
=Talking Between the Harware and the Software=
 +
How do the Master Control Program and the individual reactor controllers communicate with each other?
  
 
{{Team:Aachen/Figure|Aachen_BioreactorCommunicationProtocol.png|title=Communication Flow|size=large}}
 
{{Team:Aachen/Figure|Aachen_BioreactorCommunicationProtocol.png|title=Communication Flow|size=large}}
Line 7: Line 8:
  
  
−
===Slave to Slave===
+
=Slave to Slave=
 +
 
  
 +
If every reactor needs one USB port for itself, we will quickly run out of USB ports on normal lab computers. Therefore it is necessary that the reactors can communicate between each other so that only one reactor needs to be connected to the computer.
  
−
If every reactor needs one USB port for itself, we will very fast run out of USB ports on normal lab computers. Therefore it is necessary that the reactors can communicate between each other that only one reactor has to be connected to the computer.
+
The communication system we invented works in principle as shown above. Every rector must be able to communicate with two others, so we used the normal serial port and the SoftwareSerial library to establish another serial connection via two digital pins. In our program we used pin 5 as receiver and pin 8 as transmitter. The first reactor was connected as usual to the computer with the USB port. Now, to connect a second reactor to this one, we connected pin 5 of the first with pin 0 (the TX pin) of the second and pin 8 with pin 1 (RX pin).
  
−
The communication system we invented works in principle as shown above. Every rector must be able to communicate with two others, so we use the normal serial port and the SoftwareSerial library to establish another serial connection via two digital pins. In our program we use pin 5 as receiver and pin 8 as transmitter. The first reactor is connected as usual to the computer with the USB port. Now, to connect a second reactor to this one, we connect pin 5 of the first with pin 0 (the TX pin) of the second and pin 8 with pin 1 (RX pin).
 
  
 
If now a message reaches one reactor from direction of the MCP the reactor program checks if the receiver ID in the message matches with the reactor ID. If so, the rest of the message is evaluated and the program reacts. If not, the message is forwarded to the next "deeper" reactor. This one checks again for the receiver ID and so on, until the targeted reactor is reached.  
 
If now a message reaches one reactor from direction of the MCP the reactor program checks if the receiver ID in the message matches with the reactor ID. If so, the rest of the message is evaluated and the program reacts. If not, the message is forwarded to the next "deeper" reactor. This one checks again for the receiver ID and so on, until the targeted reactor is reached.  
  
−
If a message goes in direction to the MCP it will be forwarded immediately, since every message towards the MCP contains measuring data because the reactors do not send messages to each other except to forward them from the MCP.
+
If a message goes in direction of the MCP it will be forwarded immediately, since every message towards the MCP contains measuring data because the reactors do not send messages to each other except to forward them from the MCP.
  
−
==='''MCP to Slave'''===
+
=MCP to Slave=
  
  
−
Using the protocol definition outlined on this page, multiple reactor controllers can communicate with the MCP to send online data, or receive new setpoints.
+
Using the protocol definition outlined on this page, multiple reactor controllers can communicate with the MCP to send online data or receive new setpoints.
  
 
Messages consist of a three-byte header and a payload with data data.
 
Messages consist of a three-byte header and a payload with data data.
Line 75: Line 77:
 
|}
 
|}
  
−
 
+
=Files=
 +
Final Arduino-Bioreactor Firmware(Slave system)
 +
#with inter slave communication: [https://static.igem.org/mediawiki/2015/2/28/Aachen_Slave_Com.zip Aachen_Slave_Com.zip]
 +
#without inter slave communication: [https://static.igem.org/mediawiki/2015/0/0b/Aachen_Slave_without_Com.zip Aachen_without_Com.zip]
  
  

Latest revision as of 02:58, 19 September 2015

Talking Between the Harware and the Software

How do the Master Control Program and the individual reactor controllers communicate with each other?

Aachen BioreactorCommunicationProtocol.png
Communication Flow


Slave to Slave

If every reactor needs one USB port for itself, we will quickly run out of USB ports on normal lab computers. Therefore it is necessary that the reactors can communicate between each other so that only one reactor needs to be connected to the computer.

The communication system we invented works in principle as shown above. Every rector must be able to communicate with two others, so we used the normal serial port and the SoftwareSerial library to establish another serial connection via two digital pins. In our program we used pin 5 as receiver and pin 8 as transmitter. The first reactor was connected as usual to the computer with the USB port. Now, to connect a second reactor to this one, we connected pin 5 of the first with pin 0 (the TX pin) of the second and pin 8 with pin 1 (RX pin).


If now a message reaches one reactor from direction of the MCP the reactor program checks if the receiver ID in the message matches with the reactor ID. If so, the rest of the message is evaluated and the program reacts. If not, the message is forwarded to the next "deeper" reactor. This one checks again for the receiver ID and so on, until the targeted reactor is reached.

If a message goes in direction of the MCP it will be forwarded immediately, since every message towards the MCP contains measuring data because the reactors do not send messages to each other except to forward them from the MCP.

MCP to Slave

Using the protocol definition outlined on this page, multiple reactor controllers can communicate with the MCP to send online data or receive new setpoints.

Messages consist of a three-byte header and a payload with data data.

  • first byte is the Sender-ID
  • second byte is the Receiver-ID
  • third byte is the MessageType
  • payload of tab-separated values

Parties in the communication are identified by ParticipantIDs. The MCP is identified with the ParticipantID = 0, a master-microcontroller is ParticipantID = 1 and slave controllers for the reactors start with ParticipantID = 2 for the first reactor.

To discriminate between measurements and commands, the protocol includes a MessageType parameter. Four different message types are supported, even though the current implementation uses just two of them.

MessageType integer value
Data 0
Command 1
DataFormat 2
CommandFormat 3

When two devices communicate about a certain parameter, they use standardized symbols. In the following table all supported dimension symbols are listed.

Parameter Symbol Unit
Dilution rate D 1/h or sph
Agitation rate n rpm
Aeration rate q_g vvm or sph
Feed rate S_fin ml/h or sph
Harvest rate S_fout ml/h or sph
Temperature T °C
Biomass Signal Biomass interrupts per measurement interval
Turbidity OD -
Biomass_Concentration X gCDW/L
O2 saturation O2  %
CO2 saturation CO2  %
CHx saturation CHx  %

Files

Final Arduino-Bioreactor Firmware(Slave system)

  1. with inter slave communication: Aachen_Slave_Com.zip
  2. without inter slave communication: Aachen_without_Com.zip



▲
Contact
CC-BY-SA iGEM Aachen 2015