BITBUS-Grundlagen

BITBUS ist erheblich zuverlässiger als andere Feldbus-Lösungen, die z.B. mit asynchroner Übertragung arbeiten. 

Zur Programmierung auf der PC-Seite hat die BEUG die BAPI-Schnittstelle definiert, auf die über den Windows-WDM-Treiber zugegriffen wird - in gleicher Weise über USB oder Ethernet wie auf eine interne Baugruppe. Auch bei Linux werden gleichartige BAPI-Aufrufe gemacht.

BITBUS basiert auf soliden Standards:  

  • RS485 als elektrische Norm für zuverlässige Übertragung in gestörter Umgebung
  • Synchrone, CRC-gesicherte Telegrammübertragung nach SDLC 
  • NRZI-Codierung halbiert die Datenrate und erlaubt Verpolung des Kabels
  • Einfache Client/Server-Architektur für klare Verhältnisse

BITBUS wurde von Intel 1984 definiert und später als IEEE1188 genormt

  • Wieso BITBUS?
  • Grundlagen
  • RAC/GBS
  • Installation
  • BAPI (/TCP)
  • Spezifikation
  • Downloads

Technisch besser!

BITBUS kann große Entfernungen überbrücken, 300m bei hoher Geschwindigkeit, 1200m bei 62,5kBit/s. Im Gegensatz zu anderen kann BITBUS Verstärker einsetzen, um die Leitungslängen zu multiplizieren. BITBUS kann leicht isoliert werden. Standard-Optokoppler (VDE0884 überall verfügbar) reduzieren nicht die Leitungslänge wie bei z.B. CAN.

BITBUS benutzt SDLC, ein synchrones, nachrichtenbasierendes Protokoll mit automatischer Fehlererkennung. Standard-Controller wie 85C30 oder Z16C32 behandeln eine ganze SDLC-Nachricht in Hardware, dagegen stellen asynchrone Übertragungen der vergleichbaren Busse eine sehr hohe Prozessorlast dar, so dass meist proprietäre Spezial-Schaltkreise verwendet werden müssen. Das synchrone Verfahren mit Rahmensicherung bietet ferner größere Effizienz bei deutlicher höherer Datensicherheit.

RS485 ist weltweit anerkannt wegen seiner Unempfindlichkeit gegen Störeinflüsse. BITBUS benutzt NRZI-Codierung: Die Daten werden auf den Takt codiert, wobei die Signalfrequenz gegenüber der Standardcodierung fast halbiert wird, das führt zu deutlich längeren möglichen Leitungslängen oder entsprechend zu höherer Störsicherheit. Daneben bietet NRZI den Vorteil, dass die Polarität der Leitung beliebig ist, da nur Signalwechsel zählen - das macht die Verdrahtung einfacher. BITBUS benutzt ein einziges verseiltes Leitungspaar plus Masse für die Übertragung, (Vergleichen Sie den Aufwand z.B. gegenüber LWL). Eine fehlerhafte oder spannungslose Station behindert den BITBUS nicht (auch hier ist ein Vergleich mit LWL oder E/A-Bussen mit Schieberegisterstruktur angebracht).

BITBUS ist einfach!

Einfache Verdrahtung und eine einfache Client/Server-Architektur öffnen den BITBUS für Anwender, die sich nicht in den Tiefen eines Netzwerks verstricken wollen, sondern ihre Aufgaben einfach lösen wollen. BITBUS konzentriert sich nicht auf Schnickschnack, sondern auf Basisfunktionen und Zuverlässigkeit. Die Konzepte und die Anwendung von BITBUS lassen sich Ihrem Service- und Verkaufspersonal leicht erläutern und führen dadurch zu Akzeptanz.

Aber BITBUS ist doch kaum verbreitet!

Ja, Intel hat den BITBUS-Urprozessor 8044 (NMOS) schon lange eingestellt und die großen Konzerne am Markt achten darauf, dass sie ihren eigenen Bus einsetzen. Aber BITBUS ist bei vielen, auch großen Anwendern, die sich mit den technischen Vorteilen befasst haben, seit 25 Jahren im Einsatz und kommt sicher nicht aus Nostalgiegründen auch in neue Geräte. Dafür gibt es CMOS-Nachbauten des 8044, aber auch die Möglichkeit, den BITBUS, der ja ein offenes Protokoll ist, auf anderer Hardware zu implementieren. ELZET80 hat das schon 1990 mit der Implementierung auf dem Z80 mit dem Z85C30 SDLC-Controller vorgemacht, inzwischen sind viele andere Prozessoren und Controller dazugekommen (Z16C32 oder der S3C4530 ARM mit SDLC). Die BITBUS-Firmware ist als C-Source erhältlich und die Hardware als VHDL-Code.

Eine Frage der Philosophie!

