Benutzerhandbuch. User Manual

smart can - smart controller area network Benutzerhandbuch User Manual 3. Juni 1993 Rolf Uhlig Computer GmbH & Co. KG Sendenhorster Str. 32 48317 Drensteinfurt

Inhalt INHALT 1. smart can. Das Mikrocontroller Netzwerk... 6 1.1 Industrie-PC... 6 1.2. Feldbus... 6 1.3. Buszugangskonzepte... 6 1.4. MCL/3... 7 1.4.1. Prozeßsteuerung... 7 1.4.2. Kommunikation... 8 1.4.3. Datentypen... 8 1.4.4. Kontrollstrukturen... 8 1.4.5. Statemachine... 9 1.4.6. Prozeduren... 9 1.4.7. Event-Behandlung... 9 1.4.8. Weitere Sprachbestandteile... 9 1.5. Logbuch... 10 2. Das smart can Netzwerk... 11 2.1. Die Einordnung von smart can in das ISO/OSI-Referenzmodell... 11 2.1.1. Physical Layer (Schicht 1)... 11 2.1.2. Data Link Layer (Schicht 2)... 11 2.1.2.1. Format einer Nachricht... 11 2.1.2.2. Kommando-Acknowledge, FlipBit... 12 2.1.2.3. Datenblock... 13 2.1.3. Medium Access Sublayer... 13 2.1.3.1. Adressierung... 13 2.1.3.2. Multicast und Broadcast... 15 2.1.3.3. Bus-Zugangsverfahren... 15 2.1.4. Schicht 3-6... 17 2.1.5. Application Layer (Schicht 7)... 17 2.2. Beschreibung der Netzkommandos... 18 3. Der Systemkern... 69 3.1. Aufbau des Systemkerns... 69 3.2. Aufbau des Logbuchs... 70 3.3. Fehlermeldungen des Systemkerns... 71 3.3.1. Laufzeitfehler... 71 3.3.2. Benutzerdefinierte Fehler... 74 3.3.3. Fehler von Systemerweiterungen... 74 3.3.4. Timeout-Fehler... 75 3.3.5. Parameter-Fehler in Anweisungen... 76 3.3.6. Kommunikationsfehler über das Netzwerk... 76 3.3.7. Traps und Exceptions des Anwendungsprozessors... 77 3.4. Weitere Logbuch Einträge... 80 3

Inhalt 3.5. Systempuffer... 85 3.5.1. Systemvariablen des SysVarBuffers... 86 3.5.2. Systemvariablen des CoaxSysVarBuffers... 89 3.5.3. Belegung des I/O-Konfigurationspuffers... 91 3.5.4. Memory Usage Buffer... 91 3.5.5. System Extension Table... 92 3.5.6. Weitere Systempuffer... 93 3.6. Systemcalls... 94 3.7. Systemdeskriptoren... 95 3.8. Einbinden von Systemerweiterungen... 96 3.8.1. Aufbau einer Systemerweiterung für die WSC-CPUs... 96 3.9. Schnittstellen-Unterstützung... 99 3.9.1. Schnittstellen der TMPZ84C013-ECB CPU... 99 3.9.2. Schnittstellen der Z280-ECB CPU... 100 3.9.3. Schnittstellen der i286-at-slot CPU... 102 3.9.4. Schnittstellen der WSC-ECB CPU... 103 3.10. Setup der Power-On Defaults... 106 3.10.1. Setup der WSC91280 CPUs... 106 3.11. Das Bootsystem... 114 4. Interface zur Applikation/PC... 115 4.1. Das Mastercard-Interface MCARD... 115 4.1.1. Installation... 115 4.1.2. Schnittstelle über Softwareinterrupt... 115 4.1.3. Interne Funktionen... 116 4.1.4. Kommandocodes... 116 4.1.5. Responsecodes... 120 4.1.6. Turbo-Pascal Unit zum MCARD-Interface... 122 5. Analyse- und Entwicklungs-Tools für den PC... 124 5.1. PLOAD - smart can Commandline Steuerung... 124 5.2. MLOAD - Mastercard-Betriebsystem laden... 137 5.3. NETQUAL - Netzgüte Analysator... 138 6. Hardware... 139 6.1. TMPZ84C013-CPU... 139 6.2. Z280-CPU... 139 6.3. WSC-CPU... 140 6.4. i286 AT-Slot-Mastercard... 140 6.5. I/O-Karten... 140 7. Quick Start... 141 7.1. Installation der Hardware... 141 7.2. Installation der Software... 141 7.3. Erstellen eines MCL-Programmes... 142 7.4. Start und Abfrage der CPU... 142 4

Inhalt Anhang A. Glossar... 143 Anhang B. Systemerweiterung Motorsteuerung... 151 B.1. Routinen (SYSCALLs) des Moduls... 151 B.2. Aufbau des Variablenbereichs des Moduls... 152 B.3. Header des Motorsteuerungsmoduls... 153 B.4. Motorsteuerung für Code Level 1 und 2... 153 B.5. Fehlermeldungen der Motorsteuerungssoftware... 154 B.6. Statusmeldungen im Logbuch... 156 Index... 157 Copyright 1991, 92, 93 by ruc - Rolf Uhlig Computer GmbH & Co. KG 5

