User Tools

Site Tools


bfh:ti:fbe:i3s:unterricht:barkeeper:demosoftware

Carme M4 Demosoftware

Module

Allgemein

Die Demosoftware für den Barkeeper wurde in C unter Stm32CubeIDE 1.1.0 entwickelt. Der Programmablauf ist in mehrere FreeRtos Tasks unterteilt, welche miteinander kommunizieren. Als Grundlage diente das FreeRtos Template von Roger Weber. In diesem Kapitel werden nur die wichtigsten Komponenten erklärt. Details zu den Funktionen sind im Code kommentiert.



Layer

Die Software ist in mehrere funktionelle Layers unterteil. Dabei sind alle Barkeeper spezifischen Teile mit “bar_xyz” benannt und alle Hardware Zugriffsmodule mit “HW_xyz”. Die wichtigsten Layer und ihre Abhängigkeiten sind in der nachfolgenden Grafik dargestellt.



Files

Layer Filename Beschreibung
Main main.h Main File der Moisture-Node Software
Main FSM bar_mainFsm.h Die Main Finite-State-Machine, welche die übergeordnete Ablaufsteuerung des Barkeeper übernimmt.
(Systemstart, Subprogramme, Emergency Handling)
Subprogram bar_Program_pourdrink.h Ein Sub-Program das die eigentliche “Einschenk” Tätigkeit ausführt. Gesteuert von der Main FSM.
Sitemanager bar_SiteManager.h Der SiteManager ist die Schnittstelle zwischen Treiber und Subprogram.
Er überwacht alle Parameter des Modells und verwaltet eingehende CAN Nachrichten.
Robot Poses bar_RobotPoses.h Enthält alle Absoluten Positionen die vom Roboter angefahren werden. Zugriff über Positionslabels.
Bar Shelf bar_BarShelf.h Das BarShelf Modul ist für die Verwaltung der Getränke und der Gläser auf dem Regal zuständig.
SiteParameter bar_SiteParameter.h Unter SiteParameter findet sich die Definition eines Übergreifenden Struct, welcher das komplette Modell beschreibt.
Driver belt bar_Driver_belt.h Treiber für das Förderband. Enthält Funktionen für die direkte Ansteuerung.
Driver Turntable bar_Driver_Turntable.h Treiber für den Drehtisch. Enthält Funktionen für die direkte Ansteuerung.
Driver UR5 Robot bar_Driver_UR_robot.h Treiber für den Roboter und Greifer. Enthält Funktionen für die direkte Ansteuerung.
Driver Weight_Cell bar_Driver_WeighCell.h Treiber für den Waage. Enthält Funktionen für die direkte Ansteuerung.
CAN Gatekeeper HW_CanGatekeeper.h Ein gatekeeper für den CAN Lese-/ und Schreibzugriff. Alle Nachrichten werden über eine Tx und eine Rx Messagequeue versendet.
Carme CAN Driver can.h Der Carme BSP Can Treiber.
Bar HMI bar_HMI.h Human-Machine-Interface. Enthält das GUI sowie die auswertung der Carme Taster.
Carme LCD Library lcd.h Der Carme BSP LCD Treiber
Carme GPIO BSP carme_io1.h Der Carme BSP GPIO Triber
MicroTrace microTrace.h Ein kleines Log und Trace Modul welchers Log's verschiedener Quellen auf verschiedene Ziele verteilen kann.



Tasks

Alle Tasks, mit ausnahme des Subprograms, werden bei Systemstart durch die main Routine initialisiert und gestartet. Die Tasks werden in einer Endlosschlaufe mit einer fixen Zykluszeit ausgeführt. Alle zyklischen Tasks sind soweit möglich “non-block” umgesetzt. Da alle Tasks auf eine gemeinsame Speichereinheit zugreiffen, können sich Verzögerungen beim Warten auf Speicherfreigabe ergeben. In der Anwendung haben sich diese Wartezeiten nie geäussert und aufgrund der Programmierung sollte die Speicherzugriffe alle <1ms sein.

