Eine Steuerung im Solution Center hinzufügen

Im linken Teil des Solution Centers befindet sich der Solution Navigator. Dies ist sozusagen Ihr Projektbaum. Zu einer Solution kann alles mögliche gehören:

• Vorlagen
• M-PLC-Projekte
• Online-Devices
• Offline-Devices
• ...

Wie bereits aufgelistet, gibt es sogenannte Online-Devices und Offline-Devices:

• Online-Devices sind quasi nur Verbindungs-Konfigurationen zu real existierenden physikalischen Geräten. Ist ein Gerät erreichbar, wird seine Konfiguration ausgelesen und unter dem Online-Device als Konfigurationsbaum angezeigt.
• Offline-Devices können entweder sein
  • Backups real existierender physikalischer Geräte: Sie können aus einem Online-Device ein Offline-Device erstellen. Dadurch wird eine Offline Kopie erstellt, die Sie als Backup nutzen können.
  • Am grünen Tisch geplante Geräte, deren Konfiguration später auf reale Geräte übertragen (deployed) wird.
• Online- und Offline-Device ghören immer zusammen zu einem Gerät.

Da die Online-Devices nur Verbindungs-Konfigurationen enthalten, brauchen Sie diese also nur einmal anlegen, sofern Sie immer mit Steuerungen mit gleichen IP-Adressen arbeiten. Dann erstellen Sie sich eine Solution, die Sie für alle Ihre Projekte nutzen können. Nicht benötigte Geräte sind einfach "tot" in der Solution: Diese Geräte können nicht erreicht werden.

Um nun eine neue Solution hinzuzufügen, machen Sie einen rechten Mausklick auf das Element "Solution Projekte" und wählen Sie "Neu => Solution". Geben Sie einen sprechenden Projektnamen ein. Beispielsweise "Testanlage".
Nun ist ein Projekt mit einem Vorlagenordner angelegt.
Um nun ein Gerät anzulegen, machen Sie einen erneuten Rechtsklick auf den Projektordner und wählen "Neu => Device". Im neuen Fenster können Sie nun noch einmal entscheiden, unter welchem Projekt das Gerät angelegt wird.
Im folgenden Dialog haben Sie die Möglichkeit, ein Gerät zu suchen oder aber manuell einzurichten:

• Sie können Ihr aktuelles Netzwerk durchsuchen (abhängig von der IP Ihrer Netzwerkkarte).
• Sie können einen IP-Adressbereich vorgeben, in dem gesucht wird.
• Suchen über Router hinweg funktioniert nicht. Das Gerät muß sich im gleichen physikalischen Netzwerk befinden, wie Ihr PC.
• In den Suchergebnissen werden einzelne Steuerungen mehrfach erscheinen. Der Grund ist unklar.
• Sie können einzelne Geräte blinken lassen und auch die IP ändern. Hierzu müssen die Schalter auf PROG/3 stehen.
• Sie können ein Gerät manuell anlegen, beispielsweise, wenn Sie keine Netzwerkverbindung zum Gerät haben oder Geräte in einem anderen Netzwerk hinzufügen müssen.
• Steuerungen der neuesten Generation lassen sich über USB (die kleine USB-Buchse, nicht die große) auch direkt ansprechen.
• Haben Sie redundante Geräte, so setzen Sie den Haken "Redundant", dann wird gleich im Anschluß das zweite Gerät konfiguriert und beide werden im Projektbaum gruppiert.

Geben Sie dem Gerät einen sprechenden Namen; beispielsweise "Hauptsteuerung" oder "Unterstation".
Klicken Sie auf "Fertigstellen" - die weiteren Einstellmöglichkeiten sind in der Regel nicht von Belang, sofern Sie mit den Standardeinstellungen arbeiten.
Fertig!
Nun haben Sie ein neues Gerät in Ihrem Projektbaum, welches sowohl ein Online-, wie auch ein Offline-Device besitzt.
Über das Online-Device können Sie nun mit dem realen Gerät kommunizieren bzw. dieses online konfigurieren.

nach oben...

---

Eine Steuerung mit M-PLC verbinden

M-PLC ist nur das Progrgammierwerkzeug. Mit M-PLC wird keine Hardware-Konfiguration erstellt. Daher muß M-PLC erst einmal das zu programmierende Gerät bekannt gegeben werden. Dieses geschieht über ein Hilfsprogramm "Targetmanager". Sie finden ihn im Startmenü unter "Bachmann =< M1 Software" und danach im Tray mit folgendem Icon:



Mit Doppelklick öffnen Sie ihn:



Hier sind alle Steuerungen aufgelistet, mit denen Sie in M-PLC kommunizieren können. Die hier vergebenen Namen tauchen in M-PLC wieder auf:



Doch dazu gleich mehr...
Erst einmal muß die Steuerung im TargetManager hinzugefügt werden. Dazu klicken Sie auf "Hinzufügen...".
Geben Sie nun einen sprechenden Namen für die Steuerung ein. Die Beschreibung ist nur ein Kommentar und nicht notwendig. Nun geben Sie die IP der Steuerung ein, unter der Sie sie auch im SolutionCenter eingebunden haben. Sollten Sie später beim Aufspielen der Software Probleme durch Timeout bekommen, können Sie versuchen, die Wartezeit für diese Steuerung hochzusetzen. erfahrungsgemäß sind Werte von 30-50s ausreichend.
Klicken Sie anschließend auf "Schließen", nicht auf "Beenden".

