CL-PlatformSetup – compact-logic-control

Bedien- und Funktionsbeschreibung

Das CL Hardware Setup ist die Werkbank für die Hardware eines CL-Systems. Hier wird dem Controller mitgeteilt, was tatsächlich angeschlossen ist: Welche Pins gehören zum I²C-Bus? Wo sitzt das Display? Welcher Eingang ist ein Taster? An welchem Anschluss hängt ein Sensor?

Das Werkzeug richtet sich bewusst auch an Maker. Man muss nicht jede interne Datenstruktur der Firmware kennen. Entscheidend ist der reale Aufbau auf dem Tisch oder in der Anlage: Bauteil auswählen, Anschluss eintragen, Belegung prüfen und die fertige Konfiguration übernehmen.

Das Setup-Programm ist damit die Brücke zwischen der tatsächlich verdrahteten Hardware und den später im Programmdesigner verwendbaren Hardwarefunktionen.

1. Grundidee des Setup-Programms

Das CL-System trennt zwei Aufgaben bewusst voneinander:

Aufgabe	Zuständiges Programm
Physische Hardware, Bussysteme, GPIOs, Display und reale I/O-Blöcke einrichten	CL Hardware Setup
Steuerungsprogramm erstellen und die vorbereiteten Hardwarefunktionen verwenden	Programmdesigner

Im Hardware-Setup wird beispielsweise festgelegt:

an welchen GPIOs der I²C-, SPI- oder CAN-Bus angeschlossen ist,
welcher Displaycontroller und welche Displayanschlüsse verwendet werden,
welcher reale Sensor, Taster oder Aktor einem Hardware-I/O-Block entspricht,
welche GPIOs frei, belegt, reserviert oder mehrfach verwendet sind.

Einfach gesagt gilt:

Im Setup wird festgelegt, was angeschlossen ist. Im Designer wird festgelegt, was die Anlage damit tun soll.

Der Programmdesigner arbeitet anschließend mit den daraus entstandenen Hardware-Block-Funktionen. Dort muss der Anwender nicht erneut erklären, wie ein Sensor elektrisch angeschlossen ist oder wie sein Bus gestartet werden soll. Er verwendet den bereits vorbereiteten Eingang, Sensor oder Ausgang wie einen fertigen Baustein in seinem Steuerungsprogramm.

Ein Beispiel: Im Setup wird ein Temperaturfühler am I²C-Bus eingerichtet. Dazu werden der I²C-Bus, seine Pins und der passende Sensorblock ausgewählt. Im Programmdesigner kann anschließend mit dem Temperaturwert gearbeitet werden – etwa für einen Lüfter, eine Warnmeldung oder eine Heizungsregelung. Die Verdrahtung wird dort nicht noch einmal eingegeben.

Diese Trennung hat mehrere Vorteile:

Die Hardwarekonfiguration wird nur an einer zentralen Stelle gepflegt.
Der Programmdesigner bleibt übersichtlich und konzentriert sich auf die Programmlogik.
Hardwaredetails müssen nicht in jedem Programm erneut eingetragen werden.
Fehlerhafte oder widersprüchliche GPIO-Zuordnungen können bereits vor dem Programmstart erkannt werden.
Nach einem Hardwareumbau kann die Hardwarebeschreibung angepasst werden, ohne die grundsätzliche Bedienphilosophie des Programmdesigners zu verändern.

Wichtig ist dabei: Ein im Programmdesigner verwendeter Hardwareblock kann nur zuverlässig arbeiten, wenn die zugehörige Hardware im Setup korrekt eingerichtet wurde. Ein I²C-Sensor benötigt beispielsweise einen aktivierten und korrekt belegten I²C-Bus. Entsprechendes gilt für SPI- und OneWire-Geräte.

2. Arbeitskopie, Controller-RAM und Flash

Die Konfiguration durchläuft mehrere Zustände. Das klingt zunächst technischer, als es für die Bedienung ist. Für den Maker ist vor allem wichtig: Ein geänderter Wert im Fenster ist noch nicht automatisch dauerhaft im Controller gespeichert.

2.1 Lokale Arbeitskopie

Während der Bearbeitung werden Änderungen zunächst nur in der Arbeitskopie des Setup-Programms vorgenommen. Das gilt sowohl für die System- und Buskonfiguration als auch für die Hardware-I/O-Blöcke.

Der Wechsel zwischen den Tabs überträgt keine Daten zum Controller und speichert nichts im Flash. Beim Öffnen der Tabs I/O Hardware und I/O Übersicht werden lediglich die Ansichten anhand des aktuellen Arbeitsstandes neu aufgebaut.

Solange noch nichts zum Controller übertragen oder im Flash gespeichert wurde, können die Änderungen vollständig verworfen werden. Man kann also Einstellungen ausprobieren, ohne sofort den funktionierenden Stand im Gerät zu überschreiben.