Unser Bestreben ist es, Entscheidungszentren so weit wie möglich in die Peripherie zu legen. Im Gegensatz zum zentralistischen Ansatz verteilen wir viele kleine Steuerungen, die alle genau ihre Aufgabe kennen und nicht unbedingt einen Server brauchen, um sie durchzuführen. Wir vernetzen dann diese Steuerungen auf einer Ebene, wo nur verdichtete Anfragen und Antworten auszutauschen sind ("Distributed Control"). Die Geschwindigkeitsanforderungen sind gering auf dieser Ebene, damit auch die Anschalte- und Verdrahtungskosten.

Hochgeschwindigkeitsnetzwerke, so genannte Sensor/Aktor-Busse, sind notwendig, wenn eine zentrale Speicherprogrammierbare Steuerung (SPS) alle E/A einer Anlage selbst "verdauen" muss. Benutzt man aber richtige Programmiersprachen, ist es viel einfacher - und viel sicherer - die Probleme in Prozeduren zu isolieren. Der nächste Schritt ist dann, diese Prozeduren dahin zu verlagern, wo das Problem ist, also z.B. den Regler an die Regelstrecke. Damit kann man Anlagen- bzw. Maschinenteile so modularisieren, dass für Varianten oder Neuheiten nicht nur die mechanische Konstruktion des Teils übernommen werden kann, sondern auch die Steuerung. Die Inbetriebnahme einer aus solchen Baukastenteilen zusammengefügten Maschine beschränkt sich dann auf die Vernetzung der Einzelsteuerungen. Von der Programmieraufgabe her ist das auf einem sehr viel abstrakteren, beschreibenderem Niveau als alle E/A´s von Grund auf neu zu verknüpfen.

Ein Sensor-Aktor-Bus hat durchaus seine Berechtigung, aber eine Etage tiefer in der Steuerungshierarchie, dann nämlich, wenn er billig genug ist, wirklich einzelne Initiatoren und Ventile an einen dedizierten Controller anschließen zu können. Der AS-i-Bus ist ein gutes Beispiel dafür. 

Echtzeitfähig!

BITBUS ist spezialisiert auf Distributed control statt auf verteilte E/A und erwartete schon 1984 einen Echtzeitkern als Applikationsschnittstelle auf jedem Knoten. Glücklicherweise hat Volker Goller 1993 einen modernen Echtzeitkern mit BITBUS-Unterstützung (zunächst für den TLCS900) geschrieben. Sein nachrichtenbasierendes "mCAT", jetzt schon in zweiter Generation, passt perfekt auf die Anforderungen des BITBUS und bietet zusätzlich Unterstützung für neue Konzepte bei der Echtzeit-C-Programmierung.

Integration in's Ethernet!

BITBUS passt sich mit seiner Philosophie der verteilten Steuerung nahtlos in Ethernet Standard-TCP/IP-Netze ein. Es gibt keine Notwendigkeit für einen Echtzeit-Takt, da die Geschwindigkeits-Anforderungen durch Echtzeit-Prozesse vor Ort zur Zentrale hin völlig entspannt sind. Mit ELZET80's BAPI/TCP-Server (z.B. auf der ETH-BIT-Hardware) kann man Telegramme an entfernte BITBUS-Clients bequem über eine Windows-DLL absenden. Windows empfängt die Antwort über das Ethernet im Hintergrund und weckt Ihren Bearbeitungsprozess bei Eingang.

Typische BITBUS-Applikationen:

  • Modulare Maschinensteuerung
  • Achspositionierung
  • Produktionsplanung
  • Maschinen- und Betriebsdatenerfassung
  • Gebäudeautomatisierung
  • Transportsteuerung Medatenerfassung
  • Anzeige- und Informationssysteme

BITBUS eignet sich nicht gut als E/A-Bus, also um einzelne Sensoren/Aktoren zu vernetzen. Ausnahme: Sehr große Feldausdehnung.

Auf eine lange Zukunft!

ELZET80 bietet für die Firmen, die BITBUS auf Grund der Technologie weiter einsetzen wollen, eine Entwicklungsperspektive auf viele Jahre. Nach einem kostengünstigen Ethernet-Gateway 2004 kam 2011 z.B. eine halbhohe PCI-Express-Anschaltung für den BITBUS in unser Programm.  Für 2012 planen wir eine FPGA-Integration mit einem modernen Cortex-M4-Mikrocontroller.

Sprechen Sie uns gerne auf Ihre neuen Anforderungen an - ELZET80 steht für modernen BITBUS !

250 Teilnehmer sind in einem BITBUS-Netzwerk zugelassen. Bei ELZET 80-Hardware wird die Adresse entweder in EEPROMs abgelegt oder an Drehcodierschaltern 0..F in hexadezimaler Notation als 00..FF eingestellt. Die Adressen 0 und 250..254 sind reserviert, 255 adressiert die lokale Netzwerkkarte aus Sicht des Host-Prozessors und wird (neu bei IEEE1118) als Broadcast-Adresse (Nachricht an Alle) auf dem Bus genutzt.

