Donnerstag, August 17, 2017

SPS-Technik:


Ich komme aus mehren Welten und beschäftige mich seit 1985 mit so ziemlich jeder Art von Software: Grafik-Verarbeitung (2D/3D), "normalen" Programmiersprachen aller Art, verschiedenster Auszeichnungssprachen, Datenformate, Textanalyse per Software, RegEx, Office usw.

 

Leider muß ich nach nun fast 30 Jahren SPS-Programmierung zusammenfassen

Die meisten SPS-Programmierer sind keine "Programmierer" und "Programmierer" (Informatiker) können eine SPS nicht richtig "programmieren"

Nur jemand der in beiden Welten zuhause ist kann SPSen und die HMI dazu effektiv nutzen und den Anforderungen der Industrie 4.0 gerecht werden.
SPS-Programmierer sind, meiner Erfahrung nach, meist Elektrofachkräfte, die das "SPS-Programmieren" irgendwie mal von Leuten gelernt hatten, denen es auch nicht besser ging - dementsprechend sehen die Programme, Datenhaltung und Programiertechniken dann leider auch aus ...
Oft kommt dabei noch die Verweigerung der Firmen und Programmierer dazu, die Programme "etwas" effektiver zu gestalten als zu S5-Zeiten.


Und was SPS-Programmierer schon gar nicht sind: GUI-Designer

Das sieht man immer wieder an diesen bedientechnischen und Design-Katatstrophen die die meisten Firmen unverständlicher Weise als "Bedienoberfläche"  deklarieren.
Fernab jeder Ergonomie oder "gewohnter" Arbeitsweisen, werden hier dem Benutzer Vorgehensweisen aufgezwungen, die weitab jeder Intuitivität sind.
Selbst das eigene Coporate-Design wird so gut wie nie berücksichtigt (höchstens mal ein Firmen-Logo).
Das dies anscheinend alles eher zweitrangig ist, sieht man auch in den Programmen zur HMI-Erstellung. Oft sind irgendwelche Grafiken mitgeliefert die im Design den Clipart-Sammlungen aus den Anfängen des WWW entsprechen. Wenn dann noch sämtliche Bedienelemente in den Editoren schon andere Verhaltensweisen und vor allem andere Bezeichnungen wie in der restlichen Programmierwelt haben, was soll man dann schon für Ergebnisse erwarten?

Leider müßen auch bei der HMI wieder Programmierer heran, sonst sind nicht alle Möglichkeiten der Geräte nutzbar, oder man muss per Script Funktionalitäten oder gar Bedienelemente "nachbauen", damit erst eine brauchbare Oberfläche entsteht.
Kunstgriffe wie Kurvendarstellung und Tabellen per HTML als Browser-Objekt einzubinden sind nur einige wenige von vielen Zumutungen, halbwegs moderne Oberflächen zu gestalten.

Bei kleineren HMI-Panels fällt dann selbst dies oft weg, so dass die "Logik" der Bedienoberfläche bzw. der Datenübertragung in die Steuerung ausgelagert werden muss.

Hier sind leider oft auch die Arbeitgeber etwas zu optimistisch die meinen:

Ein (einziger) Elektrokonstrukteur kann gleichzeitig die Elektro-Hardware entwerfen (im günstigsten Fall noch die Lagerhaltung für die Bauteile übernehmen), die Elektro-CAD Pläne dazu zeichnen (das gehört ja noch zusammen?), dann die SPSen programmieren (Softwareentwicklung), am besten mit Anbindung an irgendwelche Leitsysteme oder Datenbanken und anschließend noch eine ergonomische, intuitiv zu bediende HMI-Oberfläche gestalten und zu realisieren.
Bei einfachsten, überschaubaren Geräten mag das hin und wieder noch funktionieren, die Realität und die Ergebnisse sprechen erfahrungsgemäß leider oft vollkommen dagegen.
Wenn man schon nicht mehrere Spezialisten einstellen kann, oder möchte, es gibt genügend Firmen die sich z.B. auf reine HMI Anwendungen oder Elektro-Schaltpläne spezialisiert haben.

 

Die Hersteller haben vieles verschlafen ...

Die Problematik in der SPS-Programmierung wird dazu noch verschärft, dass die Anzahl der wirklich brauchbaren Programmierumgebung überschaubar ist und diese sind dann mit der "gängigen" Hardware nicht kompatibel.