Taskname PrioritätStacksize Intervall Beschreibung
BarMainFsm 3 1024 50ms Übergeordnete FSM zur Ablaufsteuerung des Modells
BarSiteMng 3 1024 50ms Überwachen und Pollen der Parameter aller CAN Nodes
CanGatekeeper 3 1024 10ms Asynchrones Senden und Empfangen von CAN Nachrichten
Bar_HMI 2 1024 50ms Darstellen des GUI, auslesen von Taster und Schalter
Microtrace 1 1024 100ms Ausgeben von Log Nachichten auf mehreren Outputs
Subprogram 4 1024 Block Ausführen eines Ablaufs auf dem Modell. Gesteuert von MainFSM



Datenfluss Diagramm

Context

Level 1

Der Sitemanager ist im Diagramm das zentrale Element, da er Zugriffsfunktionen für die SiteState Datenstruktur enthält. Alle Module können über die SiteState Struktur den aktuellen Zustand des Modells auslesen und verändern. Der genaue Aufbau ist im Folgekapitel erläutert.



SiteState Dateistruktur

bar_SiteParameter.h

SiteState ist eine Modulübergreifende Datenstruktur, welche alle Modellparamete, Flags, Sensorwerte und Betriebszustände enthält. Der Zugriff erfolgt geschützt über den Sitemanager mithilfe folgendes Zugriffschemas (Beispiel für boot_lock):

BAR_site_t *SiteStatus = SiteMng_SiteStatusAccessEnable();
SiteStatus->robot.boot_lock = 0;
SiteMng_SiteStatusAccessDisable();

Die Access Funktion kann einen Task theoretisch bis zu einer Sekunde blockieren, danach wird eine Fehlermeldung im erzeugt und das Programm fortgesetzt. Aus diesem Grund ist es während des Zugriffs auf SiteState verboten längere Operationen auszuführen. Somit bleibt die maximale Blockierzeit <1ms.