Um alles einfach zu halten, gibt es nur einen Master, der alle Anfragen stellt und alle Antworten von den Teilnehmern (Slaves) erhält. Ein Slave darf nie senden ohne vom Master dazu aufgefordert worden zu sein, also kann es auch nicht zu Buskonflikten durch gleichzeitige Zugriffe kommen. Sobald der Master eine Anfrage gestellt hat, pollt er den Slave auf Antwort, d.h. er sendet ständig spezielle SDLC-Kurznachrichten mit dem Fragecode für "Antwort fertig?". Es können weitere Anfragen an einen Slave geschickt werden, auch wenn die erste noch nicht beantwortet wurde. Ein typischer Slave verwaltet 8 "Outstanding Messages". 

SDLC-Nachricht mit BITBUS-Nachricht (Doppelrahmen) als Informationsfeld. Eine Zeile entspricht einem Byte

Nachrichten können an 16 verschiedene Tasks (nur 8 beim i8044) pro Slave verschickt werden, wobei Task 0 immer die RAC-Task (unter IEEE1118 "GBS"-Task) ist, d.h. die Task, die die BITBUS-Standardfunktionen bedient. RAC/GBS ist die Schicht 7 des BITBUS laut OSI Schichtenmodell.

Eine BITBUS-Nachricht ist eine Standard-SDLC-Nachricht, die die BITBUS-Nachricht als SDLC-Datenfeld einschließt. SDLC ist ein bitsynchrones Protokoll, definiert von IBM, das überall da eingesetzt wird, wo Datenintegrität wichtig ist (Ethernet, ISDN).

Der SDLC-Rahmenaufbau wird durch Schnittstellencontroller wie den Z85C30 oder Z16C32 komplett in der Hardware abgehandelt. Normalerweise wird eine hereinkommende Nachricht ohne Zutun der CPU im Speicher abgelegt, erst danach erfolgt die Fertigmeldung, der EOM (End-of-Message)-Interrupt.

Nachrichtenstruktur

Während der äußere SDLC-Rahmen vom Treiber gefüllt wird, ist es Aufgabe des Anwenders, die BITBUS-Nachricht (den Doppelrahmen in unserem Schema) zu füllen:

Länge ist das Datenfeld plus 7

Vermittlungsflags (Routing flags):

  • MT unterscheidet Anfragen von Antworten
  • SE (Source extension) zeigt an, dass nicht der Netzwerkprozessor die Nachrichtenquelle ist, sondern der Prozessor dahinter, der ihn kontrolliert (z.B. bei der IPC-BIT900 der 80x86 PC und nicht der TLCS900).
  • DE (Destination extension) vermittelt die Nachricht an den Prozessor hinter der empfangenden Netzwerkkarte.
  • TR (Transmit/Receive) ist das Sende-/Empfangsflag. 0=Senden 

Zieladresse benennt den empfangenden Teilnehmer.

Quelltask/Zieltask nennen die Tasknummern (0..15) der sendenden bzw. der empfangenden Task innerhalb der Teilnehmer.

Befehl/Antwort ist das Codefeld für die Aktion, die mit den Daten vorgenommen werden soll bzw. der Antwort-/Fehlercode. Bei RAC/GBS sind diese Codes vordefiniert (siehe Tabelle), für eigene Tasks sind sie frei definierbar.

Das Datenfeld hat eine variable Länge zwischen 0 und 248 Byte (0..13 beim 8044). Normalerweise wird die Länge der erwarteten Antwort schon mit der Anfrage heruntergeschickt, um die Pufferverwaltung im Slave zu vereinfachen. Für einige RAC-Befehle (z.B. Lese E/A) gibt es eine Sequenz von Daten/Leer-Bytes, wobei die Leerbytes mit dem Inhalt des Eingabeports laut Adresse gefüllt werden.

Die CRC16-Bytes und die Endeflags sind nicht Teil der BITBUS-Nachricht, sondern werden von der SDLC-Controller-Hardware hinzugefügt.

Für alle üblichen Anwendungen braucht der Benutzer nicht mehr über BITBUS-Interna zu wissen. Der Anwender braucht nur den Datenblock mit der Nachricht wie im Doppelrahmen aufzubauen und dem BITBUS-Treiber einen Zeiger darauf zu übergeben.

Unter DOS muss beispielsweise bei dem BITIO-TSR-Programm, das zur ELZET 80 IPC-BIT900 geliefert wird, ein Zeiger in ein Prozessorregister geladen werden, danach ist ein INT78 System Call aufzurufen. Das TSR-Programm legt die Antwort in den gleichen Buffer zurück.