1. Ein Microcontroller Netzwerk 1. SMART CAN. DAS MIKROCONTROLLER NETZWERK smart can ist ein Steuerungskonzept, das voll auf dezentraler Intelligenz aufbaut. Im smart can gibt es kein zentrales Rechenwerk, ähnlich einer SPS. Die Steuerungsaufgaben werden autark von den vernetzten Prozeßsatelliten wahrgenommen. 1.1 Industrie-PC smart can ist PC-basiert. Da auch ein Industrie-PC nur bedingt prozeßtauglich ist (Industrie-PC bezieht sich eher auf Schutzarten, Gehäuseform, Zuverlässigkeit der Komponenten), muß er durch geeignete Hardware erweitert werden. Im smart can ermöglicht eine intelligente Prozeßleitkarte den Zugriff auf das Microcontroller Netzwerk. Diese Leitkarte hat in der Initialisierungsphase, nach Einschalten eines Automaten die Aufgabe, Ablaufprogrammme vom PC an die Prozeßsatelliten zu verteilen und dort zu starten. Über sie kann der PC zwar während eines laufenden Prozesses direkt auf Satelliten zugreifen, ihm obligen aber in der Hauptsache administrative Aufgaben (Bedienerschnittstelle, Produktionsplan, Interface zu übergeordneter EDV (PPS)). Die Prozeßsatelliten übernehmen segmentweise die Aufgaben einer 'lokalen SPS' mit wesentlich erweiterten Möglichkeiten und tauschen Informationen über das smart can COAX Netz mit bis zu 2,5 MBit/s untereinander und mit dem Industrie-PC (Quasi Satellit) aus. Da im smart can die Ablaufprogramme erst während der Initialisierung vom Industrie-PC in die Prozeßsatelliten geladen werden (kein Ablaufprogramm im EPROM) ist der Prozeß beliebig konfigurierbar. Der PC dient als Entwicklungs und Integrationsplattform bei der Entwicklung eines Automaten, durch die Benutzerobefläche wird er zur Bedienerplattform. Für die Programmierung, den Service, die Bedienung sind keine unterschiedlichen Geräte erforderlich. 1.2. Feldbus Mit smart can wird eine scharfe Segmentierung von Prozessen möglich, Funktionen werden Prozeßsatelliten zugewiesen die vor Ort weitestgehend autark bearbeitet werden können. Die Kommunikation zwischen den Satelliten beschränkt sich auf verdichtete Informationen und Synchronisationspunkte. Das dauernde Abfragen von Sensoren, Meßstellen vom zentralen Rechnersystem über das Netz entfällt. Die Nachteile serieller Kommunikation (Performanceverlust, besonders bei starkem Datenfluß mit geringen Informationsgehalt) werden durch Segmentierung in Anlehnung an die Struktur des Prozesses aufgehoben. Die Forderung beim Einsatz von serieller Kommunikation (wie in Feldbussystemen verwendet) kann nur sein, die Art der Information so zu gestalten, daß die zeitliche Einbuße durch die Mächtigkeit der Information ausgeglichen wird. Die Voraussetzung für Informationsverdichtung ist, im Prozeßsegment nicht nur Mittel zur Definition des Prozesses zu haben, sondern echte Datenverarbeitung im Segment durchführen zu können. Hiermit ist auch die Grundlage für Qualitätssicherung, Maschinen- und Betriebsdatenerfassung im Prozeßsegment geschaffen. 1.3. Buszugangskonzepte smart can erlaubt durch drei unterschiedliche Buszugangsverfahren, das für den jeweiligen Anwendungsfall schnellste und sicherste Verfahren auszuwählen. Ein Master/Slave-Prinzip mit Vergabe des Busmasters während des Prozessablaufs ist vorteilhaft, wenn die Netztransferzeitpunkte innerhalb eines Prozesszyklus immer gleich sind und die Kommunikationsrichtung zwischen den CPUs bekannt ist. Es kann jeweils nur eine CPU Busmaster sein und Daten senden (außer in "Notsituationen", wo Kollisionen akzeptiert werden können). Ein CSMA (Carrier Sense Medium Access) Buszugang mit deterministischer Kollisionsauflösung wird verwendet, wenn die Netztransferzeitpunkte innerhalb eines Zyklus veränderbar sind oder die Kommunikationsrichtung zwischen den CPUs nicht vorhersagbar ist. Einzelnen CPUs wird im Falle einer Kollision zweier Netznachrichten eine höhere Priorität zugeteilt, damit CPUs mit höherer Priorität ihre Nachrichten vor CPUs mit niedriger Priorität versenden können. Ein CSMA Buszugang mit nichtdeterministischer (zufälliger) Kollisionsauflösung wird verwendet, wenn es nicht relevant ist, welche CPU im Falle einer Kollision priorisiert ist. Alle CPUs sind gleichberechtigt. 1.4. MCL/3 Dieser konzeptionelle Ansatz ist Grundlage für die Definition und Implementation der Hochsprache MCL/3 (Machine Control Language 3) in den Prozeßsatelliten des smart can. Das MCL/3 Ablaufprogramm wird über das Mikrokontrollernetzwerk in den Prozeßsatelliten geladen und dort interpretativ abgearbeitet. Auf dem Netzwerk sind homogene Bedingungen, da die Umsetzung von MCL/3 in Mikroprozessoranweisungen erst im Satelliten erfolgt. So können unterschiedliche Prozessorfamilien am smart can teilnehmen, ohne das der Anwendungsprogrammierer darauf Rücksicht nehmen muß. 6