Bei der ersten Siemens S7-Version dachte ich mir noch: So etwas Primitives, manche Programierumgebung unter DOS ist besser, vom Amiga ganz zu Schweigen - aber leider wie so oft: man gewöhnt sich an alles ...

Step7 hat sich leider nicht mehr verbessert und die "neuen" sind nicht wesentlich anderst:
Entweder diese schränken den "Programmierer" so stark ein, dass es unzumutbar ist damit zu arbeiten oder die Firmen versuchen bei ihren "hochmodernen" Programmierumgebungen alte Techniken (Räder) neu zu erfinden (gescheitertes Siemens Patent auf den Datentyp "Variant" [EP 2495653 A1], unbrauchbare Versionsverwaltungen die keinen Vergleich zwischen den Versionen zulassen) so, dass eben nichts Nützliches dabei herauskommt, außer eben - viereckige Räder.
Oft ist man mit einem normalen Editor, Makros und einem Präprozessor um Welten schneller am Ziel, als mit diesen "eierlegenden Wollmilchsäuen". Diese können zwar vieles - davon alles garantiert nicht richtig; außer Übersetzen und Übertragen in die Steuerung und das ist oft nicht immer intuitiv durchführbar.
Für die zwei zuletzt genannten Vorgänge würde eine "Commando-Zeilen-Schnittstelle" vollkommen ausreichen.

Das Schlimmste sind dann die Umgebungen bei denen das Marketing gemeint hatte, die etwas, rückständigen (weitab der IEC, kein OOP) Programmierensprachen und ihre unbrauchare HMI in eine Programmoberfläche "quetschen" zu müssen. Im ungünstigsten Fall noch auf dem NET-Framework aufgebaut, damit man jede Art von Performance garantiert nicht auffindet.


Kennen Sie das?

  • Sie haben wieder 8GB (oder mehr)  für eine "Programmierumgebung" heruntergeladen und mehrer Tage lang Software installiert, damit Sie auch noch ältere SPS-Hardware betreiben können?
    Wer mehrere "Programmiergeräte" betreuen muß, kommt um eine VM fast nicht herum; alles andere ist fahrläßige und sinnlose Verschwendung von Arbeitszeit.
  • Wieder ist unbrauchbare Software für HMI dabei, die nicht mal eine Tabelle darstellen kann?
  • Keine Objektorientierung in der SPS oder der HMI?
  • Eine mangelhafte Versionsverwaltung, die als solche nicht mal nutzbar ist?
  • Für jede kleinste Programmänderung, müssen Sie immer noch mehrere MB an Programmdaten (am besten noch per Modem) übertragen, damit es der Inbetriebnehmer vor Ort wieder in Steuerung einspielen kann?
    Also keine Übertragung der reinen Projekt-Differenzen möglich.
  • Mitgelieferte (Technologie-)Funktionen die sich nicht an die eigenen Programmierrichtlinien des Herstellers halten und damit einen unsäglichen Aufwand verursachen, wenn man diese nutzen möchte.
  • Jede Firma (und deren SPS-Programmierer) erfindet Funktionen, wie z.B. Motoransteuerungen usw. immer wieder von Neuem, da es keine wirklich umfassenden, für jeden zugänglichen Funktionsbibliotheken gibt.

    Stellen Sie sich mal vor Sie müßten bei einem neuen PC-Programm erst einmal anfangen die Zeichenroutinen für die Programmoberfläche zu programmieren - das ist SPS-Programmierung, selbst im Jahr 2017.

    Den gesamtwirtschaftlichen Zeitverlust, Geldverlust und die dadurch gelangweilten SPS-Programmierer, wegen diesem Mangel möchte ich mir nicht mal vorstellen ...
  • Kaum eine effektive Art an den eigenen Quellcode zu gelangen, ohne die Programmieroberfläche zu starten oder über viel zu komplexe API-Zugriffe etwas für diesen Zweck selbst programmieren zu müssen?
  • Der Quellcode ist wieder in einem undokumentiertem Dateiformat oder in einer Datenbank abgelegt?
  • HMI-Bilder die nicht als HTML, SVG, XML abgelegt sind, die man dann auch "extern" bearbeiten könnte, sondern undokumentierte Binärdaten?
  • Keine Möglichkeiten moderne Vektorgrafik wie SVG einzusetzen?
  • Keine in der gesamten Programmierumgebung nutzbaren Makros?
  • Keine Möglichkeit das "Programm" aus Vorlagen (Templates, oder Präprozessor) generieren zu lassen?
  • Unbrauchbare Import/Export Formate für Listen aller Art?
    Anstatt als kleinsten gemeinsamen Nenner CSV oder XML zu wählen, darf man sich mit den neuesten EXCEL-Formaten begnügen, deren Dokumentation sich über mehrer Tausend Seiten hinzieht.
    XLS wäre wenigstens noch einfach auszulesen gewesen.
  • Für mehrsprachige HMI-Bedienoberlächen nur eine rudimentäre Software, die nur komplette Sätze 1:1 übersetzt?
  • Wieder keine Möglichkeit den Quelltext, am einfachsten nur per Kommandozeile, zu kompilieren und in die Steuerung zu übertragen, ohne eine "riesige" Programmierumgebung zu öffnen?
  • Wieder keine, trotz aller Werbeversprechen, Industrie 4.0-taugliche Programmierumgebung bzw. Programmiersprache oder HMI ...
  • (Programmier)Anfängerfehler in der CPU-Firmware, die man durch einen Grundkurs in C hätte vermeiden können.
  • CPUs die durch Bedienung des (leider) integrierten Panels ihre Arbeit einstellen
  • Sporadische CPU-Abstürze durch CPU-Firmware Fehler ... und von solchen Geräten hängt nicht gerade selten die Gesundheit und das Leben von Menschen ab (auch wenn für gewisse Firmen, hier der Stillstand der Produktion ein größeres Problem darstellt - das habe ich leider schon live erlebt ...)
  • ...