2.2 Konfiguration im Controller-RAM

Beim Anwenden werden zunächst zwei getrennte Datenbereiche zum Controller übertragen:

die System-, Bus- und Displaykonfiguration,
die Liste der Hardware-I/O-Blöcke.

Diese Daten befinden sich danach zunächst im RAM des Controllers. Ein RAM-Stand ist nicht dauerhaft. Ohne Speicherung im Flash würde er bei einem Reset verloren gehen und durch den zuletzt gespeicherten Flashstand ersetzt.

2.3 Dauerhafte Speicherung im Flash

Erst der Firmware-Aufruf umsr_SystemWriteToFlash() speichert die vollständige Konfiguration dauerhaft. Dabei werden die zuvor in den RAM übertragenen Systemdaten und Hardware-I/O-Blöcke gemeinsam in die aktive Konfigurationsdatei des SPIFFS-Dateisystems geschrieben.

Die Reihenfolge ist deshalb fest vorgegeben:

Gesamtkonfiguration prüfen,
System- und Busdaten in den Controller-RAM schreiben,
Hardware-I/O-Blöcke in den Controller-RAM schreiben,
den vollständigen RAM-Stand in den Flash übernehmen,
den Controller neu starten.

Die Konfiguration wird als zusammengehörige Einheit behandelt. Dadurch wird verhindert, dass beispielsweise ein neuer I²C-Sensorblock gespeichert wird, während die dafür erforderlichen I²C-Pins fehlen.

Als einfache Merkhilfe:

Fenster: Hier wird gerade gearbeitet.
RAM: Der Controller hat die neuen Daten vorläufig erhalten.
Flash: Die Daten bleiben auch nach Ausschalten oder Reset erhalten.
Reset: Der Controller startet alle Hardwarekomponenten sauber mit dem gespeicherten Stand.

2.4 Warum nach Hardwareänderungen ein Reset sinnvoll ist

Das CL-System setzt Hardwareänderungen bewusst nicht vollständig im laufenden Betrieb um. Für jede Hardwarekomponente wären sonst eigene Deinitialisierungs- und Rekonfigurationsfunktionen notwendig. Das wäre aufwendig und könnte zu schwer nachvollziehbaren Zwischenzuständen führen.

Stattdessen gilt die einfache und robuste Strategie:

Nach einer geänderten Hardwarekonfiguration wird die vollständige Konfiguration im Flash gespeichert und der Controller anschließend neu gestartet.

Beim Neustart initialisiert die Firmware alle verwendeten Bussysteme, GPIOs, Displays und Hardwarefunktionen aus einem eindeutig definierten Flashstand. Damit startet das System immer mit einer sauberen und in sich geschlossenen Hardwarekonfiguration.

Ein Reset ist besonders wichtig, wenn GPIO-Zuordnungen, Busparameter, Displayanschlüsse oder Hardware-I/O-Blöcke geändert wurden. Änderungen an reinen Beschreibungsdaten können technisch teilweise auch ohne Reset auskommen; der normale und empfohlene Abschluss bleibt dennoch Anwenden, speichern und neu starten.

3. Aufbau des Fensters

Das Fenster besteht aus vier dauerhaft sichtbaren Bereichen:

Kopfbereich

Der Kopfbereich ist bewusst kompakt gehalten. Er dient in erster Linie zur Orientierung und zeigt den Namen des Werkzeugs sowie den aktuellen Verbindungszustand beziehungsweise die verwendete Verbindung, zum Beispiel den COM-Port.

Die ausführlichen System- und Diagnoseinformationen belegen nicht mehr dauerhaft Platz im Kopfbereich. Sie stehen links unten im Tab Systembeschreibung. Dort können sie bei Bedarf gelesen oder zusammen mit den übrigen Geräteeigenschaften dokumentiert werden.

Registerkarten

Die Konfiguration ist auf fünf Tabs verteilt:

Systembeschreibung
Bussysteme
LCD-Display
I/O Hardware
I/O Übersicht

Nach dem ersten Anzeigen des Fensters wird direkt der Tab I/O Hardware ausgewählt. Dadurch steht die häufig benötigte Bearbeitung der realen Hardwareblöcke sofort zur Verfügung.

Aktionsbereich

Unterhalb der Tabs befinden sich die Aktionen zum Laden, Verwerfen, Anwenden, Neustarten und Starten des Designers. Die Tabs können dadurch die gesamte Fensterbreite für Formulare, Listen und Tabellen nutzen.

Statuszeile

Die untere Statuszeile zeigt sowohl den laufenden Arbeitsschritt als auch den Speicherzustand der Konfiguration. Typische Zustände sind:

Änderungen nur lokal – noch nicht gespeichert
Controller-RAM weicht vom Flash ab – Reset empfohlen
Gespeichert – Neustart erforderlich
Gespeicherte Konfiguration aktiv