Unter Windows wird die BITDLL mit einem Zeiger auf die Nachricht aufgerufen. Beim mCAT-Echtzeitkern wird eine BITBUS-Nachricht genau wie eine mCAT-Nachricht behandelt. So wartet man z.B. in einem mCAT-Slave auf eine BITBUS-Nachricht genauso mit MsgWait wie auf jede andere Nachricht.

Einer der großen Vorteile des BITBUS ist die Definition eines Standardbefehlssatzes mit Namen RAC "Remote Access and Control interface". Mit der Erweiterung der Befehle unter IEEE1118 wurden sie zu GBS "Generic Bus Services" umbenannt.

Diese Befehle können auf BITBUS-Hardware aller Hersteller benutzt werden und obwohl die Unterstützung nicht Pflicht ist, gibt es sehr wenige Hardware, die sie nicht unterstützt (wahrscheinlich, weil der i8044 die RAC-Task in ROM mitbrachte). RAC/GBS wird als Task 0 auf einem Teilnehmer angesprochen, der gewünschte Befehl wird im Befehlsbyte codiert.

E/A-Zugriffs-Struktur

Für E/A-Befehle muß der BITBUS-Nachrichtenpuffer mit Länge, Vermittlungsflags, Zieladresse, Quell- und Zieltasknummer und dem RACBefehlscode geladen werden (z.B. 5 für E/A-Lesen). Als Datenfeld folgen abwechselnd die gewünschten Portadressen und Datenfelder: Adresse1, Daten1, Adresse2, Daten2,... Für diesen Befehl sind die Datenfelder beliebig gesetzt. Wenn die Nachricht zurückkommt, ist das Feld für den Befehlscode mit einem Fehlercode gefüllt und die Datenbytes enthalten die Daten, die von den Portadressen gelesen wurden.

Speicherzugriffsstruktur

Für den Fall der Speicherbefehle ist der Steuerteil des Nachrichtenblocks wie bei der E/AStruktur, allerdings startet das Datenfeld mit einem Adresszeiger (hohes Byte / niedriges Byte), gefolgt von den Speicherdaten oder Leerdaten bei Lesebefehlen. Das Längenfeld ist auf die Länge der Speicherdaten plus 9 zu setzen. IEEE1118 Adresserweiterung: Um Speicher größer als 64K ansprechen zu können (z.B. beim TLCS900 wegen seiner 16MByte linearem Adressraum nötig), können die Adresszeiger wie folgt erweitert werden: Benutzen Sie BFH als Befehlscode und schreiben Sie in die ersten zwei Byte des Datenfelds die oberen 16 Bit der 32 Bit Speicheradresse. Das dritte Byte des Datenfelds wird das neue Befehlsfeld, gefolgt von den unteren 16 Bit der Speicheradresse. Adresserweiterung arbeitet auch auf E/A-Befehle, da diese auf einem 256-Byte Adressbereich basieren; als Erweiterung sind die oberen 16 Bit einer 24-Bit-Adresse anzugeben.

Funktionscodes

Funktionscodes ermöglichen es, auf Tasks zugreifen zu können, auch wenn man die lokal vergebene Tasknummer nicht kennt (was normalweise dadurch entsteht, daß Tasknummern nach Reihenfolge der Anmeldung vergeben werden). Im Task-Vorspann (bei iDCX51 und mCAT) kann man Funktionscodes eintragen, die die Funktionalität der Task bezeichnen. Die RAC/ GBS-Funktion GBS_GET_FUNC liefert eine Liste von acht oder 16 Byte mit Funktionscodes. Das erste Byte ist der Funktionscode der Task 0 (normalerweise 01, denn das ist der Funktionscode der RAC-Task), das zweite Byte ist der Code von Task1 usw. Ein FF wird zurückgeliefert, wenn die Task keinen Funktionscode definiert hat. BITBUS/IEEE1118 läßt die Codes 80..FEH als Anwender-Funktionscodes zu. Hier folgt eine Liste der RAC/GBS Befehlscodes, die von mCAT-Teilnehmern unterstützt werden. Der Befehlstyp gibt Auskunft über die Struktur des Datenfelds mit I für E/A-Struktur, M für Speicherstruktur und C für Steuerbefehle mit spezieller Struktur, so wie in der Tabelle beschrieben.

Anwendertasks im Teilnehmer

Die meisten BITBUS-Teilnehmer sind mit einem Echtzeit-Multitaskkern ausgestattet, so daß Nachrichten vom Master an eine angegebene Task beim Teilnehmer versandt werden können. Diese Slave-Tasks werden genauso angesprochen wie die RAC/GBS-Task, nur dass die Zieltasknummer nicht "0" ist, sondern eben die Nummer der gewünschten Task. Überlicherweise wird eine Task unter mCAT über die RS232-Diagnoseschnittstelle in RAM oder Flash geladen. Über die BITBUS-Funktion GET_FUNC_ID kann die Tasknummer erfragt werden, wenn Sie im Taskvorspann einen Funktionscode definiert haben. Das Herunterladen und Initialisieren von Tasks kann aber auch über den BITBUS erfolgen, wozu man sich der RAC-Funktionen GBS_DOWN_CODE und GBS_CREATE bedient. Das Handbuch zu mCAT gibt Auskünfte über die Erstellung einer Anwendertask.