Nun haben Sie die Grundlage gelegt, auf der wir im M-PLC aufbauen können. Starten Sie dieses nun - entweder mit einem vorhanden Projekt oder legen Sie ein neues an.
Gehen Sie bei geöffnetem Projekt nun auf "Online =< Kommunikationsparameter..." und Sie bekommen das Fenster, welches bereits oben gezeigt wurde.
Hier nehmen Sie nun einige M-PLC-spezifische Einstellungen vor:
Wählen Sie die Steuerung aus, auf welche das Programm übertragen werden soll. Soll auf zwei Steuerungen das gleiche Programm geladen werden (beispielsweise bei redundanten Projekten oder bei zwei Steuerungen mit gleichartigem Programm), so können sie den Haken "Redundanz" setzen und eine zweite Steuerung auswählen.
SW-Module Name gibt den Namen an, unter welchem es in der Steuerung eindeutig identifiziert wird. Hintergrund:
Sie können ein und das selbe Programm mehrfach aufrufen (z.B. mit unterschiedlichen Parametern). Jede Instanz bekommt einen eigenen SW-Module Namen, so daß sie eindeutig identifiziert ist. Der Modulname erscheint auch hinterher im SolutionCenter im Online-Device.
Der Name darf keine Sonderzeichen enthalten, außer dem Unterstrich (_). Der Name darf nicht länger als 8 Zeichen sein und wird immer in Großbuchstaben interpretiert. Standardmäßig wird der Name des gespeicherten M-PLC-Projekts auf 8 Zeichen gekürzt. Sie können ihn aber auch frei wählen.
Unter Installationseinstellungen müssen Sie den Haken "Permanent installieren" setzen, damit das Bootprojekt erzeugt wird und das Programm bei jedem Start der Steuerung gestartet wird. Ansonsten kopieren Sie nur das Programm, laden es, aber bei einem Neustart der Steuerung wird es nicht geladen, da es nicht in die mconfig.ini eingetragen wird. Dieses Feld kann beim erstmaligen Konfigurieren der Steuerung in M-PLC noch ausgegraut sein. In diesem Fall stellen Sie die Steuerung ein, schließen den Dialog und öffnen ihn erneut, dann können Sie den Haken setzen.
Den Pfad müssen Sie in der Regel nicht anpassen. Die Projekte werden auf dem Bootmedium in das APP-Verzeichnis kopiert. Möchten Sie ein abweichendes Verzeichnis (beispielsweise ist FLASH das Bootmedium, die Programme sollen aber auf der CFC abgelegt werden, so müssen Sie den Pfad hier angeben: /cfc0/app/.
Weiter unten sehen Sie rein informativ, welche Projekte bereits auf der Steuerung installiert sind.

nach oben...

---

Die wichtigsten Unterschiede zu Siemens. ODER Grundlagen der Bachmann-Steuerung.

Kommt man aus der Siemens-Welt, so hat man im Kopf: Eine Steuerung = ein Programm. Alle Konfiguration wird im Programm erledigt.
Davon muß man sich hier verabschieden!
Denken Sie sich die Steuerung als einen PC, mit all seinen Möglichkeiten - dann verstehen Sie eher, wo der Hase läuft.

Sie haben also einen PC (die Steuerung), auf diesem haben Sie als erstes mehrere Speichermedien (bspw. Flash/cfc/USB). Diese Speichermedien können mehrere Partitionen besitzen (bspw. cfc0, cfc1, cfc2). Auf diesen Medien - auf die Sie vollen Zugriff haben - ist das Betriebssystem mit all seinen Daten (Betriebssystemkern, Treiber, Systemdaten, Programmen, Konfiguration) abgelegt. Sie können bestimmen, welche Daten wo liegen, Sie können bestimmen, von welchem Medium Sie booten. Sie können alles selbst bestimmen - wenn Sie wollen. Sie müssen nicht, aber Sie können. Natürlich können Sie damit auch alles "kaputt" machen (nicht physikalisch, aber funktionell).

Sie haben also nicht EIN Programm auf EINER Steuerung. Sie haben beliebig viele (natürlich begrenzt durch die CPU und den Speicher) Programme auf einer Steuerung. Diese Programme sind einzelne Dateien. Die *.m-Dateien. Jedes Programm kann in einer oder mehreren Instanzen aufgerufen werden. Es können in M-PLC auh gleich mehrere Tasks in einem Programm geschrieben werden, welche parallel laufen.

Über FTP haben Sie vollen Zugriff auf die Steuerungen und den gesamten Inhalt aller Speichermedien. Sie können also beliebig Backups ziehen, Kopien auf der Steuerung hinterlegen, ja sogar Ihr komplettes fertiges Projekt später auf die Steuerung kopieren, so daß auf der Steuerung immer das aktuelle Projekt hinterlegt ist.

Die gesamte Konfiguration ist nur an einem Ort abgelegt: Der mconfig.ini-Datei im Stammverzeichnis des Bootmediums. Es gibt keinen anderen Ort, nur diesen. Und diese Datei ist eine reine Text-Datei, lesbar. Kopieren Sie eine mconfig.ini mit einer bekannten IP auf einen USB-Stick und starten die Steuerung von USB, anstatt von Flash oder CFC, so können Sie jede Steuerung ansprechen, auch wenn Sie die IP nicht kennen. Danach lesen Sie die mconfig.ini auf der Steuerung aus und wissen, welche IP die Steuerung hat. Einfacher geht es nicht.

Das ist der große Vorteil dieses Systems: Sie haben eine menschenlesbare Konfigurationsdatei, die die gesamte Konfiguration enthält. Sie können den Inhalt auf jede beliebige Art erzeugen: Per Solution-Center-Oberfläche, per Excel, per Text-Vorlagen, per eigenem Konfigurationstool, ... alles ist denkbar.
Das ist aber auch gleichzeitig der große Nachteil, weil die Oberfläche vom SolutionCenter nicht immer für die Massenparametrierung tauglich ist. Haben Sie mehrere verteilte Stationen, die miteinander kommunizieren, so können Sie die Konfigurationen nicht gegeneinander abgleichen - aber von einer Station auf die andere kopieren.

Es gibt bei CoDeSys keinen Online-Offline-Vergleich. Da das kompilierte Programm auf die Steuerung kopiert wird, können die Versionen nur anhand der Checksumme und des Datums abgeglichen werden. Detailvergleiche sind nur mit verschiedenen Offline-Programmständen in M-PLC möglich.

Sie merken also, im Vergleich zu herkömmlichen Industriesteuerungen eine komplett andere Philosophie. Aber im Vergleich mit einem PC denke ich recht schnell verständlich.

nach oben...

---

Wo sind meine Datenbausteine? ODER Wie organisiere ich meine globalen Daten?

In CoDeSys fehlt das Konzept von "Datenbausteinen". Es gibt Instanzen von FBs, diese werden aber im aufrufenden Programm oder global als Variable angelegt, nicht als Instanz-DB.
Alle globalen Daten werden in Variablenlisten angelegt. Dazu gehen Sie in M-PLC links im Navigationsbereich unten auf den Reiter "Ressourcen". Dann sehen Sie oben einen Ordner "Globale Variablen". Hier können Sie verschiedene Variablenlisten anlegen.
In jeder Liste können Sie die Bereiche VAR_GLOBAL/END_VAR beliebig oft definieren. Jedem Bereich können Sie noch Schlüsselwörter zuordnen. Beispielsweise

• REDUEX: So deklarierte Variablen werden nicht in der Redundanz berücksichtigt
• RETAIN: So deklarierte Variablen bleiben auch über einen Spannungsausfall hinweg erhalten
• CONSTANT: Konstanten, nicht während der Laufzeit veränderbar

Somit können Sie sich mit Hilfe dieser Variablenlisten quasi Global-DBs erstellen, in denen Sie Daten strukturieren.

nach oben...

---

Wo sind meine OBs? ODER Wie organisiere ich meinen Programmablauf?

Der Programmablauf wird in CoDeSys anders geregelt, als in Step7. Statt den OBs gibt es den Bausteintypen "Programm". Dieses ist quasi die oberste Ebene. Programme können sich gegenseitig aufrufen oder von FBs aufgerufen werden, aber nicht als Instanz. Sie haben einen eigenen Speicherbereich, in dem beispielsweise Instanzen von FBs abgelegt werden können. Diese Werte bleiben von Aufruf zu Aufruf erhalten. Programme sind global bekannt.

Programme können nun ereignisgesteuert oder zyklisch aufgerufen werden. Sie können in einem M-PLC-Projekt ein oder mehrere Programme aufrufen. Um das zu konfigurieren, gehen Sie im M-PLC links im Navigationsbereich unten auf den Reiter "Ressourcen". Dann sehen Sie einen Punkt "Taskkonfiguration". Öffnen Sie diesen Punkt, sehen Sie dort den "DefaultTask" konfiguriert. Diesem können Sie wahlweise weitere Tasks hinzufügen.
Die hier einstellbare Priorität unterscheidet sich von der Priorität auf der Steuerung. Sie korrelieren zwar, sind aber unterschiedlich granular: Die Priorität in M-PLC kann zwischen 0..31 eingestellt werden. Diese wird auf die Steuerungspriorität 18..175 umgesetzt, welche real von 0..255 geht. Je höher die Zahl, desto geringer die Priorität. Das Äquivalent der Steuerungspriorität wird bei Änderung unten im Fenster angezeigt. Standard ist 19.
Darunter können Sie den Aufruftyp einstellen:

• Zyklisch: Der Task wird in einem festen Zeitabstand aufgerufen (Vergleichbar mit Weck-OBs bei Step7). Er muß aber auch in diesem Zeitraster abgearbeitet werden können.
• Freilaufend: Der Task wird abgearbeitet und sofort wieder aufgerufen - allerdings mit niedrigster Priorität. Das ist vergleichbar mit OB1 bei Step7.
• Extern ereignisgesteuert: Hier können verschiedene Ereignisse (Fehler, Events, Synch-Signale) gewählt werden. Vergleichbar mit Fehler- oder Ereignis-OBs in Step7.

Über "PI deaktivieren" kann das Prozeßabbild abgeschaltet werden.

nach oben...

---

Wo ist meine HWConfig? ODER Wie konfiguriere ich meine Hardware?

Die Hardware-Konfiguration wie in Step7 gibt es nicht - schon gar nicht so komfortabel.
Die Konfiguration wird - bei fertiger Station - bereits aus der Hardware übernommen. Das Online-Device ermittelt automatisch die angeschlossene Hardware. Diese können Sie weiter konfigurieren.
Sie können dabei entweder live mit dem Online-Device arbeiten oder aber ein Offline-Device am grünen Tisch zusammenstellen.
Der Vorteil vom Online-Device ist, daß Sie alle Auswirkungen direkt sehen und das Gerät direkt konfigurieren. In vielen Fällen ist das von Vorteil, da Hardware oder Variablen oftmals direkt vom Gerät importiert werden müssen.
Der Nachteil ist, daß die Konfiguration unter Umständen recht lange dauert, da oftmals Neustarts bei Änderungen notwendig sind, um übernommen zu werden.
Das Offline-Gerät wird konfiguriert und kann dann später "deployed" werden, also auf das entsprechende Gerät aufgespielt werden. Benötigen Sie die Hardwarekonfiguration in M-PLC, muß diese exportiert und dort importiert werden. Beim Online-Device wird sie einfach ausgelesen.

Der größte Nachteil ist aus meiner Sicht, daß nur bei wenigen Aktionen verständliche Assistenten gibt. Der Benutzer wird seinem Erfahrungsschatz (der erst gesammelt werden muß) und bei größeren Konfigurationen seinen selbst gebauten Konfigurationswerkzeugen überlassen. Es läßt sich zwar alles über das Solution Center konfigurieren, hat man aber beispielsweise 100 Signale zu übertragen, so wird diese Fleißarbeit zur Nervensache - denn jedes Signal muß einzeln per Hand eingegeben werden. Auf der anderen Seite spielt das System hier seinen Vorteil aus, daß die Konfiguration in einer menschenlesbaren Textdatei gespeichert ist. So läßt sich auch die größte Konfiguration über Excel erzeugen und einfach in die Datei hineinkopieren. Wobei natürlich die Fallstricke der Syntax beachtet werden müssen. Ansonsten sieht alles richtig aus, wird unter Umständen sogar korrekt im Konfigurationsdialog vom Solution Center korrekt angezeigt, aber beim Starten der Steuerung trotzdem vom Interpreter ignoriert - ohne Fehlermeldung.

nach oben...

---

Wozu sind die Drehschalter auf der Steuerung?

Die CPU besitzt zwei Drehschalter, der untere ist der "High"-Schalter, der obere der "Low"-Schalter.
Diese haben folgende Bedeutung:






Anmerkungen:

• Testmodus: wenn das Prozessor Modul alle Parameter vergessen hat, (konnte früher mal vorkommen, als es noch Batterie gepufferten NVRAM0 gab) kann in diesem Modus alle nötigen Parameter für die Wiederherstellung in der Konsole eingetragen werden.
• Im Modus Prüffeld werden die Steuerung in Klimaschränken über die COM1 mit Zentralrechnern verbunden, um Testprogramme, Reboots, Messdaten und Reports von der Steuerung anzufordern.
• Bootmodus F4 und F5 unterscheiden sich nicht.

nach oben...

---

Unterschiede zwischen Virtual und VirtualRW

Werden Karten auf Virtual eingestellt, so wird reale Hardware simuliert. Eingänge lassen sich weder mit der PLC-Software, noch mit dem Solution-Center beschreiben.
Werden Karten auf VirtualRW eingestellt, so wird reale Hardware simuliert. Eingänge lassen sich sowohl mit der PLC-Software, als auch mit dem Solution-Center zu Testzwecken beschreiben.

Wird reale Hardware gefunden, wird der Modus der Karte automatisch auf Real umgestellt. Somit lassen sich auch robuste Systeme aufbauen, in welchen defekte Karten ausgebaut werden können, aber das Programm weiterläuft. Allerdings lassen sich fehlende/defekte Karten nicht erkennen.

nach oben...

---

Die Schnittstellen

Es gibt einige Standard-Schnittstellen, welche ich hier kurz beleuchten möchte:

Die Steuerungen besitzen zwei Ethernet-Schnittstellen. Anders als bei Siemens sind dieses tatsächlich eigenständige Schnittstellen und sind nicht "verswitcht". Der Vorteil: Es können zwei eigenständige Netze aufgebaut werden. Der Nachteil: Ein Durchschleifen des Ethernets á la "In/Out" wird nicht unterstützt. Entweder muß der Datenverkehr explizit von einer Schnittstelle zur anderen geroutet werden (was meines Wissens nach nur über ein eigenes Programm funktioniert) oder aber alle Steuerungen müssen sternförmig miteinander über einen (oder mehrere) Switche verbunden werden.

Des Weiteren besitzen die Steuerungen eine aktive USB-A-Buchse über die sich Speichermedien anschließen lassen. Diese können für verschiedenste Zwecke genutzt werden, beispielsweise

• Updates
• Backups
• Datenübertragung
• Speichererweiterung
• Ersatz des internen Speichers
• Notfall-Bootmedium

Gerade der letzte Punkt wird interessant, wenn man an eine unbekannte Anlage kommt oder eine unbekannte Steuerung in den Händen hält. Oftmals ist die IP nicht bekannt. Hält man einen USB-Stick mit einer Konfigurationsdatei bereit, so kann man von ihm booten (das Betriebssystem kann auf dem Stick liegen oder vom Gerät geladen werden) und die Konfigurationsdatei des Gerätes einsehen - und so die IP auslesen.
Auch lassen sich Testszenarien damit schnell durchführen: Den internen Speicher der Steuerung auf den USB-Stick kopieren, eine zu testende Software auf den Stick kopieren und den Stick als Bootmedium einstellen. Schon testen Sie Ihr neues Programm, ohne die originale Version auf der Steuerung zu verändern. Geht etwas schief oder ist der Test beendet, den Drehschalter wieder zurückstellen, USB-Stick ziehen und das alte Programm läuft wieder.
Neuere Steuerungen besitzen auch eine USB-Mini-B-Buchse zum direkten Anschluß der Steuerung an ein Programmiergerät. So ist bei neueren Steuerungen auch die Kenntnis der IP nicht mehr notwendig, um sich mit einem Gerät zu verbinden. Fraglich ist hier nur, ob die Entscheidung für eine Mini-B-Buchse besser war als für eine normale Typ-B-Buchse, wenn man die teilweise rauhen Umgebungsbedingungen bedenkt, in denen Steuerungen eingesetzt werden.

Auf den Geräten befinden sich in der Regel zwei serielle Schnittstellen. Dabei ist die erste fest auf RS232 eingestellt. Auf diese wird standardmäßig die Konsole ausgelesen, so daß bei schwerwiegenden Problemen über ein Terminal hier direkt Fehler ausgelesen werden können.
Die zweite Schnittstelle ist umschaltbar zwischen RS232/RS422/RS485. Die Umschaltung ist auch aus einem Programm heraus möglich, so daß sich durch ein Umschalten der Topologie (da unterschiedliche Pins beschaltet sind) ein "Abschalten" der Schnittstelle realisieren läßt. Die Kommunikation der Schnittstellen findet im überlagerten Betriebssystem statt, so daß vom Programm der Puffer regelmäßig ausgelesen werden muß. Das Betriebssystem stellt selbst keinen Indikator "New Data" bereit.

Einige Steuerungen besitzen darüber hinaus noch eine CAN-Schnittstelle.

nach oben...

---

Wozu gibt es Stationsnummern?

Ein Rückwandbus einer Station kann max. 16 Module verwalten. Wenn diese Modulzahl erhöht werden soll oder aber der Rückwandbus verlängert werden soll, wobei die Busschienen mehr als 10cm auseinandersitzen, so kann eine Station per Fastbus erweitert werden.
Dafür wird ein Fastbus-Master und ein Fastbus-Slave benötigt. Der Fastbus-Master hat wiederum eine eigene Stromversorgung, um seinen Rückwandbus zu versorgen.
Diese Erweiterung wäre dann Station 2.

nach oben...

---

Nummerierung der Karten

Eine Kartennummer ist möglich von 1..32000. Die Nummer einer Karte innerhalb dieses Bereichs ist beliebig, muß aber innerhalb einer CPU eindeutig sein.
Die Kartennummern gelten sowohl für reale (Hardware) Karten, wie auch für virtuelle (Software/Bus/Kommunikation) Karten.
Somit kann man sich firmenintern bestimmte Kategorien aufbauen.
Beispielsweise läßt sich folgende Kategorisierung denken:
Eine Karten-Nummer ist wie folgt aufgebaut: XyyZZ

• X
  • Nicht vorhanden: Hardware-Karte (I/O oder Schnittstellenmodul)
  • 1 = Virtuelle Karte für die Übertragung von Peripheriedaten
  • 2 = Modbus-Master-Karte
  • 3 = Virtuelle Karte für die Übertragung von Modbusdaten
• yy
  • Nicht vorhanden: Hardware-Karte (I/O oder Schnittstellenmodul)
  • 2stellig: Nummer der Unterstation (Slavenummer)
• ZZ
  • 2stellig: fortlaufende Kartennummer am Slave (sowohl Hardware, wie auch Software-Karten)

Beispiel 1:
Die IO-Karte auf Slave Nr. 2, in Slot 3 kann Karte 3 heißen.
Die zugehörige Kommunikationskarte (virtuell) hieße dann (sowohl auf dem Slave, wie auch auf dem Master) 10203.

Beispiel 2:
Die Modbus-Karte auf Slave 3 kommuniziert mit dem Modbus-Slave 50. Sie hat die Nummer 20350.
Die zugehörige Kommunikationskarte (virtuell) hieße dann (sowohl auf dem Slave, wie auch auf dem Master) 30350.

Dieses Schema läßt sich natürlich für jede Firma anpassen und stellt hier nur ein Beispiel dar, wie man die Menge an Kartennummern sinnvoll nutzen kann.

nach oben...

---

Nummerierung der Slots

Die Slot-Nummern werden für jede Karte angegeben, aber weder bei Modbus- noch bei BCH-Karten genutzt oder überprüft, sie können dort beliebig vorgegeben werden. Es ist davon auszugehen, daß auch andere virtuelle Karten die Slot-Nummer nicht nutzen. In diesem Fall wäre sie ausschließlich für Hardware-Karten relevant, deren Steckplatz sie angibt.

nach oben...

---

Zähler

Auf einigen DIO-Karten lassen sich Sonderfunktionen, wie z.B. Zählerfunktionen aktivieren.
Wird eine Zählerfunktion aktiviert, werden am Ende der Karte zusätzliche analoge Kanäle aktiv, auf denen der Zählerstand abgeholt (lesen) und gesetzt (schreiben) werden kann.
Der Zählerstand wird als DINT repräsentiert, zählt also bis 2147483647. Danach kommt ein Überlauf auf -2147483647.
Die maximale Impulsfrequenz liegt bei 20kHz, die Impulslänge darf 33µs nicht unterschreiten.
Zu einem Zähler gehören mehrere Eingänge für Zusatzfunktionen: Rücksetzen, Zählrichtung, ...
Einige dieser Eingänge können für normale DI-Funktionen genutzt werden, sofern sie nicht für die Funktion des Zählers benötigt werden. Siehe dazu Dokumentation der Baugruppen.

nach oben...

---

Wie lasse ich mehrere Tasks untereinander kommunizieren?

Haben Sie mehrere Tasks programmiert, so kommt es häufiger einmal vor, daß diese Daten untereinander austauschen müssen. Dazu kann man zwei Wege gehen. Entweder über GDs, das sind allgemeine Speicherbereiche in der Steuerung, die von allen Tasks gemeinsam genutzt werden (vergleichbar mit Merkern in Step 7). Oder man geht den Weg der Hochsprache: Über Pointer.
Diesen letzten Weg möchte ich hier einmal kurz erläutern.
Der Gedanke ist, daß man die Daten in einem Task ablegt und dann von einem anderen Task heraus darauf zugreift. Dazu legt man sich am besten einen Benutzerdefinierten Datentypen (Step7: UDT) an. Diesen gibt man in beiden Programmen bekannt. Nennen wir ihn "PubData".
In dem einen Task legt man nun eine globale Variable vom Typ PubData an und liest und beschreibt sie ganz normal. Nun bildet man einen Pointer auf diese Variable. Wichtig: Dieser Pointer muß als SVI-Variable veröffentlicht werden.
In dem anderen Task legt man nun einen Pointer vom Typen PubData an. Initial hat dieser Pointer den Wert NULL.
Das erste, was nun das Programm beim Hochstarten machen sollte, ist, sich einen Wert für diesen Pointer zu holen, nämlich die Adresse, unter der die Daten im ersten Task gespeichert sind.
Dazu sind mehrere Schritte notwendig:

• Mit SMI_Connect_NB wird eine Verbindung zur CPU aufgebaut. Gibt man hier -1 für die IP an, bekommt man eine Verbindungs-ID zur lokalen CPU. Es kann aber auch eine Verbindung zu jeder beliebigen CPU im Netzwerk aufgebaut werden. Somit lassen sich auch Kommunikationskanäle zwischen CPUen aufbauen.
  Wichtig ist hier, daß man den Befehl mit der Endung _NB nutzt. NB steht für "Non Blocking". Das heißt, der Programmablauf wird nicht blockiert. Man ruft die Funktion auf und fragt sie in jedem Zyklus erneut ab, ob bereits ein Ergebnis vorliegt. Weder Programm noch Systemressourcen werden blockiert.
• Mit SMI_GetAddr holt man sich nun die Adresse, an welcher der Pointer auf PubData liegt.
• Ist das erfolgreich, liest man mit SMI_GetVal den Wert des Pointers und überprüft ihn auf ungleich NULL.

Alle Funktionen sind in der Bibliothek SMI_plc.lib definiert.
Auf diese Weise stellt man sicher, daß der erste Task läuft und bereits gültige Werte schreibt. Ansonsten steht im Pointer weiterhin NULL und er wird nicht ausgewertet.
Nun hat man einen gültigen Pointer im zweiten Task und kann über den Dereferenzierungs-Operator ^ direkt auf die Werte zugreifen. Beispielsweise so: MyPointerToPubData^.MyValue.
Vorsichtig muß man sein, wenn nun der erste Task angehalten oder aktualisiert wird. Dann kann es zu unvorhergesehenen Folgen kommen. Ansonsten funktioniert diese Methode einwandfrei.

nach oben...

---

Was sind BCH/BCR/BCP?

Bluecom (BC) ist bei Bachmann die Grundlage der Redundanz. Diese gibt es in zwei verschiedenen Ausbaustufen: Netzwerkredundanz und Hot-Standby-Redundanz.
Für die Netzwerkredundanz ist die Grundlage das BCP, das Bluecom-Protokoll. Es realsisiert auf Netzwerkebene die Redundanzmechanismen und das Voting, welche Verbindung genutzt wird.
Für den Anwender ist der BCH, der Bluecom-Handler die Schnittstelle zum BCR. Im BCH werden virtuelle Karten mit Kanälen zur Datenübertragung definiert. Der BCH übernimmt also die Rolle des Datenorganisators.
Wird nun eine Hot-Standby-Redundanz von zwei Steuerungen gewünscht, kommt der BCR, Bluecom Redundanz, ins Spiel. Dieser ist verantwortlich, daß die daten der beiden Steuerungen untereinander abgeglichen werden. Dazu wird für den abzugleichenden Task ein BCR-Kanal eingerichtet. Dieser Kanal ist bis zu 1440 Byte groß und gleicht die in ihm gespeicherten Daten des Tasks auf beiden Steuerungen ab. Muß er dieses über mehrere Zyklen machen, weil in beiden Tasks dauerhaft unterschiedliche Werte produziert werden, fällt die Steuerung aus der Redundanz. Im Redundanzkanal sind standardmäßig alle Variablen des Tasks, außer, sie werden als REDUEX gekennzeichnet. Für die Größenermittlung des Kanals werden sie allerdings weiterhin mitgezählt, was bedeutet, es kann kein redundanter Task größer als 1440 Byte aufgebaut werden.
Allerdings lassen sich bis zu drei Tasks redundant halten, also 3x 1440 Byte = 4320 Byte.
UM die Hot-Standby-Redundanz nutzen zu können, müssen spezielle Funktionen für Zeiten und Zähler verwendet werden, welche kompatibel mit der Redundanz sind. Diese sind in der BCR_plc.lib hinterlegt.

nach oben...

---

Größe einer BCH-Karte berechnen.

Rechnen Sie die Größe aller DO-Kanäle zusammen (U1/Bool zählt als Byte!) und runden Sie auf ein Vielfaches von 4 auf, 8Byte addieren = Ausgangs-Paketgröße
Rechnen Sie die Größe aller DI-Kanäle zusammen (U1/Bool zählt als Byte!) und runden Sie auf ein Vielfaches von 4 auf, 8Byte addieren = Eingangs-Paketgröße
Eingangs-Paketgröße Slave = Ausgangs-Paketgröße Master
Ausgangs-Paketgröße Slave = Eingangs-Paketgröße Master

Sind die 8Byte nicht hinzugerechnet, kann es zu folgender Fehlermeldung kommen: BCH_CREATETRAILER: Input length of 'local:SlaveXXX' too short for trailer!.

Zur Diagnose gibt es einen Consolen-Befehl:

bch_ShowCard(CardNb)
Dieser gibt die konfigurierten sowie die benutzten Längen aus (z.B. "LengthIn: 100 (used 12)")
Auf die Länge "used" müssen noch die 8Byte für den BCH gerechnet werden!

Die 1400Byte, welche im BCP angegeben werden können, beziehen sich nicht auf ein Segment, dies ist die maximale Datenlänge pro Slave.
Es gibt im Segment eine gemeinsame Konfiguration, welche dann aber für alle Slaves gilt, dies ist aber keine Begrenzung für das Segment, sondern für die einzelnen Slaves.

nach oben...

---

Unterschied bch_DoCmd und bcr_UpdatePi

Das doCmd aktualisiert nur das Prozeßabbild im BCH. Die Hot-Standby-Redundanz (BCR) wird dabei nicht aktualisiert. Das kann zu unerwarteten und unerwünschten Ergebnissen führen. Daher sollte im voll-redundanten Betrieb immer bcr_UpdatePi eingesetzt werden, da dieser auch die Redundanz-Kanäle aktualisiert.

Umgekehrt darf bei nur netzwerk-redundanten Systemen nicht bcr_UpdatePi eingesetzt werden, da hier kein BCR vorhanden ist. Es kommt dann zu extrem langsamen Aktualisierungen auf dem BCH. Hier muß bch_DoCmd eingesetzt werden.

nach oben...

---

MaxCycleTime

Die MaxCycleTime definiert, nach welcher Zeit der Task in dem Kommunikationspuffer nach neuen Daten schaut. Je nach Baudrate muß die MaxCycleTime angepaßt werden. Ist diese zu groß, wird es im Logbuch eingetragen, da der Task zu selten nach neuen Daten schaut und eine konforme Kommunikation so nicht stattfinden kann.
Für die On-Board-Schnittstellen wird das Schlüsselwort COM[COM-Port]MaxCycle verwendet, MaxCycle wird somit pro Port eingestellt.
Für die RS204-Karte wird das Schlüsselwort MaxCycle verwendet, MaxCycle wird somit modulweit für alle 4 Ports eingestellt.

Empfohlene Werte für MaxCycle:




nach oben...

---

Modbus-Adressierung

Modbus gruppiert verschiedene Datentypen: Digitale Werte = Coils (lesen/schreiben) und Analoge Werte = Register (lesen/schreiben). Die Telegrammfunktionen 03H und 10H verwenden beispielsweise Register-Adressen ab 40001. Der Datentyp 4xxxx ist dabei bereits durch die verwendete Telegrammfunktion gegeben.
Im Telegramm wird deshalb die 4 weggelassen und der Datentyp in den Modbus-Beschreibungen zumeist nicht angegeben.

Speziell beim Modbus-Telegramm ist auch, dass die Nummerierung der Register bei 1, die Adressierung jedoch bei 0 beginnt.
So wird also z.B. beim Lesen des Registers 40001 im Telegramm die Adresse 0 abgefragt.

Coil/Register Nummern	Modbus-Adresse	Daten Adresse	Typ	Beschreibung
1-9999	0-9998	0000 bis 270E	Read-Write	Einzelne Output Coils
10001-19999	10000-19998	0000 bis 270E	Read-Only	Einzelne Input Coils
30001-39999	30000-39998	0000 bis 270E	Read-Only	Analoge Input Register
40001-49999	40000-49998	0000 bis 270E	Read-Write	Analoge Output Holding Register

Coil- bzw. Register Nummern kann man sich vorstellen als Speicherplatznamen, denn sie existieren in den eigentlichen Telegrammen nicht. Verwendet werden dort die Daten-Adressen.

Zum Beispiel hat das erste Holding Register, Nummer 40001, die Datenadresse 0.
Die Differenz zwischen diesen beiden Werten ist der Offset.
Jeder Datentyp hat einen Offset: 1, 10001, 30001 und 40001.

• Register 1 (Coil 1) = Modbus-Adresse Coil0_1 (Bachmann / Master) oder Modbus[0] für ein Slave-Mapping CoilsSviList auf das Array of BOOL Modbus[0..x].
  
• Register 40001 (HReg 1) = Modbus-Adresse HReg0_1 (Bachmann / Master) oder Modbus[0] für ein Slave-Mapping HRegsSviList auf das Array of UInt Modbus[0..x].

nach oben...

---

Konsistente Übertragung aller Daten

Bei einigen Modbus-Slaves besteht die Forderung, alle Daten konsistent zu übertragen, das heißt, immer alle Daten in einem Rutsch zusammen.
Dafür gibt es mehrere Möglichkeiten:

• Bei jeden Wert einen kleinen Offset blinken lassen, so daß eine ständige Änderung stattfindet
• Es gibt das DoCmd MIO_CMD_SENMBMESSAGE. Hier muss man zwar alles selbst machen, aber hier kann man selbst bestimmen wann und was man senden möchte.
• Den Funktionsblock Mio_DoCmd8_NB benutzen. Mit dieser Funktion kann man aus einem Array HReg-Daten zyklisch schreiben. Hier kann man die maximale Länge, die in der Norm vorgesehen ist, zyklisch schreiben. Auch nicht geänderte Werte.
• Alle Daten in einen Kanal legen: Channel1 = "MyArray/ARRAY(16)/rwps/HReg0_8". Dann sollten (!) alle Daten konsistent übertragen werden, da sie in einem Kanal liegen.
  • Das Array ist immer ein Array of Byte, die HRegs sind Word.
  • Importiert in M-PLC kann eine weitere Sicht über das Schlüsselwort AT auf den Datenbereich eingerichtet werden.
  • Funktioniert nur mit Arrays bis max. 128, also für 64 Integer.

Laut Handbuch Bachmann:
Um die Anzahl der Abfragen (Requests) und damit der Buszugriffe möglichst gering zu halten, werden diese zusammengefasst. Alle Kanäle, welche die gleichen Lese- bzw. Schreibflags (r, w) gesetzt haben und auf dieselben oder benachbarten Adressen desselben Adressbereiches (Coil, HReg, Disc, IReg) zugreifen, werden zu einer Abfrage zusammengefasst.
Kanäle, die als Einzelabfrage (SCoil und SHReg) definiert wurden, werden nicht mit anderen Kanälen zusammengefasst. Wenn optionale Parameter nicht angegeben werden, werden für diese Parameter Standardwerte verwendet. Somit werden diese Anfragen auch zusammengefasst.

Wenn Kanäle nicht zusammengefasst werden, kann es insbesondere bei schreibbaren Kanälen mit überlappenden Modbus-Server-Datenadressbereichen zu Dateninkonsistenz kommen.

Die Zusammenfassung geschieht auch modulübergreifend, wenn:

• Beim Modbus-UFB Modul die Konfigurationseinstellung CombReqOfCard = TRUE gesetzt ist
• Für ein physikalisches Slave-Gerät mehrere Modbus-Master-UFB-Module konfiguriert wurden. Das System erkennt diesen Zustand folgendermaßen:
  • Bei Modbus-RTU:
    • Die Module die selbe Slave-Adresse haben (Schlüsselwort SlaveAdr)
  • Bei Modbus-TCP:
    • Die Module die gleiche Slave-IP-Adresse haben (Schlüsselwort SlaveIP)
    • Die Module den gleichen Ziel-Port haben (Schlüsselwort PortNb)
    • Die Module die gleiche optionale Slave-Adresse haben (Schlüsselwort SlaveAdrGateway)
• Wenn optionale Parameter nicht angegeben werden, werden für diese Parameter Standardwerte verwendet. Somit werden diese Abfragen auch zusammengefasst.

Fazit:

Sobald sich ein Wert im Prozeßabbild ändert, wird der gesamte Modbus übertragen (s. Zusammenfassung der Anfragen oben).
Ggf. muß die Polling Rate der Schnittstelle auf den Änderungszyklus der Variablen (z. B. bei einem Zähler oder einem Blinkebit) abgestimmt werden.
Beispiel: Zähler ändert sich alle Sekunde, Pollingrate auf 1500ms gestellt.

Ist dieses nicht der Fall, so müssen die Werte mit mio_setValue geschrieben werden, am Prozeßabbild vorbei. Damit erkennen die Modbus-Kanäle, daß sie beschrieben wurden und senden ihre Daten.

nach oben...

---

SyncWithNet

Speziell für die Anwendung von Modbus-Ringen wurde der Parameter SynchWithNet implementiert. Dazu wird ein Modbus-Ring physikalisch aufgebaut und an zwei benachbarte Schnittstellen (bspw. auf einem RS204-Modul) angeklemmt. Dann wird für jede Schnittstelle eine NetNB konfiguriert. Für die erste Schnittstelle wird nun der optionale Parameter SynchWithNet aktiviert und auf die NetNB-Nummer der zweiten Schnittstelle eingestellt.
Nun werden die Schnittstellen jeweils abwechselnd aktiv und inaktiv geschaltet, immer, nachdem eine Slave-Abfrage durchgelaufen ist. Die Daten stehen ganz normal für jede Schnittstelle einzeln hinterher zur Verfügung (sprich: Es müssen auch zu jedem Slave die Modbus-Module zwei Mal konfiguriert werden). Über die Timeouts kann nun festgestellt werden, ob ein Slave über beide Schnittstellen (Ring OK) oder nur über eine Schnittstelle (Ring gestört) erreichbar ist. Dementsprechend kann nun reagiert werden. Diese Implementierung ist dem Programmierer überlassen.

nach oben...

---

BCH

nach oben...

---

BCR / Redundanz

nach oben...

---

Modbus

nach oben...

---

Upload .m von M-PLC schlägt fehl: Datei nicht gefunden

Es kann vorkommen, daß der Upload der Programmdatei auf die Steuerung fehlschlägt, weil der Pfad oder die Datei nicht gefunden wird.
Dann findet M-PLC u. U. den korrekten Pfad nicht. Unter Kommunikationseinstellungen dann den absoluten Pfad, anstatt dem relativen Pfad angeben:
relativer Pfad: app/
absoluter Pfad: /cfc0/app

nach oben...

---

Probleme mit der FTP-Verbindung

Es kann eine Debug-Ausgabe aller FTP-Kommandos auf die Konsole eingeschaltet werden:

• Konsole im SolutionCenter öffnen
• ftpdDebug=1 ausführen
• Nun werden alle FTP-Befehle auf die Konsole ausgegeben, wenn bspw. von M-PLC eine Datei hochgeladen wird.
• mit ftpdDebug=0 die Ausgabe wieder abschalten

nach oben...

---