Bus System Choice

[MokshaBirk]

Considered

• CAN
• SERCOS
• EtherCat

  CAN

• Easy to implement and debug
• Messages have priorities
• Unknown delay until a message is transmitted
• Low speed
• Needs transceiver chips
• The bus is non-trivial to build

  Sercos

• Bus with hard RT properties
• Inherent cycles for setting/getting data from slaves
• Very short delay between cycles possible
• Harder to configure
• No viable master implementation found
• There is only a basic API with no HW support

  EtherCat

• Properties like Sercos
• Master: http://www.etherlab.org/en/ethercat/index.php
• Works with or without (slower) RT_PREEMPT patch for Linux
  • It should be manageable to get RT_PREEMPT working
• The master control process can be implemented using a C API

  Proposal

• Implement a quick-and-dirty CAN bus so sensors and actuators can be steered
• When CAN works on a basic level try to set up basic EtherCat master/slave communication
  • Let the master talk to a proprietary slave
  • When the master works, try to set up a slave on a BeagleBone Black
• Implement the EtherCat control process

TODO: Decide on a deadline for basic EtherCat operations. It it's not working by then, improve the CAN bus

[xkonni]

Ja klingt grundsätzlich nach nem guten Plan. Dann holen wir uns von Vlado mal ein paar BeagleBones und machen eine Liste was wir noch bestellen wollen.

[MokshaBirk]

Planänderung: CAN ist aufwändiger zu implementieren als ich erst dachte und die EtherCat Masterkomponente habe ich schon laufen (ohne Kommunikation mit Slaves bisher). Ich würde also direkt EtherCat nehmen, da sind Hardware und Software schon verfügbar. Ansonsten bin ich gerade dabei die Konfiguration der BeagleBones mit Ansible zu automatisieren