RAC/GBS Befehle:

Befehls- Code Befehls- Typ Beschreibung
00 C GBS_RESET
Setzt den Slave zurück (einzige Funktion ohne Antwortnachricht)
01 M GBS_CREATE
Erzeugt und startet eine Task. Das Datenfeld enthält einen Zeiger auf den Taskvorspann, MSB zuerst (16 Bit mit BF-Erweiterung)
02 C GBS_DELETE
Entfernt eine Task. Daten: Tasknummer als einziges Datenbyte
03 C GBS_GET_FUNC
Lese Funktionscode (s.o.)
04 C GBS_PROTECT
Sperrt RAC-Bearbeitung. Daten: 0=kein Schutz, 1=Speicherschützen, 2=Schreibschutz
05 I GBS_READ_IO
Liest von E/A-Portadressen.
06 I GBS_WRITE_IO
Schreibt auf E/A-Portadressen.
07 I GBS_UPDATE_IO
Schreibt auf Ports und liest gleich wieder zurück.
08 M GBS_UP_DATA
Lädt einen beliebigen Speicherblock vom Teilnehmer.
09 M GBS_DOWN_DATA
Schreibt auf einen beliebigen Speicherblock im Teilnehmerspeicher.
0A I GBS_OR_IO
Logisches OR der Daten im E/A-Port mit den Masken, die als Datenbytes geliefert werden. Liest den Port zurück. Zum Setzen von Bits.
0B I GBS_AND_IO
Logisches AND zum Löschen von Bits.
0C I GBS_XOR_IO
Logisches XOR zum Invertieren von E/A-Bits.
0D I GBS_WRITE_IRAM
Schreibt auf einen vordefinierten Speicherbereich.
0E I GBS_READ_IRAM
Liest vom vordefinierten Speicherbereich.
0F I GBS_GET_INFO
Liefert Hardware und Taskinformationen (s.u.).
11 M GBS_UP_CODE
Lädt Code aus dem Slave hoch (wie UP_DATE).
12 M GBS_DOWN_CODE
Lädt Code ins Flash-EPROM des Slaves.
15 C GBS_GET_TIME
Liefert Zeit und Datum in Struktur gbd_time (s.u.)
16 C GBS_SET_TIME
Setzt die Zeit (s.u.).
17 C GBS_SUSPEND_TASK
Suspendiert die Task mit Nummer, die als einziges Datenbyte geschickt wird.
18 C GBS_RESUME_TASK
Nimmt Task (Nummer) wieder auf.
1A C GBS_GET_TASK_ID
Returns task id for function id entered (Ähnlich zu GET_FUNC, aber für nur eine ID)
20 M GBS_FLASH_ERASE
Löscht einen Flash-EPROM Speicherblock. Benutzt erw. Adressierung und 32Bit Länge als Daten.
21 M GBS_FLASH_GET_ID
Liefert einen 32Bit EPROM Typencode in Nachricht mit erweiterter Adressierung.
22 C GBS_EEPROM_WRITE
Schreibt in das serielle EEPROM mit 16BIT-Adressen: 16Bit Daten; 16Bit Adr.; 16Bit Daten; 16 Bit Adr.;
23 C GBS_EEPROM_READ
Liest EEPROM (Struktur wie WRITE).
BF   GBS_EXTEND_ADDR
Adresserweiterung, siehe Text.


RAC/GBS Fehlercodes:

00     
GBS_ERR_OK
Ok, kein Fehler.
80 GBS_ERR_NO_DEST_TASK
Task existiert nicht.
81 GBS_ERR_TASK_OV
Kein Platz für weitere Tasks.
82 GBS_ERR_REGISTER_OV
Keine weitere Registerbank verfügbar.
83 GBS_ERR_DUPLICATE_TID
Andere Task mit gleichem Funktions-ID schon vorhanden.
84 GBS_ERR_NO_BUFFERS
Kein Platz mehr für Puffer.
86 GBS_ERR_BAD_TASK_DESC
Taskdescriptor (ITD) ist ungültig.
87 GBS_ERR_NO_MEMORY
Speicher verbraucht.
90 GBS_ERR_TIME_OUT
IEEE1118 Slave nicht verfügbar.
91 GBS_ERR_PROTOCOL
Unspezifizierter Fehler.
93 GBS_ERR_NO_DEST_DEVICE
Kein Host-Prozessor (DE) verfügbar.
95 GBS_ERR_PROTECTED
RAC/GBS-Befehl in Kraft.
96 GBS_ERR_NO_GBS
Unbekannter RAC/GBS Befehl.
97 GBS_ERR_BAD_COMMAND_LEN
Befehlslänge passt nicht zur Befehlsspezifikation