4. Tab „Systembeschreibung“

Auf dieser Seite werden die allgemeinen Eigenschaften des CL-Systems festgelegt. Diese Angaben beschreiben das Gerät als Ganzes und gelten unabhängig von einem einzelnen Bus oder Hardwareblock.

Systemname

Der Systemname dient zur verständlichen Identifikation des Controllers, zum Beispiel Anlage 1, Heizungssteuerung oder Prüfstand. Er wird im Kopfbereich angezeigt und erleichtert die Zuordnung, wenn mehrere CL-Systeme verwendet werden.

System-ID

Die System-ID ist eine numerische Kennung des Geräts. Sie kann für die eindeutige Zuordnung innerhalb einer Anlage oder Kommunikation verwendet werden. Der vorgesehene Wertebereich liegt bei 0 bis 255.

Hardwareversion

Die Hardwareversion beschreibt den Hardwarestand des Controllers oder der aufgebauten Plattform. Sie sollte zum tatsächlichen Aufbau passen, weil unterschiedliche Hardwarestände abweichende Möglichkeiten oder Pinbelegungen besitzen können.

Systemfunktion „SPS Run“

Mit SPS Run wird die vorgesehene Systemfunktion aktiviert. Diese Einstellung bestimmt, ob das System im normalen SPS-/Steuerungsbetrieb arbeiten soll.

Startverzögerung

Die Startverzögerung wird in Millisekunden angegeben. Sie gibt angeschlossenen Komponenten nach dem Einschalten oder Reset Zeit zum Hochlaufen, bevor die Firmware auf sie zugreift. Dies kann beispielsweise bei Displays, Sensoren oder externen Controllern erforderlich sein.

Log-Ausgabe

Die Option Log-Ausgabe einschalten aktiviert zusätzliche Diagnoseausgaben. Diese Informationen können bei der Inbetriebnahme und Fehlersuche hilfreich sein und später über das Konfigurationsprogramm abgerufen werden.

Ausgänge beim Systemstart setzen

Bis zu vier GPIOs können beim Start als digitale Ausgänge gesetzt werden. Damit lassen sich definierte Anfangszustände herstellen, bevor das eigentliche Steuerungsprogramm übernimmt.

In diesem Konfigurationsbereich bedeutet GPIO 0: nicht verwendet.

Zeitdienste

Der Bereich Zeitdienste enthält die zeitbezogene Systemkonfiguration:

externe RTC am I²C-Bus verwenden,
RTC-Typ auswählen,
NTP-Dienst eines Routers verwenden,
NTP-Dienst im Access-Point-Modus bereitstellen.

Wird eine externe RTC verwendet, muss auch der I²C-Bus korrekt eingerichtet sein.

Systeminformationen

Links unten auf der Seite stehen die ausführlichen Systeminformationen. Dazu können – abhängig von Firmware und Prozessor – beispielsweise API-, Firmware- und Hardwarestand sowie Speicher- und Prozessorinformationen gehören.

Diese Angaben sind im normalen Arbeitsablauf nicht ständig nötig. Bei der Fehlersuche, beim Support oder beim Vergleich zweier Controller sind sie jedoch sehr wertvoll. Durch die Platzierung auf der Systemseite bleibt der Kopf des Fensters auf kleinen Notebook-Displays frei und übersichtlich.

5. Tab „Bussysteme“

Dieser Tab beschreibt die gemeinsam genutzten Hardware-Schnittstellen des Controllers. Sensoren und Aktoren aus dem Tab I/O Hardware können auf diese Busse zugreifen. Deshalb werden Buskonfiguration und I/O-Blöcke vor dem Speichern gemeinsam geprüft.

Status, Standard und Deaktivieren

Die Busbereiche für CAN, I²C, SPI, RGB-LED und OneWire besitzen eine einheitliche Bedienung:

Standard lädt die vorgesehenen Standardwerte des jeweiligen Busses.
Deaktivieren setzt alle zu diesem Bus gehörenden GPIOs auf 0.
● bereit wird grün angezeigt, sobald mindestens ein zugehöriger GPIO ungleich 0 ist.
○ deaktiviert wird angezeigt, wenn alle zugehörigen GPIOs 0 sind. In diesem Zustand wird der Button Deaktivieren ausgeblendet.

Beim Deaktivieren werden nur die GPIO-Zuordnungen entfernt. Weitere Einstellungen wie Geschwindigkeit, Modus, Pull-ups oder die Anzahl angeschlossener Geräte bleiben erhalten. Dadurch kann ein Bus später leichter wieder eingerichtet werden.

Der Status bereit bedeutet, dass eine Pinzuordnung vorhanden ist. Ob alle für eine konkrete Funktion benötigten Pins vollständig und konfliktfrei eingerichtet sind, wird zusätzlich bei Anwenden geprüft.

CAN-Bus

Der CAN-Bereich enthält:

TX – GPIO für die Sendeleitung,
RX – GPIO für die Empfangsleitung,
Speed – Übertragungsgeschwindigkeit,
Modus – Betriebsart des CAN-Controllers,
Blockdatenserver – aktiviert den zugehörigen Blockdatenserver.

TX und RX müssen zur realen Verdrahtung und zum verwendeten CAN-Transceiver passen.

Typische Anwendungen sind die Verbindung mehrerer Controller über größere Entfernungen, die Kommunikation mit Maschinenmodulen oder die Anbindung robuster Sensor-/Aktorknoten. CAN eignet sich besonders dort, wo elektrische Störungen auftreten können und mehrere Geräte zuverlässig miteinander sprechen sollen. Der optionale Blockdatenserver stellt Blockdaten über diese Verbindung bereit.

I²C-Bus

Der I²C-Bereich enthält:

SCL – GPIO der Taktleitung,
SDA – GPIO der Datenleitung,
Speed – Busgeschwindigkeit,
SDA Pull-up und SCL Pull-up – interne Pull-up-Konfiguration,
Bus suchen – sucht nach erreichbaren I²C-Geräten,
ACK-Prüfung deaktivieren – erweiterte Option für spezielle Geräte oder Diagnosefälle,
Glitch Ignore – Filtereinstellung für kurze Störimpulse.

SDA und SCL müssen beide belegt sein und dürfen nicht denselben GPIO verwenden. Sobald ein I²C-Hardwareblock eingerichtet ist, prüft das Setup diese Bedingungen vor dem Speichern.

I²C ist im Maker-Bereich besonders verbreitet, weil viele kleine Sensoren nur zwei gemeinsame Signalleitungen benötigen. Im CL-System stehen dafür unter anderem Hardwareblöcke für folgende Anwendungen zur Verfügung:

Abstandsmessung mit dem VL53L4CD,
Luftgüte beziehungsweise VOC-Messung mit dem CCS811,
berührungslose Temperaturmessung mit MLX90614,
Bewegungs- und Lagemessung mit dem QMI8658C,
Analogeingänge mit dem ADS1115,
zusätzliche Ein- und Ausgänge über IO-Expander der 9555B- oder TCA9554-Familie,
analoge Sollwerte über DAC-Bausteine wie GP8302 oder GP8403,
Wärmebild-/Infrarotanwendungen mit einem MLX9064x-Sensor.

Mehrere I²C-Geräte können sich SDA und SCL teilen, sofern ihre Adressen zueinander passen. Mit Bus suchen lässt sich prüfen, welche Geräte am Bus antworten.

SPI-Bus

Der SPI-Bereich enthält:

MOSI – Daten vom Controller zum Teilnehmer,
MISO – Daten vom Teilnehmer zum Controller,
CLK – Bustakt,
Speed – Übertragungsgeschwindigkeit,
Mode – SPI-Modus beziehungsweise CPOL/CPHA-Einstellung,
Posttrans – Nachlauf-/Post-Transaction-Einstellung.

Für verwendete SPI-Hardwareblöcke müssen mindestens MOSI und CLK eingerichtet sein. Je nach angeschlossenem Gerät können außerdem MISO und zusätzliche Chip-Select-Leitungen erforderlich sein.

SPI wird verwendet, wenn höhere Datenraten oder eine direktere Geräteansteuerung benötigt werden. Typische Anwendungen sind schnelle Sensoren, Wandler, externe Speicher oder spezielle Erweiterungsmodule. Im CL-System können entsprechende SPI-Sensorblöcke angelegt werden. Auch das LCD-Display und der Ethernet-Controller W5500 können SPI-Ressourcen verwenden. Deshalb muss besonders auf den verwendeten SPI-Host und auf getrennte Chip-Select-Leitungen geachtet werden.

RGB-LED

Der Bereich für adressierbare RGB-LEDs enthält:

GPIO – Datenleitung,
Anzahl – Zahl der angeschlossenen LEDs,
Modell – verwendeter LED-Typ, zum Beispiel WS2812,
Format – Reihenfolge der Farbkanäle, zum Beispiel GRB.

Die Modell- und Formatauswahl muss zum verwendeten LED-Typ passen, damit Farben korrekt ausgegeben werden.

Damit lassen sich beispielsweise eine Statusanzeige, eine kleine Ampel, eine beleuchtete Bedientaste oder eine längere LED-Leiste aufbauen. Im Bereich der Hardware-I/O-Blöcke gibt es dazu Funktionen für einzelne RGB-LEDs, Statusanzeigen, Linien, Fortschrittsbalken, Positionen und Animationen. Die zentrale RGB-Konfiguration legt dabei zunächst den angeschlossenen LED-Typ und die grundlegende Datenleitung fest.

OneWire

Der OneWire-Bereich enthält:

GPIO – gemeinsame Datenleitung,
Anzahl – erwartete Anzahl der Geräte,
Geräte anzeigen – zeigt die gefundenen OneWire-Geräte beziehungsweise deren Adressen.

Wird ein OneWire-Hardwareblock verwendet, muss ein OneWire-GPIO eingerichtet sein.

OneWire wird häufig für einfach verdrahtete Temperaturfühler eingesetzt. Mehrere Geräte können an derselben Datenleitung hängen und werden über ihre eindeutige Adresse unterschieden. Geräte anzeigen hilft dabei, die am Bus gefundenen Teilnehmer den späteren Hardwareblöcken zuzuordnen.

Netzwerkdienste

Hier kann der Modbus TCP Server aktiviert werden. Die Funktion steht ab der dafür vorgesehenen Firmwareversion zur Verfügung. Bei älteren Firmwareständen zeigt das Setup einen entsprechenden Hinweis an.

Modbus TCP eignet sich beispielsweise zur Anbindung an Visualisierungen, übergeordnete Steuerungen, Gateways oder Diagnoseprogramme im lokalen Netzwerk.

Ethernet (W5500)

Der Ethernet-Bereich wird über die Checkbox im Expander aktiviert. Für den W5500 werden folgende Werte eingerichtet:

SPI-Host,
SPI-Geschwindigkeit in MHz,
MOSI,
MISO,
CLK,
CS,
INT,
Reset-GPIO.

Da Ethernet den SPI-Bus beziehungsweise SPI-Ressourcen verwendet, müssen die Zuordnungen mit den übrigen SPI-Geräten abgestimmt werden.

Ein W5500 ist eine gute Wahl, wenn eine kabelgebundene und dauerhaft stabile Netzwerkverbindung benötigt wird – beispielsweise im Schaltschrank oder an einer fest installierten Anlage.

SD-Karte

Der SD-Kartenbereich wird ebenfalls über die Checkbox im Expander aktiviert. Konfiguriert werden:

D0 – Datenleitung,
CMD – Kommandoleitung,
CLK – Taktleitung.

Auch diese GPIOs müssen konfliktfrei zur restlichen Hardwarebelegung passen.

Die SD-Karte kann beispielsweise Messwerte, Protokolle, Rezeptdaten oder andere größere Datenmengen aufnehmen, die nicht nur im internen Flash liegen sollen.

6. Tab „LCD-Display“

Die Displaykonfiguration besitzt einen eigenen Tab, weil sie je nach Interface eine größere Anzahl von Einstellungen und GPIOs benötigt. Die Trennung hält die Seite Bussysteme kompakt, ohne Displayfunktionen zu verstecken.

Display aktivieren

Mit LCD-Display verwenden wird die Displayhardware aktiviert. Ist die Option ausgeschaltet, sind die darunterliegenden Einstellungen deaktiviert.

Interface und Grunddaten

Zu den Grunddaten gehören:

Interface – verwendete Anschlussart,
SPI-Host – verwendete SPI-Einheit bei einem SPI-Display,
Auflösung – Breite und Höhe in Pixeln,
Offset – X-/Y-Versatz des sichtbaren Bereichs.

Die sichtbaren Pinfelder passen sich an das ausgewählte Interface an. Bei einem SPI-Interface werden die SPI-Leitungen angezeigt. Bei parallelen Interfaces erscheinen die benötigten Datenleitungen DATA 0 bis 7 beziehungsweise DATA 0 bis 15.

Speicher, Farbe und Ausrichtung

Folgende Optionen beeinflussen Speicherverwendung und Bildausgabe:

PSRAM – externen RAM für die Displayverarbeitung verwenden,
Farben invertieren – Farbdarstellung invertieren,
X/Y tauschen – Displayachsen vertauschen,
X spiegeln und Y spiegeln – Bildausgabe entlang der jeweiligen Achse spiegeln.

Diese Einstellungen werden typischerweise an die Einbaulage und den Displaycontroller angepasst.

Daten- und Steuerleitungen

Abhängig vom Interface werden unter anderem folgende Leitungen konfiguriert:

MOSI/SDA,
MISO,
CS,
CLK beziehungsweise Write Clock,
DATA 0 bis DATA 7,
bei 16-Bit-Interfaces zusätzlich DATA 8 bis DATA 15.

Die allgemeinen Steueranschlüsse sind:

DC – Data/Command-Umschaltung,
Reset – Displayreset,
Backlight – Hintergrundbeleuchtung,
Power – schaltbare Displayversorgung.

Touch

Über Touch wird ein angeschlossener Touchcontroller aktiviert. Daneben wird der passende Controllertyp ausgewählt. Die dafür benötigten Bus- und GPIO-Anschlüsse müssen ebenfalls zur tatsächlichen Hardware passen.

Datenformat

Für unterschiedliche Displaycontroller und Datenformate stehen folgende Optionen zur Verfügung:

Little Endian,
RGB statt GBR,
2 Bytes tauschen.

Diese Werte sollten nur geändert werden, wenn Bildfarben oder Byte-Reihenfolge des verwendeten Controllers dies erfordern.

Da Displaytreiber und Pins während des Systemstarts initialisiert werden, ist nach Änderungen an dieser Seite ein Reset besonders wichtig.

7. Tab „I/O Hardware“

Auf dieser Seite werden die realen Hardware-I/O-Blöcke verwaltet. Sie ersetzt das frühere separate I/O-Konfigurationsfenster und ist direkt in das Hardware-Setup integriert.

Blockliste

Die linke Tabelle zeigt die vorhandenen Blockplätze. Angezeigt werden:

Block-ID,
Symbol,
I/O-Typ,
frei vergebener Name,
ID-Text,
Beschreibung,
Schaltfläche zum Zurücksetzen des Blocks.

Die vollständige Tabellenzeile wird bei der Auswahl hervorgehoben. Dadurch ist eindeutig erkennbar, welcher Block gerade im rechten Bereich bearbeitet wird.

Block anlegen oder ersetzen

Ein Blockplatz kann per Rechtsklick ausgewählt und über das Kontextmenü mit einer Hardwarefunktion belegt werden. Das Menü bietet die verfügbaren Kategorien und Blocktypen an, zum Beispiel:

digitale Eingänge,
digitale Ausgänge,
analoge Hardwareanschlüsse,
I²C-Sensoren,
SPI-Sensoren,
OneWire-Geräte,
weitere von der API bereitgestellte Hardwareblöcke,
frei, um einen Blockplatz unbenutzt zu lassen.

Ein vorhandener Block kann auf dieselbe Weise durch einen anderen Typ ersetzt werden. Die Löschen-/Zurücksetzen-Schaltfläche am rechten Tabellenrand setzt den betreffenden I/O-Platz zurück.

Dynamischer Einstellbereich

Rechts neben der Liste werden die Einstellungen des ausgewählten Blocks angezeigt. Der Inhalt richtet sich dynamisch nach dem Blocktyp. Zu den möglichen Feldern gehören:

Name,
Einheit,
Anzeige- oder Zahlenformat,
blockspezifische interne Parameter,
GPIO-Nummer,
Beschreibung der Pinverwendung,
interner Pull-up beziehungsweise Pull-down.

Bei den GPIO-Feldern der Hardware-I/O-Blöcke bedeutet 255: nicht verwenden. Dies ist von der Buskonfiguration zu unterscheiden, in der 0 als nicht verwendet behandelt wird.

Abhängigkeit von den Bussystemen

Ein Hardware-I/O-Block beschreibt eine nutzbare Funktion, ersetzt aber nicht die Einrichtung des zugrunde liegenden Busses. Beispiele:

Ein I²C-Sensorblock benötigt gültige SDA- und SCL-Pins.
Ein SPI-Sensorblock benötigt mindestens MOSI und CLK.
Ein OneWire-Block benötigt einen OneWire-GPIO.

Beim Anwenden prüft das Setup die aktiven Real-I/O-Blöcke gemeinsam mit der Buskonfiguration. Bei fehlenden Busanschlüssen oder GPIO-Konflikten wird die Übertragung abgebrochen und der Tab Bussysteme geöffnet, damit der Fehler korrigiert werden kann.

Neben Busgeräten stehen im CL-System auch viele direkt nutzbare Hardwarefunktionen zur Verfügung. Beispiele sind:

normale digitale Eingänge und Ausgänge,
Drehgeber und Drehgeber mit Taster,
Impuls-, S0- und Geschwindigkeitszähler,
Impulszeitmessung,
DIP-Schalter,
Wägezellen-Auswertung über HX711,
PWM- und Frequenzausgänge,
Schrittmotor- und Achsfunktionen,
analoge Eingänge,
RGB-Anzeigen und Animationen,
WiFi- und WiFi-Diagnosefunktionen.

Welche Einstellfelder rechts erscheinen, hängt vom gewählten Block ab. Ein einfacher Eingang benötigt andere Angaben als ein I²C-Sensor, ein Zähler oder eine RGB-Animation. Der Anwender sieht dadurch nur die Parameter, die zu seiner ausgewählten Hardwarefunktion gehören.

Verhalten beim Tabwechsel

Beim Wechsel auf I/O Hardware wird die Liste aus der lokalen Arbeitskopie aktualisiert. Es findet dabei keine Übertragung zum Controller statt. Die Bearbeitung bleibt Bestandteil der gemeinsamen, noch nicht gespeicherten Gesamtkonfiguration.

8. Tab „I/O Übersicht“

Die I/O-Übersicht fasst die GPIO-Informationen aus mehreren Quellen zusammen:

vom Controller gemeldeter Firmwarezustand,
System-, Bus- und Displaykonfiguration,
Hardware-I/O-Blöcke,
erkannte Mehrfachbelegungen.