Da die Sensordaten oder Positionsdaten im SiteStruct veraltet sein können, wird über spezielle Abfragefunktionen des Sitemanagers ein Poll ausgelöst. Alle Daten die von externen Komponenten stammen (Waage, Roboter, etc. sollten über solche Abfragefunktionen abgeholt werden. Beispiel:

SiteMng_RobotGetTcp();

Die Funktion ist non-block und liefert so lange “fail” zurück, bis ein aktueller Wert empfangen wurde. Für Details, siehe Dokumentaion im Code.

Aufbau der SiteState Dateistruktur

BAR_site_t Datentyp Beschreibung
robot Parameter des Roboterarms
tcp_coord BAR_robot_tcp_t Letzte ermittelte TCP Koordinaten
joint_angles BAR_robot_joint_t Letzte ermittelte Gelenkwinkel
error bar_nodeErrorCodes_t Fehlercodes
emergency_stop uint8_t 1=Emergency stop
protective_stop uint8_t 1=Protective Stop
robot_mode BAR_robot_mode_t Betriebsmodus Roboter, siehe Runmode
boot_lock uint8_t Sperre bei Systemstart. 0=Lock, 127=free
updatetime_rm uint32_t Zeitstempel Datenempfang “Runmode” (in ticks)
polltime_rm uint32_t Zeitstempel Pollanfrage “Runmode” (in ticks)
updatetime_ep uint32_t Zeitstempel Datenempfang “Emergency/Protective” (in ticks)
polltime_ep uint32_t Zeitstempel Pollanfrage “Emergency/Protective” (in ticks)
updatetime_j uint32_t Zeitstempel Datenempfang “Joint angles” (in ticks)
polltime_j uint32_t Zeitstempel Pollanfrage “Joint angles” (in ticks)
updatetime_tcp uint32_t Zeitstempel Datenempfang “TCP coordinates” (in ticks)
polltime_tcp uint32_t Zeitstempel Pollanfrage “TCP coordinates” (in ticks)
gripper Parameter des Greifers
object uint8_t Objektdetektion. 1=Objekt, 0=Frei. NICHT IMPLEMENTIERT, Modbus Fehler in CAN-GW
error bar_nodeErrorCodes_t Fehlercode Greifer
updatetime uint32_t Zeitstempel Datenempfang Greifer (in ticks)
polltime uint32_t Zeitstempel Pollanfrage Greifer (in ticks)
table Parameter des Drehtisches
angle uint16_t Aktueller Winkel des Drehtisch, sofern busy = 0
busy uint8_t 1=Drehtisch in Bewegung, 0=Drehtisch steht
error bar_nodeErrorCodes_t Fehlercode Drehtisch
updatetime uint32_t Zeitstempel Datenempfang Drehtisch (in ticks)
polltime uint32_t Zeitstempel Pollanfrage Drehtisch (in ticks)
belt Parameter des Förderbandes
sensor_A1 uint8_t Lichtschranke ausserhalb (User)
sensor_A2 uint8_t Lichtschranke innerhalb (Roboter)
motor uint8_t 1=Motor läuft
busy uint8_t 1=Node busy
error uint8_t Fehlercode Förderband
updatetime uint32_t Zeitstempel Datenempfang Förderbandes (in ticks)
polltime uint32_t Zeitstempel Pollanfrage Förderbandes (in ticks)
weight Parameter der Waage
weight int18_t Gewicht auf Waage
error uint8_t Fehlercode Waage
updatetime uint32_t Zeitstempel Datenempfang Waage (in ticks)
polltime uint32_t Zeitstempel Pollanfrage Waage (in ticks)
bottle[4]Parameter je Flasche auf Drehteller (Array mit 4 Elementen)
beverage_type BAR_beverage_t Getränketyp der Flasche
capacity uint16_t Die maximale Flüsigkeitsmenge der Flasche in g
weight_empty uint16_t Das Leergewicht der Flasche in g
turntable_angle uint16_t Der Drehtischwinkel an welchem die Flasche steht
fill_level uint16_t Der aktuelle Füllzustand der flasche in g (nur Inhalt, 0=leer)
shelf Parameter des Glasregals
slots[9] uint8_t 1=Slot durch Glas besetzt, 0=Slot frei
program Parameter zu Programmablauf
PourNewDrinkFlag uint8_t 1=MainFsm startet das Subprogram “PourDrink”
AddGlassFlag uint8_t 1=Das Subprogram “PourDrink” wird bei aufruf ein Glas auf das Glasregal laden
SelectedBeverage BAR_beverage_t Der Typ des auszuschenkenden Getränks
GlassSource uint8_t 0=Leeres Glas kommt vom Förderband, 1=Glas kommt aus dem Regal
SubprogRunningState BAR_program_state_t Der Zustand des Subprograms. Wird auf “SUB_PROG_STOPPED” gesetzt sobald fertig



Main FSM

bar_MainFsm.h

Das Main FSM Modul ist für die Übergeordnete Ablaufsteuerung zuständig (Roboter aufstarten, Subprogram ausführen, Emergency Handling). Es wird durch eine Zustandsmaschine gesteuert und hat den unten dargestellten Ablauf. Die Nummern an den Übergängen, bezeichen die Abfragereihenfolge der Bedingungen.



Subprogram

bar_program_PourDrink.h

Das “PourDrink” Subprogram ist wie der Name schon sagt für das Ausschenken von Getränken zuständig. Es übernimmt aber auch gleich das Einsortieren von Gläsern auf das Regal, da die Abläufe ineinander fliessen. Es handelt sich ebenfalls um eine FSM (Nachfolgend Sub-FSM genannt) welche in einem eignen Task abläuft. Dieser Task wird beim ersten Aufruf erzeugt und nach Abschluss seiner Aufgabe blockiert (Nicht gelöscht). Eine erneute Freigabe kann nur über die Main FSM erfolgen, welche den Task aber auch jederzeit Unterbrechen kann. Bei einer Unterbrechung läuft der aktuelle Zyklus noch fertig, bis der Synchronistationspunkt der Sub-FSM erreicht wird. Die Sub-FSM darf längere Task-Delays enthalten, sollte aber nach Möglichkeit keine längere blockierende Abfragen Ausführen.

Aufbau SUB-FSM State

Ein State ist immer nach dem gleichen Muster aufgebaut und in drei Sektionen unterteilt.

  • OnEnter → Wird beim ersten Eintritt ausgeführt. Zurückgesetzt bei Verlassen nach anderem Zustand
  • WaitFor → Wartet auf ein Ereigniss oder eine Abfrage
  • Timeout → Tritt die Abfrage nicht ein, kann hier ein alternativer Weg gesucht werden oder das Programm über den Timeout State verlassen werden.



Sitemanager

bar_SiteManager.h

Der Sitemanager ist ein zentrales Element, da alle Anfragen zu Modellspezifischen Parametern darüber ablaufen. Er enthält vier wichtige Komponenten:

  • CAN RX Parsing
  • CAN-Node Polling
  • Driver Wrapper
  • SiteStatus Access

CAN RX Parsing

Der Can RX Parser wird zusammen mit dem CAN Polling in einem eigenständigen Task ausgeführt. Dabei wird zyklisch geprüft ob in der Message-queue des CAN Gatekeeper Modul neue Nachrichten ankommen. Eine neue Nachricht wird nach ID klassifiziert und auf ihren Inhalt zerlegt. Dieser wird anschliessend in die Datenstruktur “SiteState” abgefüllt. Dabei wird immer ein Zeitstempel des Dateneingangs hinterlegt.

CAN-Node Polling

Die Pollingfunktionen senden jedem CAN-Node in einem fixen Intervall Statusanfragen. Dieses ist definiert durch “SITEMNG_POLLRATE_xyz”. Der Zeitstempel des letzten Poll's wird ebenfalls im SiteState abgelegt.

Driver Wrapper

Bei den Driver Wrapper handelt es sich um eine Sammlung von Funktionen, welche den Zugriff auf Parameter der CAN-Nodes Steuern. Da Daten in der SiteState Datenstruktur veraltet sein können, wird bei einer Datnanfrage (GET) erst das Alter der Daten überprüft. Ist das Alter SITEMNG_MAXAGE_xyz überschritten, wird ein neuer Poll ausgelöst (unter Einhaltung des maximalen Poll Intervall). Die Funktion wird “fail” zurückgeben. Durch wiederholtes Aufrufen der Wrapper Funktion, kann nun der Eingang der neuen Daten abgewartet werden.

Einige der Wrapper Funktionen (vorallem SET) sind nur der vollständigkeithalber im Sitemanager und werden dort direkt zum Driver weitergeleitet.

SiteStatus Access

Der SiteStatus Access besteht aus zwei Funktionen. Sie werden verwendet um von anderen Modulen direkt auf die SiteStatus Datenstruktur zuzugreiffen. Siehe Abschnitt “SitState” für Details.

SiteMng_SiteStatusAccessEnable();
SiteMng_SiteStatusAccessDisable();



HMI

bar_HMI.h

Das Human-Machine-Interface ist ein eigenständiger Task, welcher alle Ein-/Ausgaben des Users verarbeitet. Dazu läuft einerseits eine FSM welche das GUI aufbaut und aktualisiert, andererseits eine Funktion Namens “hmiInputProcessing()” welche alle Taster-Events überwacht. Wird ein Tastendruck festgestellt, wird dies in die GUI FSM weitergeleitet und dort darauf reagiert.

Die FSM des GUIs und das Input Processing werden mit unterschiedlichen Zykluszeiten ausgeführt. Das Inputprocessing bei jedem Programmloop, das GUI über die unter HMI_GUI_REFRESH_RATE Zeitrate. Das im Running Zustand angezeigte Terminal wird über ein Ringregister umgesetzt. Das MicroTrace Log Modul kann über den HMI Output Nachrichten einfügen, welche das GUI anschliessend darstellt.

bfh/ti/fbe/i3s/unterricht/barkeeper/demosoftware.txt · Last modified: 2020/01/30 12:52 by ief12