Die Liste läßt sich beliebig fortsetzen ...

Nur wie kann man dieses Problem lösen?

Ist es allein mit einer Software schon getan?
Die (relativ) fortschrittlichen IEC-Sprachen auf z.B. so etwas "einfach gestricktes" wie eine der neuen Steuerungen der Firma Siemens zu übertragen dürfte wohl aufwendig werden - lösen kann man aber alles.

Eine wirklich gute Software sollte (mindestens) all das oben genannte Probleme beseitigen und am besten kompatibel mit sämtlicher (zumindest den Marktführern) Steuerungshardware sein - am besten hinunter bis zu einem Mikrocontroller ...
Nur wie kann man eine Siemens S1500 z.B. mit CODESYS programmieren?

Wobei die Hardware sich mechanisch stellenweise immer auf dem Weg in Richtung "minderwertig" befindet  - am besten nicht versuchen einen Draht abzuklemmen, sonst fällt alles auseinander ... .
Ist es also auch Zeit an eine richtige Hardware für alle zu denken, die auch nicht in so unzählige Versionen und Varianten aufgeteilt ist, dass dies die Lagermöglicheiten jeder Firma zunichte macht?
Wenn ich Maschinen entwickle, möchte ich mit einer möglichst kleinen Teile-Palette, möglichst viel erreichen und nicht erst eine neue Steuerung suchen müssen, nur weil diese ein paar MB (!!!) mehr Speicher hat, oder nur einige wenige Funktionen mehr beinhaltet.
Warum gibt es nicht einfach eine "komplette" SPS-CPU bei der ich die Funktionen z.B. nur durch die Firmware freischalten kann?

Leider halten auch noch immer noch viele Hersteller an Ihrer rein Zyklischen-Abarbeitung der Programme fest, die die Programme (auch Aufgrund mangelnder CPU-Leistung) langsam macht und dazu noch im ungünstigsten Fall unterschiedliche, nicht immer vorhersehbare (Interrupts) Bearbeitungszeiten verursacht.


Welche Mittel und Resourcen braucht man um diese Probleme aus der Welt zu schaffen?
(das ist wirklich, ganz sicher eine ernsthafte Frage)

Ohne praktikable Lösungen in diesem Bereich wird unser Weg in die Industrie 4.0 keinesfalls effektiv zu begehen sein, auch wenn es die Marketingabteilungen von Firmen wie Siemens dies anderst sehen möchten.


Alle Betroffenen bitte melden!

Kommentar schreiben


Sicherheitscode
Aktualisieren