Zusammenfassung

Im Kopf der Ansicht werden die Anzahlen der GPIOs dargestellt:

Frei,
Belegt,
Konflikte.

Damit ist unmittelbar erkennbar, ob die Konfiguration grundsätzlich plausibel ist oder geprüft werden muss.

Suche und Filter

Die Liste kann über ein Suchfeld nach GPIO, Funktion, Block oder Zuordnung durchsucht werden. Zusätzlich stehen die Filter nur belegte und nur Konflikte zur Verfügung.

Der Button Aktualisieren wertet den aktuellen lokalen Konfigurationsstand erneut aus. Auch diese Aktualisierung schreibt keine Daten zum Controller.

Tabellenspalten

Die Tabelle enthält:

GPIO – Nummer des Anschlusses,
Status – frei, belegt, reserviert oder nicht verfügbar,
Funktion / Verwendung – zugeordnete Hardwarefunktion,
Quelle – Herkunft der Zuordnung,
Zuordnung – genauere Beschreibung des verwendenden Konfigurationselements oder Blocks.

Verwendete, gemeinsam genutzte und konfliktbehaftete GPIOs werden farblich unterschieden. Nicht verfügbare oder durch die Firmware reservierte Anschlüsse werden gedämpft dargestellt.

Konfliktprüfung

Die Übersicht ist nicht nur eine Anzeige. Dieselbe zusammengeführte GPIO-Auswertung wird beim Anwenden zur Validierung verwendet. Erkannte Konflikte verhindern das Speichern, damit keine offensichtlich widersprüchliche Hardwarekonfiguration in Betrieb genommen wird.

9. Aktionen unterhalb der Tabs

Config laden

Mit Config laden wird eine vorhandene *.umsr-Datei ausgewählt und auf den Controller übertragen.

Die *.umsr-Datei ist eine binäre Kopie der vollständigen Konfigurationsdatei, die im SPIFFS-Dateisystem des Controllers liegt. Beim Öffnen einer Geräteverbindung legt das umsrDevice automatisch eine Sicherung dieser Datei im Backup-Verzeichnis des Programms an. Eine Konfiguration kann außerdem an einem ausgewählten Ort als *.umsr-Datei gesichert werden.

Beim Laden wird die vorhandene Flash-Konfiguration direkt durch die ausgewählte Datei ersetzt. Anschließend wird der Controller neu gestartet und das Setup erneut geöffnet. Die normale RAM-Übertragung und ein zusätzlicher Aufruf von umsr_SystemWriteToFlash() sind in diesem Sonderfall nicht erforderlich, weil die aktive Flashdatei unmittelbar ersetzt wird.

Nicht gespeicherte lokale Änderungen werden dabei verworfen. Vor dem Laden erscheint deshalb eine Sicherheitsabfrage.

Hardware neu starten

Hardware neu starten führt einen Reset des Controllers aus und öffnet das Setup anschließend erneut.

Sind lokale Änderungen vorhanden, kann der Anwender wählen:

Änderungen speichern und neu starten,
Änderungen verwerfen und neu starten,
im Setup bleiben.

Ein Reset ohne vorheriges Speichern stellt den zuletzt im Flash gespeicherten Stand wieder her.

Verwerfen + schließen

Diese Aktion verwirft alle noch nicht gespeicherten Änderungen und schließt das Setup. Wurde der Controller-RAM durch einen teilweise fehlgeschlagenen Übertragungsvorgang verändert, stellt ein Reset den gültigen Flashstand wieder her.

Die Funktion ist besonders hilfreich, wenn Einstellungen ausprobiert, aber noch nicht dauerhaft übernommen wurden.

Setup beenden

Setup beenden schließt das Programm. Bei offenen Änderungen erscheint eine Abfrage mit den Möglichkeiten:

speichern und Hardware neu starten,
Änderungen verwerfen und schließen,
Abbruch und Rückkehr zum Setup.

Ist eine Konfiguration bereits gespeichert, aber noch nicht durch einen Reset aktiviert, wird ein Neustart angeboten.

Designer starten

Diese Aktion schließt das Setup und startet den Programmdesigner mit dem zuletzt gespeicherten Konfigurationsstand.

Nicht gespeicherte lokale Änderungen werden nicht stillschweigend übernommen. Der Anwender muss ihr Verwerfen bestätigen. Ist nach einem vorherigen Speichern noch ein Reset erforderlich, wird dieser vor dem Start des Designers ausgeführt.

Anwenden + Reset + Designer

Dies ist der empfohlene Abschluss einer Hardwarekonfiguration. Die Aktion führt den vollständigen Ablauf aus:

System-, Bus-, Display- und I/O-Konfiguration gemeinsam prüfen,
System- und Busdaten in den Controller-RAM übertragen,
Hardware-I/O-Blöcke in den Controller-RAM übertragen,
die vollständige Konfiguration im Flash speichern,
den Controller zurücksetzen,
die Verbindung schließen,
den Programmdesigner starten.

Damit arbeitet der Designer anschließend mit einer gespeicherten und nach dem Reset sauber initialisierten Hardwarekonfiguration.

10. Automatische Prüfungen vor dem Speichern

Vor der Übertragung wird die Gesamtkonfiguration geprüft. Unter anderem werden folgende Fehler erkannt:

Ein I²C-Block ist vorhanden, aber SDA oder SCL ist nicht eingerichtet.
SDA und SCL verwenden denselben GPIO.
Ein SPI-Block ist vorhanden, aber MOSI oder CLK fehlt.
Ein OneWire-Block ist vorhanden, aber der OneWire-GPIO fehlt.
Ein GPIO wird durch mehrere nicht miteinander verträgliche Funktionen verwendet.
Die GPIO-Auswertung kann aufgrund inkonsistenter Daten nicht durchgeführt werden.

Bei einem Fehler wird nichts in den Controller übertragen. Das Setup zeigt die gefundenen Punkte an und wechselt zur Busseite, damit die Konfiguration berichtigt werden kann.

11. Empfohlener Arbeitsablauf

Neue Hardware einrichten

Verbindung zum CL-System herstellen und den Verbindungsstatus im Kopf kontrollieren.
Allgemeine Angaben unter Systembeschreibung eintragen.
Benötigte Schnittstellen unter Bussysteme konfigurieren.
Falls vorhanden, das LCD-Display vollständig einrichten.
Unter I/O Hardware die realen Sensoren, Eingänge und Ausgänge anlegen.
Unter I/O Übersicht freie Pins, Belegungen und Konflikte kontrollieren.
Anwenden + Reset + Designer wählen.
Die vorbereiteten Hardwarefunktionen im Programmdesigner verwenden und daraus die eigentliche Anlagenlogik aufbauen.

Bestehende Hardware ändern

Betroffenen Bus, das Display oder den I/O-Block ändern.
Abhängige Hardwareblöcke und GPIO-Konflikte kontrollieren.
Die vollständige Konfiguration erneut anwenden.
Den Controller neu starten.

Änderungen nur ausprobieren

Solange die Änderungen nur lokal vorliegen, können sie über Verwerfen + schließen rückgängig gemacht werden. Wurde bereits ein RAM-Bereich verändert, aber der Vorgang nicht erfolgreich abgeschlossen, stellt ein Reset den gültigen Flashstand wieder her.

Gesicherte Konfiguration wiederherstellen

Config laden wählen.
Passende *.umsr-Datei auswählen.
Sicherheitsabfrage bestätigen.
Die Datei wird als aktive Flashkonfiguration eingesetzt.
Nach dem automatischen Reset wird das Setup mit dem geladenen Stand erneut geöffnet.

12. Wichtige Hinweise

Änderungen in Eingabefeldern sind zunächst nur lokale Änderungen.
Ein Tabwechsel ist kein Speichervorgang.
System-/Busdaten und Hardware-I/O-Blöcke werden als gemeinsame Konfiguration behandelt.
Erst umsr_SystemWriteToFlash() macht den aus dem RAM übertragenen Stand dauerhaft.
Bei Hardwareänderungen ist der Reset Bestandteil des normalen Arbeitsablaufs.
Busse müssen eingerichtet sein, bevor abhängige Hardwareblöcke zuverlässig verwendet werden können.
In der Bus- und Systemkonfiguration bedeutet GPIO 0 in den entsprechend gekennzeichneten Feldern nicht verwendet.
Bei den GPIO-Feldern der Hardware-I/O-Blöcke bedeutet GPIO 255 nicht verwenden.
Eine *.umsr-Datei enthält die vollständige binäre Gerätekonfiguration und sollte eindeutig zum Gerät beziehungsweise Anlagenstand benannt werden.
Vor größeren Änderungen empfiehlt es sich, den automatisch gesicherten oder manuell exportierten Konfigurationsstand aufzubewahren.

13. Kurzfassung

Das CL Hardware Setup beschreibt, welche Hardware tatsächlich am Controller vorhanden und wie sie angeschlossen ist. Alle Änderungen werden zunächst als Arbeitsstand bearbeitet, anschließend gemeinsam geprüft, in den Controller-RAM übertragen und mit umsr_SystemWriteToFlash() dauerhaft im Flash gespeichert. Ein abschließender Reset sorgt dafür, dass alle Hardwarekomponenten aus einem sauberen, konsistenten Zustand neu initialisiert werden.

Der Programmdesigner baut darauf auf: Er verwendet die im Setup vorbereiteten Hardware-Block-Funktionen für die eigentliche Steuerungslogik, ohne die elektrische Hardwarekonfiguration erneut vornehmen zu müssen.