System Info

Der RAC/GBS-Befehl 0F, GBS_GET_INFO, liefert Informationen über die Software des Teilnehmers wie folgt:

Daten Bytes      Inhalt
0..5 6 ASCII-Zeichen Name ("i8044", "mCATV2")
6,7 ASCII Versionsnr. ("2.1")
8 i8044 Speicherinfo, unter mCAT nicht unterstützt
9 Max. BITBUS-Nachrichtenlänge, die dieser Teilnehmer unterstützt.

GBS Time Services System Info Struktur

typedef struct { 
BYTE zone, /* TIME ZONE : 0 = GMT, 8 = PST */
offset, /* TIME OFFSET : 0..59 MINUTES */
day_of_week, /* 1..7, MONDAY = 1. */
year, /* 1980 = 0, 2235 = 255. */
month, /* 1..12, JANUARY = 1. */
day, /* 1..31. */
hour, /* 0..23. */
min, /* 0..59. */
sec; /* 0..59. */
} GbsTime;

BITBUS Installation

Verdrahtung BITBUS

Obwohl BITBUS sich als sehr tolerant gegenüber Verkabelungsfehlern herausgestellt hat, schreibt die RS485-Spezifikation einige Vorsichtsmaßnahmen vor, die für optimale Funktion auch unter schwierigen Bedingungen beachtet werden sollten:

Kabel

RS485 benutzt ein Differenzsignalpaar, wobei eine Ader (normalerweise Data + genannt) auf +5V liegt, um TRUE (1, Hi) anzuzeigen, während die invertierte Ader (Data -) auf 0V liegt für FALSE. Der große Vorteil differentieller Übertragung ist die Unempfindlichkeit gegen induzierte Spannungsspitzen, da diese auf beide Adern gleich einwirken und damit nur den Absolutwert der Spannungen verändern, nicht aber deren Pegel zueinander. RS485-Empfänger sind für einen großen Eingangsspannungsbereich ausgelegt.

Für korrekten Betrieb müssen die Adern verseilt sein, das Kabel wird dann als "paarig verdrillte Leitung" oder englisch "twisted pair cable" verkauft. Die Eingangsspannungen dürfen, wie oben gesagt, gegen Signalmasse absolut driften (über -7 bis +12V). Nichtsdestotrotz sollte eine Signalmasse mitgeführt werden, obwohl sehr viele RS485-Installationen darauf verzichten. Normalerweise nimmt man jedoch ein Kabel mit zwei verdrillten Paaren und benutzt ein Paar für Signalmasse. Ein drittes Paar ist in BITBUS-Netzen nötig, die mit Verstärkern (Repeatern) arbeiten, und zwar nur in den Segmenten jenseits des Repeaters. Diese Paar (RTS+/RTS-) schaltet die Verstärkungsrichtung im Repeater vom Standard (alles in Richtung Slaves) auf Eingang (Richtung Master), wenn ein Slave senden will.

Signalabschluss (Terminierung)

RS485 erwartet einen Signalabschluss des Aderpaars an beiden Enden der Leitung. Ein 120Ohm -Widerstand gibt einen annähernd richtigen Abschluss für die RS485-Treiber. Die verwendeten Kabel sollten möglichst gut zu diesem Wert passen, d.h. möglichst eine charakteristische Impedanz von 120Ohm oder mehr haben. DB9-Steckverbinder mit Abschlußwiderständen sind von ELZET 80 erhältlich. Auf manchen Baugruppen ist der Abschluss auch schon integriert und braucht nur über Jumper zugeschaltet zu werden (IPC-BIT900, DC900).

Abschirmung und Erdung

Obwohl Abschirmung nicht in der BITBUS-Spezifikation gefordert ist, sollte man für alle industriellen Anwendungen abgeschirmtes Kabel einsetzen. Diese Abschirmung sollte mit Erde (nicht mit Signalmasse) verbunden werden und zwar nur auf einer Seite des Kabels, um Potentialausgleichsströme über das BITBUS-Kabel zu vermeiden.

Die Signalmasse sollte an einem und nur an einem Punkt im Segment mit Erde verbunden werden, um bei den isolierten Treibern, die ELZET 80 verwendet, überhaupt einen Potentialbezug herzustellen. Wobei hier Experimentieren (also z.B. Massebezug wegnehmen) nicht schadet, manchmal verhält sich die Praxis anders, als die Theorie es vorschreibt. Differenzen zwischen Masse und Erde, die die Spannungsfestigkeit der DC/DC-Wandler überschreiten, werden in den meisten BITBUS-Anschaltungen auf ELZET 80-Baugruppen durch 300V- Transientenschutzdioden mit parallelem Funkentstörkondensator abgeleitet. Daraus ergibt sich ein dreipaariges verdrilltes Litzenkabel mit Gesamtschirmung. Das resultierende Kabel ist unter der Bezeichnung LiYCY(B) 3x0,25mm2 lieferbar.