1. Ein Microcontroller Netzwerk MCL/3 deckt die drei wichtigen Bereiche in Mikrokontrollernetzwerken: x Prozeßsteuerung/Regelung x Kommunikation x Datenverarbeitung durch Hochsprachenmittel, angelehnt an die Syntax von Pascal und Modula 2 ab. Der Interpreter arbeitet registerlos mit CISC (Complex Instruction Set) 3-Adress-Instruktionen. Die Sprache MCL/3 ist im MCL/3 Referenzhandbuch beschrieben. 1.4.1. Prozeßsteuerung Für das Abfragen von Sensoren und die Ansteuerung von Aktoren ist jeder Prozeßsatellit seiner Aufgabe angemessen mit I/O Hardware ausgestattet. Über Befehle können bit- oder portweise Ausgänge gesetzt und zurückgesetzt werden. OUT1 (Bit#) setzt den Ausgang Bit#, OUT0 setzt ihn zurück. Für die Impulsansteuerung von Ausgängen (z.b. Impulsventilen) kann mit OUTP (Zeit, Bit#) am Ausgang ein Impuls erzeugt werden. Das Ablaufprogramm arbeitet weiter, der gesetzte Ausgang wird nach abgelaufener Zeit zurückgesetzt. OUTPORT (Wert, Port#) gibt einen acht Bit Wert an einen Ausgangsport aus, OUTSTR (ComPort#, String) gibt einen ASCII String (wahlweise mit führendem Längenbyte oder Null terminiert) an einer der Datenschnittstellen (V24, Centronix) des Prozeßsatelliten aus. Über diese Datenschnittstellen können Fremdeinheiten adaptiert werden (z.b. Protokolldrucker, weitere Steuereinheiten). Die Befehlsgruppe PUTIO, CLRIO und SETIO gehört ebenfalls zu den Befehlen der Prozeßsteuerung. Mit ihnen können aber zusätzlich Ausgänge auf anderen Satelliten manipuliert werden, sie beinhalten implizit Kommunikation über das Mikrokontroller Netzwerk. Um Ausgänge zeitlich definiert, aber unabhängig vom Ablaufprogram schalten zu können, dient die Befehlsgruppe DELAYPUTIO, DELAYSETIO, DELAYCLRIO. Die Abfrage von Sensoren kann auf zwei unterschiedliche Weisen erfolgen. WAIT0 (Bit#) und WAIT1 (Bit#) sind Warteschleifen die erst abgebrochen werden, wenn eine Zustandsänderung eintritt (WAIT0 (Bit#): Warte solange wie Bit# gleich Null ist (inaktiv)). Die Eingänge können auch nur auf Status abgefragt werden (IF IN0 THEN..). Ebenso ist die Abfrage eines acht Bit Ports möglich (INPORT (Variable, Port#)), das Einlesen aus den Datenschnittstellen der Satelliten ist mit INSTR (Variable, ComPort#) einfach zu realisieren. Mit GETIO (Variable, Port#, Satellit#) können auch von anderen Satelliten im Netz Ports abgefragt werden, hier findet implizit Kommunikation über das Mikrokontrollernetzwerk statt. 7

1. Ein Microcontroller Netzwerk 1.4.2. Kommunikation Befehle zur Kommunikation zwischen den Satelliten im smart can Microcontroller Netzwerk sind eine wichtige Erweiterung einer Programmiersprache für Systeme dezentraler Intelligenz. Dem Anwendungsprogrammierer müssen Sprachmittel zur Verfügung stehen, die den problemlosen Informationsaustausch oder Aktionsverknüpfungen ermöglichen. In MCL/3 stehen für den Austausch von Kommandos unter anderem die folgenden Befehle zur Verfügung: SENDCMD (Satellit#, Kommando#) erlaubt das Verschicken von internen und benutzerdefinierten Kommandos an andere Satellitenrechner. Durch besondere Netzkommandos kann auch ein Multicast an Satellitengruppen oder ein Broadcast an alle Netzteilnehmer mit SENDCMD gesendet werden. WAITCMD (Satellit#, Variable) Bei WAITCMD handelt es sich um eine Warteschleife, die den Satellitenrechner veranlaßt, auf ein an ihn gerichtetes Kommando zu warten. Das Ablaufprogramm muß nach Empfang das Kommando auswerten und die entsprechenden Aktionen einleiten. Der Austausch von Daten (wie z.b. prozeßbestimmende Parameter, QS-Informationen, Operatoreinstellungen) zwischen Prozeßsatelliten ist mit den Befehlen SENDVAR (Quellvariable, Zielsatellit, Zielvariable, Datenlänge) und GETVAR (Zielvariable, Quellsatellit, Quellvariable, Datenlänge) möglich. GETVAR und SENDVAR können Datenblöcke bis zu 255 Bytes mit einem Aufruf übertragen. Reicht das Ändern von Flags (Merkern, intern oder benutzerdefiniert), um anderen Satelliten etwas mitzuteilen, können die Befehle SETFG (Satellit#, Merker) und GETFG (Satellit#, Merker) verwendet werden. 1.4.3. Datentypen In MCL/3 sind die wichtigsten Datentypen (Byte, Word, Array, Text, etc.) verfügbar. Die Typprüfung durch den Compiler ist strikt. Hervorzuheben sei hier der Typ OBJECT mit allen Eigenschaften objektorientierter Programmierung, wie Datenkapselung, Vererbung, privaten Methoden und Daten. Mit MCL/3 ist objektorientierte Programmierung möglich, dem Programmierer steht ein modernes Programmierkonzept auch auf Prozeßsatellit-Ebene zur Verfügung. Der MCL/3 Compiler erlaubt die arithmetische Verarbeitung von Parametern mit einer Genauigkeit von 8 bis 64 Bit. Die Verarbeitung wird automatisch den übergebenen Parametern angepaßt, um maximale Rechengeschwindigkeit zu erhalten. Die Arithmetik umfaßt die Grundrechenarten, logische Operationen und Bitmanipulation. Spezielle, nicht in MCL/3 enthaltene Operatoren, können programmspezifisch definiert werden. Für die Bearbeitung von Strings sind in MCL/3 mächtige Operationen implementiert. Es können sowohl Null terminierte Strings (C Notation) als auch Strings mit führendem Längenbyte (Pascal Notation) bearbeitet werden. 1.4.4. Kontrollstrukturen Wie jede Hochsprache besitzt MCL/3 algorithmische Strukturen wie Prozeduren, Operatoren, Unterprogrammaufrufe, Module und Refinements. Exemplarisch sei an dieser Stelle das Sprachmittel Refinement (Verfeinerung) beschrieben. Refinements sind, ähnlich wie Makros, keine Unterprogramme, sondern werden vom Compiler als Codeblock an der Aufrufstelle eingesetzt. Der Vorteil ist die schnelle Ausführung des Codes, da kein Unterprogramm angesprungen werden muß (mit dem notwendigen Overhead). Bei Mehrfachaufrufen wird mehr Code erzeugt. Das Refinement unterstützt die Top-Down Implementation von Problemstellungen. Das Problem kann in übersichtliche Abschnitte gegliedert werden, die funktionale Implementation erfolgt erst auf unterster Ebene. Mit dem Sprachmittel Refinement und der Verwendung langer Bezeichner, ist es leicht möglich selbst dokumentierenden Code zu schreiben. Zur Ablaufsteuerung des MCL/3 Programmes stehen die üblichen Schleifen FOR..TO..DO (Anzahl Schleifendurchläufe ist vorher bekannt), WHILE.. DO (abweisende Schleife), REPEAT.. UNTIL (nicht abweisende Schleife) und LOOP (Endlosschleife) zur Verfügung. Weitergehend sind Entscheidungen IF..THEN..ELSE und die Auswahl CASE.. implementiert. 1.4.5. Statemachine 8

1. Ein Microcontroller Netzwerk Eine syntaktische Besonderheit ist die Statemachine, die den Ablauf des Programms als Zustandsübergangstabelle steuert. Die State Machine wird durch die Schlüsselwörter STATE und ENDSTATE eingerahmt. Ruft man die State Machine in einer Endlosschleife auf, so hat man ein SPSähnliches Verhalten des Prozeßsatelliten. Die Kontrollstruktur Statemachine erlaubt die Umsetzung einer graphischen Beschreibung eines endlichen Automaten (Zustandsübergangsdiagramm) in eine textuelle Beschreibung. 1.4.6. Prozeduren Mit Prozeduren können, wie aus Pascal bekannt, häufig gebrauchte Algorithmen implementiert werden. Die Übergabe von Parametern an Prozeduren mit Zurückliefern von Ergebnissen vereinfacht die Implementation wiederkehrender Teilabläufe mit unterschiedlicher Parametrisierung. Prozeduren können in linkbaren Objektmodulen zusammengefaßt werden. 1.4.7. Event-Behandlung Für nicht vorher bestimmbare Ereignisse wie z.b die unerwartete Änderung eines Eingangs, der Ablauf eines Timers, das Ändern eines globalen Flags durch einen anderen Satelliten oder das Eintreten einer Fehlerbedingung, können Eventhandler installiert werden. Dieses sind Unterprogramme die im Falle des Eintretens eines Ereignisses durchlaufen werden, während das Abarbeiten des Hauptprogramms gestoppt ist. Nach Verlassen des Eventhandlers kann das Hauptprogramm fortgesetzt werden (Syntax : z.b. ONTIMER (Timer#, Unterprogramm) veranlaßt den Unterprogrammaufruf bei Ablauf des Timers). 1.4.8. Weitere Sprachbestandteile Natürlich werden in MCL/3 alle Hardwareeigenschaften der smart can Komponenten unterstützt. So können Hardwaretimer bedient werden, Digital-Analog (und umgekehrt) Wandlung wird unterstützt bis hin zu kundenspezifischen Befehlen, die z.b. die Positionierung eines AC-Servo Antriebes übernehmen. Für die zeitliche Überwachung von Abläufen lassen sich für jeden Eingang (auch für Datenschnittstellen) Timeoutbedingungen definieren, die bei Eintreten den Sprung in ein Unterprogramm erzwingen. Dort kann dann die Situation analysiert und behandelt werden, um danach im Hauptprogramm fortzufahren. Diese Eigenschaft von MCL/3 und smart can ermöglicht die Einpassung der realen Abläufe auf Erwartungshorizonte und Ereignisfelder. Abnorme Verläufe können erkannt und dokumentiert werden, die darauf folgende Analyse deckt Störungen auf. 1.5. Logbuch Während des Ablaufs eines Programms auf einem Satelliten wird ein lokales Logbuch geführt in dem außergewöhnliche Ereignisse protokolliert werden. Diese Ereignisse können systemimmanent oder vom Programmierer definiert sein. Mit LOGSTAMP (#) wird eine Zeitmarke im Logbuch gesetzt. Aus dem Logbuch ist dann die absolute Zeit des Eintrages zu erkennen und das Zeitintervall zum nächsten LOGSTAMP. Für die Protokollierung von Variableninhalten kann der Befehl LOGVAR (#, Variable) verwendet werden. Aus dem Logbuch ist dann der Inhalt der Variablen zu einem bestimmten Zeitpunkt zu erkennen. Das Logbuch kann zu Zwecken der Fehlersuche in einem Ablaufprogramm verwendet werden. Bei entsprechender Definition kann auch ein Statusbericht über das Zeitverhalten der einzelnen Bewegungsabläufe aus dem Logbuch entnommen werden. Hier erhält man dann wichtige Informationen zur vorbeugenden Wartung und somit zur Verringerung von Maschinenstillstandszeiten. 9

2. Die Netzwerkfunktionen 2. DAS SMART CAN NETZWERK 2.1. Die Einordnung von smart can in das ISO/OSI-Referenzmodell Die Schichteneinteilung des ISO/OSI-Modells wurde beim Design von smart can als Vorschlag verstanden. Größeres Augenmerk wurde auf die sinnvolle Aufteilung der Dienste und Aufgaben auf Kommunikations- (CuP) und Applikationsprozessor (AuP) gelegt. Das Interface zwischen MAC-Layer und Application-Layer ist auch das Interface zwischen CuP und AuP. Auf Feldbus- und Steuerbus-Ebene ist es sinnvoll die Layer ISO- 3 bis ISO-6 nicht zu implementieren, da die Nutzung der Dienste dieser Layer zu Lasten des Datendurchsatzes und der Antwortzeit gehen. 2.1.1. Physical Layer (Schicht 1) Die (Basisband-)Datenübertragung findet mit Frequenzen von ca. 5 MHz statt. 13-Bit-Blöcke (10 Datenbits, Startbit, Paritybit, Stopbit) werden Manchester-codiert und -dekodiert. Dadurch ist eine gute Störunanfälligkeit gegeben. 2.1.2. Data Link Layer (Schicht 2) Der Kommunikationsprozessor behandelt die Aufgaben des Data Link Layers. Das sind CRC-Berechnung mit einem 16-Bit CRC-Polynom nach CCITT, Paritycheck für jedes Byte, konfigurierbare Zahl von Übertragungswiederholungen bei Empfangsfehlern und Versenden einer Acknowledge-Nachricht an den Absender. 2.1.2.1. Format einer Nachricht TYPE HEADER = STRUCT ( BYTE To, From, Master, WORD Cmd, BYTE Len, WORD Crc) ; Das CRC-Wort wird dem Anwendungsprozessor nicht bekannt gemacht. 10

2. Die Netzwerkfunktionen þüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüÿ ý(psilqý$evhqý%xvý&rppdqgý&rppdqgý'dwhqý&5&ý&5&ý ýjhuýghuýpdvwhuý/rzý+ljkýolqjhý&&,77ý&&,77ý ý$guhvvhý$guhvvhý)ols%lwýý$fn%lwýý/rzý+ljký üüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüü 1. Byte: Empfängerkarte. CPU-ID der Empfängerkarte. Hier sind alle Werte von 00-FF erlaubt. 2. Byte: Absenderkarte. Dieses Byte enthält die Nummer der Karte, die die Nachricht gesendet hat. Hier sind keine Adressen F0-FF erlaubt. 3. Byte: Neuer Busmaster. Dieses Byte enthält die Nummer der Karte, die mit dieser Nachricht Busmaster werden soll (im Master/Slave-Buszugangsmodus). Busmaster kann nur eine CPU im gleichen Netzsegment werden. Es sind nur Busmaster 00-1F erlaubt. Bit 7 in diesem Byte ist das FlipBit. Dieses Bit wird von Nachricht zu Nachricht einer CPU geändert (ge"flipt"). Dadurch ist sichergestellt, daß gleiche Meldungen von der gleichen CPU, die aufeinanderfolgen, nicht als Sendretry betrachtet werden. 4. und 5. Byte: Kommando. (In der Reihenfolge Lowbyte, Highbyte). Kommandos mit den Nummern 7F00h-7FFFh werden vom Netzinterpreter ausgewertet, Kommandos 0000h-7EFFh können als User-Kommandos mit SENDCMD gesendet und mit WAITCMD oder WAITMSG empfangen werden. Ist Bit 7 im 5. Byte gesetzt, dann ist diese Nachricht eine Bestätigung des Empfängers über den Empfang der Nachricht (ACK). Diese Bestätigung wird an den Absender geschickt, wenn die Nachricht keine Broadcast- oder Multicast-Nachricht ohne Quittung (Empfänger = FC..FF) war. 6. Byte: Datenlänge. Folgen dem Header (1.-8. Byte) noch Datenbytes (z.b. Parameter), dann gibt das 6. Byte an, wieviele Datenbytes noch folgen. Die Datenblockgröße kann zwischen 0 und 255 Bytes betragen. 7. und 8. Byte: CRC Die 16-Bit-Prüfsumme wird mit dem Polynom X 16 +X 12 +X 5 +X 0 über die ersten 6 Bytes des Headers berechnet. Ab. 9. Byte: Eventuell vorhandene Datenbytes. Die Prüfsumme über den Datenbereich wird als letztes und vorletztes Datenbyte an die Nachricht gehängt. 2.1.2.2. Kommando-Acknowledge, FlipBit Nachdem die Nachricht abgesandt wurde, wartet der Absender die Zeit SVCRTimeout auf ein Acknowledge (kurz ACK) von der adressierten Karte ab. Bei einem Acknowledge ist das Bit 7 des 5. Bytes (Kommando High) gesetzt; das Kommando der quittierten Nachricht wird in den Kommandobytes des ACK's wiederholt. Im Normalfall (SVCRTimeout nach Reset) dauert es 3-5ms, bis eine Übertragungswiederholung gestartet wird, falls kein oder ein falsches ACK empfangen wird. Über die CoaxSysVariable SVCMaxRetry kann das MCL-Programm festlegen, wieviele Übertragungswiederholungen maximal versucht werden, bevor die Übertragung mit einem SENDERROR abgebrochen wird. Die Voreinstellung ist SVCMaxRetry=8. Zum einen kann die Nachricht selbst gestört werden, was zur Übertragungswiederholung führt, da der Empfänger die Mitteilung nicht empfangen hat und deshalb kein ACK schicken kann. Zum anderen kann das Ack auf eine korrekt empfangene Mitteilung gestört werden, was auch zur Übertragungswiederholung führt. Da allerdings der Nachrichtenempfänger die Aktion zu dieser Nachricht bereits ausgeführt hat und die gleiche Nachricht 3-5ms später nocheinmal als Sendretry eintrifft, würde er ohne besondere Vorkehrungen die Aktion nocheinmal ausführen, was nicht erlaubt ist. Der Empfänger kann nicht wissen, daß sein ACK nicht richtig angekommen ist. Die Lösung ist das FlipBit, das auf der sendenden Karte nur dann verändert wird, wenn das ACK korrekt empfangen wurde. Dadurch ist sichergestellt, daß die Empfänger-CPU eine Übertragungswiederholung erkennen kann, weil sich das FlipBit seit der letzen Nachricht nicht geändert hat. Korrekt empfangene identische Mitteilungen nacheinander unterscheiden sich damit also immer noch durch das FlipBit. Die 11

2. Die Netzwerkfunktionen Empfänger-CPU sendet nach jeder empfangenen Nachricht ein ACK, aber führt die Aktion auf eine Mitteilung nur aus, wenn die Mitteilung keine Übertragungswiederholung ist. Auf eine per Broadcast gesendete Mitteilung wird kein ACK gesendet. 2.1.2.3. Datenblock Falls eine Nachricht von einem Datenblock gefolgt wird, wird die Zahl der dem Header folgenden Datenbytes im 6. Byte angegeben. Ist das Feld Datenlänge 0, dann existiert kein Datenblock und auch keine Prüfsumme für den Datenblock. Die maximale Datenblocklänge pro Mitteilung ist z.zt. auf 255 Bytes beschränkt. Dem Datenblock folgen noch zwei Prüfsummenbytes, die mit dem selben Algorithmus berechnet werden, wie die Headerprüfsummenbytes. Auch ein Ack kann einen Datenblock besitzen (Abfrage von Daten auf der Empfänger-CPU). 2.1.3. Medium Access Sublayer Der Kommunikationsprozessor übernimmt die Aufgaben des Medium Access Sublayers. Er organisiert die Anforderung und Abgabe des Busmaster-Status. Er erkennt neue Adressen auf dem Bus und informiert die anderen Busteilnehmer über die Adressen der am Bus kommunizierenden Karten. 2.1.3.1. Adressierung Das erste Byte einer Nachricht ist durch ein gesetztes 9. Datenbit kenntlich gemacht. Das erste Zeichen ist die Adresse der Empfänger-CPU dieser Nachricht. Alle Netzteilnehmer müßen jede Nachricht (bzw. den Header) auswerten, um den in der Mitteilung übertragenen aktuellen Busmaster zu kennen. Die 256 möglichen Adressen sind in Gruppen eingeteilt: 00-1F sind CPUs die innerhalb eines Netzstranges adressiert werden. CPU 00 ist immer die Mastercard. Pro Strang gibt es genau eine Mastercard. 20 ist eine passive Diagnose- oder Monitor-CPU. CPUs mit dieser Adresse sind zwar unter ihrer CPU-Adresse adressierbar, sie reagieren aber nicht auf Broadcasts und erhalten auch keine Lifecharacters. Sie sind den anderen CPUs auch nicht bekannt und werden in der Liste der am Netz installierten Karten nicht mitgezählt. Eine CPU kann auf Adresse 20 eingestellt werden, indem die fünf Adress-DIP-Schalter auf 00000 gestellt werden. 21-7E sind reserviert. 7F ist der PC in dem sich bis zu vier Mastercards befinden können. Pro Netz kann es nur einen PC gegen. Z.Zt. reagiert der PC nur auf User-Kommandos und nicht auf Systemkommandos. Kommandos wie I/O-Port-Abfrage auf dem PC sind also nicht implementiert. 80-9F sind absolut adressierte Karten am Strang der Mastercard 0. 80 ist die Mastercard mit der CardId=0. A0-BF sind absolut adressierte Karten am Strang der Mastercard 1. A0 ist die Mastercard mit der CardId=1. C0-DF sind absolut adressierte Karten am Strang der Mastercard 2. C0 ist die Mastercard mit der CardId=2. E0-EF sind absolut adressierte Karten am Strang der Mastercard 3. E0 ist die Mastercard mit der CardId=3. An diesem Strang können zwar mehr als 16 Karten angeschloßen sein, aber nur 16 können von anderen Strängen absolut adressiert werden. F0-F7 sind reserviert. 12

2. Die Netzwerkfunktionen F8-FB sind Multicast-Adressen mit Quittung. Durch das Kommando SETMULTICARDS werden die Multicast-Teilnehmer einer Multicast-Adresse zugeordnet. Maximal sind 32 Teilnehmer an einer Multicast-Adresse möglich. Eine Karte, die eine Multicast-Adresse F8-FB als Empfängeradresse verwendet, erhält von allen Multicast-Teilnehmern eine Quittung. Adresse FB ist per Default mit allen am Strang angeschlossenen Teilnehmern vorbesetzt. Diese Adresse wirkt wie ein Broadcast mit ACK. FC-FE sind Multicast-Adressen ohne Quittung. Durch das Kommando SETMULTICARDS werden die Multicast-Teilnehmer einer Multicast-Adresse zugeordnet. Maximal sind 32 Teilnehmer an einer Multicast-Adresse möglich. Eine Karte die eine Multicast-Adresse FC-FE als Empfängeradresse verwendet, erhält keine Quittung. FF ist die Broadcast-Adresse. Alle CPUs erhalten die Mitteilung, aber quittieren sie nicht. Als Absenderadressen sind keine Adressen F0-FF erlaubt. Als Busmasteradressen sind nur Adressen 00-1F erlaubt. Ob eine Strangübergreifende absolute Adressierung mit den Adressen 7F-EF möglich ist, hängt von der Version der Host-Software (z.b. MCARD.EXE für PCs) ab. Ältere Versionen bieten diese Möglichkeit noch nicht. Je nach adressierter CPU wird das Timing für die Übertragung festgelegt. Dazu existiert in jeder CPU eine Tabelle, die für jede Empfänger-CPU die Wartezeit zwischen der Übertragung von zwei Zeichen festlegt. Diese Wartezeit ist nötig, damit langsame CPUs, bei denen einzelne Zeichen per Interrupt-Routine ausgelesen werden, nicht einen Teil der Nachricht verschlucken. Die Tabelle ist im CoaxSysVarBuffer unter dem Namen SVCSendDelays zu finden. 2.1.3.2. Multicast und Broadcast Bei Multicast oder Broadcast erhalten mehrere CPUs ein Kommando zur gleichen Zeit. Diese Gleichzeitigkeit ist ein Vorteil bei synchroner Aktivierung oder bei synchronem Abfragen von Daten. Ein Broadcast wird nicht quittiert, d.h. falls eine CPU die Broadcast-Nachricht nicht empfangen hat, erhält der Absender darüber keine Mitteilung. Ein Multicast kann mit oder ohne Quittung erfolgen. Diese Quittung kann auch Daten enthalten, wodurch es z.b. möglich ist eine Statusvariable oder ein Flag auf mehreren CPUs gleichzeitig abzufragen. Die zu einer Multicast-Adresse gehörenden Teilnehmer müßen einmal zu Beginn allen Stationen per Broadcast mit dem Netzkommando CMD_SETMULTICARDS mitgeteilt werden. Anschließend genügt die Angabe der Multicast-Adresse. 13

2. Die Netzwerkfunktionen 2.1.3.3. Bus-Zugangsverfahren smart can stellt drei Bus-Zugangsverfahren zur Verfügung: x Master/Slave-Prinzip mit 3 Varianten der Busmaster-Anforderung. x Carrier Sense (CSMA) mit CPU-ID abhängiger Buszuteilung (deterministisch). x Carrier Sense mit zufälliger Buszuteilung (nicht deterministisch). Falls CSMA ohne Collision Detect implementiert ist (z.zt. auf allen CPUs), wird nach 3-5ms die Übertragung wiederholt. 1. Master/Slave-Buszugang Mitteilungen werden nur vom Busmaster an andere CPUs gesendet. Der aktuelle Busmaster kann vom Programm aus der Systemvariablen SVMaster entnommen werden. Die Nachricht wird sofort versendet und nach 1-2ms (typ. 1.5ms für Datenaustausch zwischen ISO-Layer 7) von der Empfänger-CPU beantwortet. Muß eine Nachricht ausnahmsweise von einer CPU versendet werden, die nicht Busmaster ist, dann muß sie erst den Busmaster-Status anfordern. Dies kann durch eine vorgeschaltetes GETMASTER-Kommando oder direkt durch das zu sendende Kommando geschehen. Die Busmaster-Anforderung wird solange zurückgehalten, bis der Bus frei ist. Zu diesem Zweck versendet der (Noch-)Busmaster in regelmäßigen Abständen von ca. 10 Millisekunden ein Lebenszeichen (LifeChar). Das LifeChar nimmt zyklisch die Adressen (IDs) der am Netz angeschlossenen CPUs an. Außerdem wird pro Zyklus noch ein globales LifeChar FF gesendet. Ein Lifecharzyklus mit 3 CPUs (CPU 2 sei Busmaster) dauert ca. 40ms, da die Zeichen 00, 01, 03, FF gesendet werden. Die Adresse 02 wird ausgespart, da CPU 2 Busmaster ist. Eine Busmaster-Anforderung wird nach folgenden durch die Variable SVCGetMasterMode bestimmten Kriterien abgesandt: Warten auf LifeChar mit eigener CPU-Id: Bit 1-0 von SVCGetMasterMode sind 00. Die Busmaster-Anforderung wird gesendet, sobald das LifeChar mit der CPU-ID der anfordernden Karte erscheint. Falls das gewünschte LifeChar verfälscht wurde oder fehlte (z.b. weil die CPU am laufenden Netz angeschlossen wurde), wird die Anforderung nach nach dem zweiten Erscheinen des globalen LifeChars FF übertragen. Falls kein LifeChar mit der eigenen CPU-Id gefunden wurde, wird die Prozedur UPDATE CARDS durchlaufen, dabei wird allen am Netz angeschlossenen CPUs die eigene CPU-Id mitgeteilt. Die Zeiten für eine Busmaster-Anforderung sind: Best case: 2ms Worst case: (n+1)210ms+2 (für 2 CPUs und Mastercard: 82ms) Average case: (n+1)/210ms+2 (für 2 CPUs und Mastercard: 22ms) Wobei n die Zahl der angeschloßenen CPUs incl. Mastercard ist. Warten auf beliebiges LifeChar: Bit 1-0 von SVCGetMasterMode sind 01. Die Busmaster-Anforderung wird gesendet, sobald das nächste LifeChar erscheint. Die Zeiten für eine Busmaster-Anforderung sind: Best case: 2ms Worst case: 12ms Average case: 7ms Nicht auf LifeChar warten: Bit 1-0 von SVCGetMasterMode sind 10. Die Busmaster-Anforderung wird sofort, ohne Warten auf ein LifeChar übertragen. Dadurch sind Kollisionen mit anderen Netzkommandos möglich, die nach einigen Übertragungswiederholungen zum Abbruch der Kommunikation führen können. Die Zeiten für eine Busmaster-Anforderung sind: Best case: 2ms Worst case: 2ms Average case: 2ms 14

2. Die Netzwerkfunktionen Zusätzlich: GETMASTER-Kommando vorwegschicken. Bit 2 von SVCGetMasterMode ist 0. Bevor das Kommando mit neuem Busmaster versendet wird, wird erst noch das Kommando GETMASTER vorweg gesendet. Im Falle einer Kollision kollidiert dann GETMASTER mit einem anderen Kommando. Es finden keine Übertragungswiderholungen des GETMASTER- Kommandos statt. Die oben angegebenen Zeiten verlängern sich jeweils um 2ms. Diese Variante ist inzwischen nicht mehr notwendig, Bit 2 von SVCGetMasterMode sollte also immer 1 sein. 2. Carrier Sense Medium Access mit deterministischer Kollisionsauflösung nach CPU-Id. Bit 4-0 von SVCGetMasterMode sind 11110. Nach dem Empfang des letzten Zeichens einer Nachricht wird vor dem Senden der Nachricht die Zeit (QBD+(CPUID MOD 16))*100us gewartet. QBD ist der Quiet-Bus-Delay, der in der Systemvariablen SVCQuietBusDelay eingestellt ist (voreingestellt sind 300us). Es wird also maximal QBW+1.5ms gewartet, bevor die Nachricht versandt wird. Sollte es zu einer Kollision kommen, wird vor erneutem Senden der Nachricht eine von der Zahl der erfolgten Wiederholungen und der (CPUNr MOD 4) abhängigen Zeit gewartet. Diese Zeitspanne liegt beim ersten Versuch zwischen 0 und 1.1ms und wird beim 2. bis 4. Versuch jeweils ungefähr verdoppelt um dann beim 5. wieder bei 0-1.1ms zu liegen. 3. Carrier Sense Medium Access mit deterministischer Kollisionsauflösung und einstellbarer Priorität. Bit 4-0 von SVCGetMasterMode sind 10110. Für jede CPU kann in der CoaxSystemvariablen SVCQuietBusDelay eine Zeit in Vielfachen von 100us eingestellt werden, die diese CPU nach dem Empfang des letzten Zeichen abwartet, bevor die Nachricht gesendet wird. CPUs die eine höhere Priorität erhalten sollen, bekommen kleinere Werte in SVCQuietBusDelay. CPUs die gleiche Werte in SVCQuietBusDelay haben sind potentielle Kandidaten für Kollisionen. Die maximale Wartezeit vor dem Versenden einer Nachricht ist zwischen 100us und ca. 9ms in der Variablen SVCQuietBusDelay einstellbar. Sollte es zu einer Kollision kommen, wird vor erneutem Senden der Nachricht eine von der Zahl der erfolgten Wiederholungen und der (CPUNr MOD 4) abhängige Zeit gewartet. Diese Zeitspanne liegt beim ersten Versuch zwischen 0 und 1.1ms und wird beim 2. bis 4. Versuch jeweils ungefähr verdoppelt um dann beim 5. wieder bei 0-1.1ms zu liegen. 4. Carrier Sense Medium Access mit nicht deterministischer Kollisionsauflösung. Bit 4-0 von SVCGetMasterMode sind 00110. Nach dem Empfang des letzten Zeichens einer Nachricht wird vor dem Senden der Nachricht die Zeit (QBD+Random(0,15))*100us gewartet. QBD ist der Quiet-Bus-Delay, der in der Systemvariablen SVCQuietBusDelay eingestellt ist. Es wird also maximal QBW+1.5ms gewartet, bevor die Nachricht versandt wird. Sollte es zu einer Kollision kommen, wird vor erneutem Senden der Nachricht eine von der Zahl der erfolgten Wiederholungen und dem Zufall abhängige Zeit gewartet. Diese Zeitspanne liegt beim ersten Versuch zwischen 0 und 1.1ms und wird beim 2. bis 4. Versuch jeweils ungefähr verdoppelt um dann beim 5. wieder bei 0-1.1ms zu liegen. 2.1.4. Schicht 3-6 Die Layer 3 (Network), 4 (Transport), 5 (Session) und 6 (Presentation) des ISO-Modells wurden aus Effizienzgründen weggelassen. So sollte z.b. der Presentation Layer die Aufgaben CPU-Zugangskontrolle, Datenkonvertierung, Datenverschlüsselung und Datenkomprimierung umfassen. All dies sind Aufgaben, die in einem Maschinensteuerungs-Netzwerk unnötigen Overhead mit sich bringen. Sollte zum Beispiel die Datenkonvertierung notwendig sein, so ist das die Aufgabe des Anwendungsprogrammes. Die Schnittstelle zwischen Kommunikationsprozessor und Anwendungsprozessor ist gleichzeitig die Schnittstelle zwischen Medium Access Sublayer und Application Layer. Die Anwendung soll die Kontrolle über den Busmaster behalten, damit ein schneller Netzzugang vorhersagbar bleibt. Im Master/Slave-Zugangsverfahren führt die Aufteilung in Busmaster- und Nicht-Busmaster-CPUs zu zwei Prioritätsstufen für CPUs. Die unterschiedlichen Prioritäten wirken sich in der Zeit aus, die eine CPU maximal benötigt, um eine Nachricht zu versenden und damit Busmaster zu werden. 15

2. Die Netzwerkfunktionen 2.1.5. Application Layer (Schicht 7) Der Anwendung auf den SlaveCPUs stehen MCL-Befehle wie SENDCMDM, SENDCMD (Kommando senden mit und ohne Abgabe des Busmasterstatus), WAITCMD, WAITMSG (Kommando empfangen) GETVAR, SETVAR (Daten empfangen und versenden), SETFG, IFFG0 (Flags verändern und abfragen) oder komplexere wie DELAYCLRIO (I/O-Bit nach einer bestimmten Zeit beim Empfänger löschen) zur Verfügung. Diese Befehle werden vom Netzinterpreter auf der Empfänger-CPU interpretiert. 16

2.2 Beschreibung der Netzkommandos 2.2. Beschreibung der Netzkommandos Im folgenden sind die mit Netzinterface-Version 1.0 implementierten Systemkommandos beschrieben. Der Bereich 7F00-7FFF für Kommandos ist reserviert für Kommandos, die vom Netzinterpreter behandelt werden. Kommandos 0000-7EFF werden dem Anwendungsprogramm über eine Kommando-Queue zugestellt. Trotzdem soll an dieser Stelle darauf hingewiesen werden, daß in zukünftigen Versionen die Kommandos 4000-7EFF zu besonderen Zwecken vom System verwendet werden können. Falls eine Aktion auf der Empfänger-CPU nicht ausgeführt werden kann, und die Empfänger-CPU dies der Absender-CPU mitteilen möchte, wird ein NAK (FFFFh) zurückgesandt. Weitere Wiederholversiche sind dann sinnlos. Unter dem Absatz 'Antwort' werden die vom Netzinterpreter zurückgelieferten Datenbytes beschrieben. Unter 'Parameter' sind die mitzusendenden Datenbytes beschrieben. Der Empfänger überprüft nicht die bei jedem Kommando richtige Datenlänge, sondern verläßt sich auf die passende Zahl. Einige Netzkommandos verhalten sich je nach übergebener Datenlänge unterschiedlich. Z.B. gibt es die Möglichkeit in Abhängigkeit von der Datenlänge 8 oder 16-Bit I/O-Adressen anzugeben. Eine 8-Bit Adresse adressiert immer ECB-I/O- Karten. Unter dem Absatz 'Fehler' werden Fehler beschrieben, die das Netzkommando auf der Fremd-CPU auslösen könnte. 17

2.2 Beschreibung der Netzkommandos CMD_NILCMD (7F00h) - Keine Funktion Funktion: Keine. Parameter: Keine. Antwort: ACK. Keine Daten. Fehler: Keine. Bemerkung: Mit diesem Kommando kann der Masterstatus abgegeben werden, wenn keine weiteren Wirkungen erwünscht sind. Verfügbarkeit: Ab Interface-Version 0.0 in allen Implementierungen. 18

2.2 Beschreibung der Netzkommandos CMD_SOFTRESET (7F01h) - Softreset Funktion: Die adressierte Karte führt einen Warmstart mit Selbsttest durch. Das vorhandene Programm, die Variablen und das Logbuch werden gelöscht. Bevor das nächste Kommando gesendet wird muß 2 bis 3 Sekunden gewartet werden, da die CPU in der Zeit einen Selbsttest durchführt. Parameter: Keine. Antwort: Es ist damit zu rechnen, daß von einigen CPUs kein ACK zurückgesandt werden kann, wenn der Reset bereits währemd eines laufenden ACK-Sendevorganges ausgeführt wird! Bemerkung: Dieses Kommando wird normalerweise nur in der Initialisierungsphase per Broadcast durch eine PC-Anweisung von der Mastercard an die CPUs versendet. Im Logbuch der CPUs erscheint der Eintrag SOFTRESET. Verfügbarkeit: Ab Interface-Version 0.0 in allen Implementierungen. 19

2.2 Beschreibung der Netzkommandos CMD_SETMULTICARDS (7F02h) - Multicast-Teilnehmer mitteilen Funktion: Der Empfängerkarte mit mitgeteilt, welche CPU-Adressen einer der Multicast-Adressen F8, F9, FA, FB, FC, FD, FE zugeordnet werden. Parameter: STRUCT (BYTE MCAddress, t1, t2, t3,..., t32) ; MCAddress ist die Multicast-Adresse, der maximal 32 Teilnehmer zugeordnet werden können. t 1,..., t Header.Len-1 sind die Teilnehmeradressen an diesem Multicast. Antwort: ACK. Keine Daten. Fehler: Keine. Bemerkung: Dieses Kommando wird normalerweise per Broadcast (evtl. mit Quittung also Adresse FB versendet). GGf. kann mit GETMULTICARDS eine Überprüfung des Empfangs dieses Kommandos stattfinden. Achtung: Beim Empfang des Kommandos SETCARDS werden die Teilnehmer der Multicast- Adresse FB auf alle am Netz angeschlossenen CPUs gesetzt. Siehe auch: GETMULTICARDS. Beispiel: Nachdem das Kommando SETMULTICARDS mit Parameter (F8, 04, 05, 06, 07) per Broadcast an alle CPUs gesendet wurde, empfangen nur die CPUs 4, 5, 6, 7 eine Mitteilung, die an Adresse F8 gesendet wurde. Verfügbarkeit: Ab Interface-Version 0.10 in allen Implementierungen. 20

2.2 Beschreibung der Netzkommandos CMD_GETMASTER (7F03h) - Masteranforderung Funktion: Die adressierte Karte wird aufgefordert den Masterstatus an die sendende Karte abzugeben. Um dieses Kommando abzusetzen, wartet die Nicht-Busmaster-Karte solange, bis sie ein Lifecharacter mit ihrer Kartennummer empfangen hat. Direkt danach sendet sie dieses Kommando. Dadurch werden Buskollisionen vermieden, wenn mehrere Karten gleichzeitig Busmaster werden möchten. Das gilt nur im Master/Slave-Buszugangsmodus. Parameter: Keine. Antwort: ACK. Keine Daten. Der neue Busmaster ist die Absender-CPU der Nachricht. Fehler: Keine. Bemerkung: Dieses Kommando muß nicht unbedingt vor einer Busmaster-Anforderung gesendet werden. Es genügt, wenn der zukünftige Busmaster seine Adresse im Master-Feld der Nachricht einträgt. Ist Bit 2 in der Systemvariablen SVCGetMasterMode gesetzt, dann wird kein CMD_GETMASTER versendet, falls die sendende CPU noch nicht Busmaster war. Verfügbarkeit: Ab Interface-Version 0.0 in allen Implementierungen. 21