Interface PLCnext Target for Simulink
Modelle in wenigen Schritten debuggen
Fortsetzung des Artikels von Teil 1
Gemeinsame Visualisierung von Modellinhalt und Signalen
Wenn ein Modell schon in der Steuerung läuft und alle Tests absolviert hat, erweist es sich häufig als nützlich, sich einen Überblick über die Modellsignale und -ausführung zu verschaffen. Zu diesem Zweck lässt sich entweder der in Simulink vorhandene External-Mode oder das Add-in »Viewer for Simulink« für PLCnext Engineer einsetzen. Beim External-Mode kann der nötige Interface-Code optional in die Modell-Binaries hinein generiert und der External-Mode-Server zur Laufzeit für jedes PLCnext-Programm mit konfigurierbarem Port an- oder ausgeschaltet werden. Der External-Mode läuft also nur bei Bedarf, und es lassen sich Modellsignale anzeigen sowie Parameter anpassen. Der External-Mode hat aber auch Nachteile: Zunächst ist für die Verwendung eine Matlab-Lizenz erforderlich. Außerdem sind viele Signale nur sichtbar, wenn sie vorher konfiguriert wurden. Signale in Referenzmodellen sind gar nicht sichtbar.
Viewer for Simulink stellt eine Alternative zur Verfügung. Über das Add-in für die PLCnext-Steuerungen lässt sich der gesamte Modellinhalt gemeinsam mit den bestehenden Signalen visualisieren. Limitierungen kann der Entwickler konfigurieren. Gleiches gilt für den Inhalt von Referenzmodellen. Ferner können sämtliche Signale verändert oder auf einen bestimmten Wert gezwungen werden. Bisher funktionierte der Viewer for Simulink nur für PLCnext-Programme. Nun ist auch eine Erweiterung auf Funktionsbausteine für die PLCnext-Modelle geplant (Bild 2).
Übersichtliche Darstellung der Fehlerart
Während der Modellentwicklung ist der Umgang mit Division-durch-Null-Fehlern und anderen FPU-Exceptions (Floating Point Unit) ein zeitraubendes Thema. Für Modellentwickler ist der Unterschied zwischen einem kleinen meist Double-Wert und einer Null, der oft durch unerwartete Input-Daten verursacht wird, häufig marginal. Der Prozessor, der durch diese Null dividieren soll, kann damit ein schwerwiegendes Problem haben. Selbst wenn dies nicht zutrifft und als Ergebnis NaN (Not a Number) durch das Modell weiterpropagiert wird, zeigt sich das als kritisch für die Funktionalität des Modells an sich.
| Add-on zur Vermeidung, Analyse und Behebung von Fehlern |
|---|
|
Mit PLCnext Target for Simulink lassen sich die Vorteile modellbasierter Entwicklungsprozesse mit den umfangreichen Möglichkeiten eines offenen Ecosystems für die Automatisierung kombinieren. Ob für HIL-Tests, das Abfangen von Exceptions oder die Überprüfung eines Modells auf der Codeebene: Anwender bekommen Werkzeuge, die das Debuggen einfach und effizient gestalten. Von der Grobansicht bis ins Detail bietet das Add-on Lösungen zum Vermeiden, Analysieren und Beheben von Fehlern. |
In PLCnext Target for Simulink lässt sich das Verhalten in solchen Fällen frei einstellen. Entweder kann die Division ignoriert werden, was zur beschriebenen Propagation von NaN führt. Oder der Fehler wird detektiert und bringt lediglich das Modell/PLCnext-Programm in den Fehlerzustand. In diesem Fall zeigen die Diagnose-Ports des Programms die Fehlerart an, und Entwickler können eine genauere Beschreibung im Handbuch nachschlagen.
Voreingestellte Debugging-Konfiguration im Eclipse-Projekt
Zur detaillierten Untersuchung des Modellverhaltens oder der Fehler ist es sinnvoll, die C/C++-Ebene zu betrachten. Beim Erstellen der PLCnext Library wird automatisch ein Eclipse-Projekt erzeugt, mit dessen Hilfe sich der generierte Code anpassen und neu bauen lässt – etwa um Log-Nachrichten einzufügen oder Fehler zu debuggen (Bild 3).
In den erstellten Eclipse-Projekten ist zudem eine gdbserver-Remote-Debugging-Konfiguration voreingestellt. Sie unterstützt dabei, ein in der Steuerung laufendes Modell in wenigen Schritten zu debuggen. Das Linux-Programm gdb steht Entwicklern mit seinen Werkzeugen in vollem Umfang zur Verfügung. Sie können beispielsweise Breakpoints setzen, um sich das Verhalten und die Variablen an bestimmten Stellen im Detail anzuschauen. Während der Verbindung über den dgbserver lassen sich auch Exceptions und Signals schnell lokalisieren. Im Fall eines Division-durch-Null-Fehlers hält der Debugger an und markiert die Stelle im C/C++-Code, sodass der entsprechende Fehlerblock und die Ursache bestimmt werden können. Statt den Umweg über gdbserver zu nehmen, lässt sich gdb auch in der Steuerung nutzen – ein weiterer Vorteil des Linux-Betriebssystems.
Die Autoren
Konstantin Just
ist Produktmanager im Marketing Software der Business Unit Control Systems von Phoenix Contact Electronics in Lemgo.
Florian Zaffke
ist Entwicklungsingenieur bei Sokratel Kommunikations- und Datensysteme in Norderstedt.
- Modelle in wenigen Schritten debuggen
- Gemeinsame Visualisierung von Modellinhalt und Signalen
Lesen Sie mehr zum Thema