Repeaterbetrieb

Ein Standard-RS485-Treiber wie der 75176 treibt 31 Empfänger auf einem Adernpaar (moderne Transceiver wie der bei ELZET 80 eingesetzte 75LBC176 treiben über 50). BITBUS spezifiziert recht vorsichtig 28 Teilnehmer an einem Bus, wobei die Ausdehnung des Busses je nach Datenrate entweder 300m (375kBit/s) betragen darf oder 1200m (62,5kBit/s). Stichleitungen sind nicht zulässig, d.h. ein Teilnehmer muss direkt an die Busleitung angeschlossen werden. Zum Anschluss von mehr Teilnehmern (max. 250) können Verstärker, genannt Repeater, eingesetzt werden. Ein Repeater wird wie ein Teilnehmer in die Leitung eingeschleift und hat einen Abzweig, der wiederum ein komplettes 300/1200m-Kabel treiben kann. Dieser Bereich wird Slave-Segment genannt und ist bei ELZET 80-Repatern isoliert vom Mastersegment. Da ein Verstärker Daten nicht gleichzeitig in zwei Richtungen auf dem gleichen Aderpaar treiben kann, wird eine Senderumschaltesteuerung benötigt. Neben dem Datenpaar wird also im Slave-Segment noch ein Steuerleitungspaar benötigt. Jeder Teilnehmer hat sein Signal RTS, was benötigt wird, um den Sendetreiber einzuschalten. Dieses Signal wird parallel auf das Steuerleitungspaar RTS geführt, um den Repeater damit in Richtung Master umzuschalten. Dieses Signal braucht nur in den Slave-Segmenten verdrahtet zu werden. Die BITBUS-Spezifikation erlaubt zwei Repeater hintereinander (d.h. zweimal über die Slave-Seite angeschlossen) bei 375kBit/s und bis zu 10 Repeater bei 62.5kBit/s. Innerhalb eines Segments (also auf der Masterseite) haben Repeater die gleiche Buslast wie ein Teilnehmer. Damit sind pro Segment bis zu 28 Repeater möglich, was eben entsprechend viele Slave-Segmente bzw. Stichleitungen zuläßt.

Anwendung von Repeatern für Stichleitungen und großräumige Vernetzung: Bis zu 28 Repeater sind in einem Segment erlaubt, es dürfen aber (bei 375kBit/s) nur zwei Repeater slaveseitig durchlaufen werden.
Anwendung von Repeatern für Stichleitungen und großräumige Vernetzung: Bis zu 28 Repeater sind in einem Segment erlaubt, es dürfen aber (bei 375kBit/s) nur zwei Repeater slaveseitig durchlaufen werden.
BAPI verbindet max. 16 Programme mit max. 6 Karten
BAPI (BITBUS Application Programmers Interface)

Der BAPI-Standard (pdf) der Bitbus European Users Group bietet eine einheitliche API um auf verschiedene Hardware eines oder mehrerer Hersteller zuzugreifen. Damit werden keine proprietären Treiber mehr benötigt, weshalb eine heterogene BITBUS-Umgebung ganz einfach betrieben werden kann. ELZET80 hat BAPI-Treiber von Anfang an unterstützt und kann diese inzwischen für USB, PCIe, PCI, ISA, PC/104 und PCI104 liefern, wobei alle aktuellen Windows-Varianten (bis 7/64) und Linux unterstützt werden. Der ELZET80-Treiber für Windows kommt als DLL, die in nahezu alle Sprachen und Visualisierungsprogramme eingebunden werden kann. 

BAPI ist multitaskingfähig, es können also mehrere Tasks von verschiedenen Anwendungen darauf zugreifen, ohne die Schnittstelle für andere Tasks zu blockieren. Ausserdem können mehrere Masterbaugruppen gleichzeitig bedient werden, der Windows-WDM-Treiber z.B. kann bis zu sechs Baugruppen parallel bedienen, auf die jeweils bis zu 16 Tasks gleichzeitig zugreifen können.

Die Programmierung ist ziemlich unkompliziert: Nach Auswahl des anzusprechenden Boards mit BitbusOpenMaster() müssen Sie die Datenstruktur der BITBUS-Nachricht füllen und an BitbusSendMsg() übergeben. Der Prozessor auf der BITBUS-Baugruppe sendet die Nachricht dann an den adressierten Slave und wartet auf Antwort - die Ihnen in der Funktion BitbusWaitMsg() ausgehändigt wird. Dazu kommt natürlich etwas Fehlerbehandlung und Timeouts, aber im Prinzip war es das schon. Die wenigsten Anwender senden weitere Nachrichten bevor die erste beantwortet wurde, aber der Treiber unterstützt bis zu sechs solcher "outstanding messages"; die Reihenfolge der Antworten erkennt man am sequentiellen Zähler in der Antwort-Nachricht.

Umbenennen von BAPItcp.dll in BAPInt.dll simuliert PC-Karten ohne Appl.-Änderung
BAPI über Ethernet: BAPI/TCP
 
Um einen nahtlosen Übergang von PC-Karten zu über Ethernet angeschlossenen Geräten zu ermöglichen, wurde BAPI/TCP im Jahr 2000 zur BEUG-Norm. Ohne weiteren Aufwand wird eine BITBUS-Nachricht in eine TCP/IP-Nachricht eingepackt und an den BAPI-TCP-Server geschickt, der auf einer ETH-BIT, einer TSM-ARMCPU oder anderer Ethernet-fähiger ELZET80-Hardware läuft. Der BAPI/TCP-Server simuliert eine IPC-BIT PC-Steckkarte und liefert die Nachricht an den gewünschten BITBUS-Knoten aus. Die Antwort wird ebenfalls über TCP/IP zurückgeliefert. Übrigens funktioniert das in ähnlicher Weise, wenn Sie einen BITBUS-Slave ersetzen wollen.
 
Um den Übergang auf Ethernet für Ihr bestehendes Programm unmerklich zu machen, gibt es eine BAPItcp.dll für Windows, die Sie mit unserem Hilfsprogramm auf die IP-Adressen der ETH-BIT-Umsetzer parametrieren können. Diese DLL packt die BITBUS-Nachrichten in TCP/IP um und spricht mit dem BAPI/TCP-Server auf z.B. ETH-BIT (und das auf bis zu sechs Umsetzern). Die BAPItcp.dll können Sie dann in BAPInt.dll umbenennen (die BAPInt.dll für die PC-Karten muss zuvor natürlich gelöscht werden). Dann kann ihre bestehende Software die BITBUS-Slaves über TCP/IP ansprechen, ohne am Programm etwas ändern zu müssen, nicht einmal den Namen der anzusprechenden DLL.
 
Der BAPI/TCP-Server öffnet den BITBUS übrigens für jedes Betriebssystem, das TCP/IP-Kommunikation über Sockets unterstützt. Sie müssen lediglich die BITBUS-Nachricht in TCP/IP einpacken und zum vorher geöffneten Port 8044 auf dem BAPI/TCP-Server senden. Unter "Downloads" finden Sie die Spezifikation der BEUG und die ELZET80-spezifischen Erweiterungen.
 

BITBUS/IEEE1118-Spezifikationen

Typ: Master/Slave-Netzwerk mit SDLC Nachrichtenaustausch. 248 Byte max. Nettodatensatz pro Nachricht.
Struktur: Bus, beidseitig terminiert. Stichleitungen und Verlängerungen durch Repeater möglich.
Medium: Verdrilltes Kabel (ein Paar, 120Ohm charakteristische Impedanz) mit Signalmasse und Abschirmung. Zweites Aderpaar nötig in Repeatersegmenten.
Elektrisch: 0/5V-Differenzsignal wie in RS485 definiert.
Protokoll: SDLC bitsynchrone selbstgetaktete NRZI-Übertragung mit Start- und Abschlußflags, Adressprüfung und 16-Bit-CRC-Prüfwort.
Datenrate: 375kBit/s oder 62,5kBit/s, höhere optional.
Teilnehmer: 28 pro Segment. Mit Repeatern 250 maximal. Datenrate über mehr als zwei Repeater in Serie: 62,5kBit/s.
Länge: 300m pro Segment bei 375kBit/s, 1200m bei 62,5kBit/s.
Steckverbinder: 9poliger D-Stecker.


BITBUS in der Netzwerkhierarchie: Verwenden Sie Ethernet, um große Mengen Daten zu transportieren; verwenden Sie AS-i, um einzelne Sensoren anzuschließen.
BITBUS bewegt Datenblocks mittlerer Größe zwischen autonomen Stationen (Distributed control).
BITBUS benutzt preiswerte Verdrahtung und bietet große Reichweiten.

Die Spezifikation des BITBUS-"Erfinders" Intel (englisch).

BAPI

BAPI-Standard der Bitbus European Users Group

BAPI/TCP

BITBUS über Ethernet - Die Spezifikation

Bei Windows oder Linux sprechen Sie den BITBUS über den BAPI-Treiber (DLL) an. Wenn Sie von einem anderen Betriebssystem aus auf BITBUS zugreifen wollen, bietet der BAPI/TCP-Server auch einen Direktzugang über eine TCP-Socket-Schnittstelle als Master oder Slave.

BAPITCP - Implementation specifics