Programmierung auf dem PC

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Mit einem Debugger arbeitest du gewöhnlich mit Einzelschritten oder Breakpoints.
...

So kenne ich das von CoDeSys. Ich benutze Breakpoints und Einzelschitte jedoch nur in der Simulation. Mit laufender Maschine würde das sicher mit einem schaden enden.

...
Nun zur Programmierung eines PC als Soft-SPS: C++ scheint mir nicht die richtige Sprache. Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen. Damit ist die Speicherverwaltung und der Konstruktor/Destruktor-Mechanismus überflüssig. Mehrfachvererbung verwendet kaum ein C++-Programmierer. Vererbung an sich läßt sich auch in C, ohne ++, mit Structs und Funktionszeigern realisieren.
...

Ich selbst bin in C++ eine Niete und kann da auch nicht wirklich was zu sagen. In C beherrsche ich einige Schweinereien die den Code schlanker aber nicht gerade verständlicher machen.

...
C (auch ohne ++) macht auf mich immer einen leicht kryptischen Eindruck, da man mit kurzen Folgen von Sonderzeichen allerlei nette Effekte bewirken kann.
Ich halte Pascal für leichter lesbar (wichtig, da Steuerungen eigentlich immer von anderen Personen als dem Programmierer gewartet werden müssen) und so finde ich es folgerichtig, daß SCL ziemlich "Pascal-artig" ist.
...

100% ACK

...
Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.
...

Auch hier 100% ACK.
Ich persönlich halte FUP bei Bitverknüpfungen für unschlagbar.
Immer die richtige (passende) Sprache (Tool) für die Aufgabe zu wählen ist schon mal die halbe Miete.

...
Meine Vorstellung wäre, Compiler zur Verfügung zu stellen für:
KOP, FUP -> AWL
AWL->Maschinencode
SCL->Maschinencode
SCL-> AWL
Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt:
AVA->Maschinencode
AVA-> AWL
Der Sinn, den über den Zwischenschritt AWL gehen zu können oder nicht, liegt darin, daß mit AWL-Zwischenschritt der Code auch für nicht Hochsprachenkundige (notfalls) nachvollziehbar bleibt, während ohne AWL-Zwischenschritt optimaler (schneller, kurzer) Maschinencode erzeugt wird.

Ich kenne das ja nur vom hören sagen hier aus dem Forum. Bin mir also bei folgenden Aussagen nicht sicher:

Step7 macht aus SCL erstmal AWL und das würde dann übel und schwer zu lesen sein.

Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.

_____

Ich kenne das auch von µC wenn man sich da einen Code der in C verfasst wurde in ASM anschaut ist das nicht wirklich lesbar.

Einen Compiler zu bauen ist sehr schwer und super viel Arbeit.

Ich denke das sich ST/SCL für die entsprechenden Aufgaben etablieren wird.

Als die SPSen auf den Markt kamen hat auch kein Instanthalter gewust was das ist und was da auf sie zu kommt. Das war zwar weit vor meiner Zeit aber heute ist eine SPS absolut Standart und so wird es mit den "neuen" Sprachen auch sein.

Die Anforderungen steigen und wenn wir da mit halten wollen dürfen wir nicht als Bermse wirken.

 

[Werner29]

Hallo Zottel,

ich denke wie du, dass die Sprache keine Rolle spielt. Das Problem sind die Programmierumgebungen. Und die sind bei C/C++ eben nicht dafür gemacht,
sich an einen laufenden Prozess anzudocken, ohne Anhalten des Prozesses
Werte anzusehen. Mal eben schnell den Code ändern. (Du hast in deinem Beispiel vergessen, dass man auch Daten ändern will, dann wird die Sache meist komplizierter).

Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt:
AVA->Maschinencode
AVA-> AWL

Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings.
Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.

Bernhard

 

[Gerhard Bäurle]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
KOP, FUP -> AWL
...
SCL-> AWL
...
AVA-> AWL
Der Sinn, den über den Zwischenschritt AWL gehen zu können oder nicht, liegt darin, daß mit AWL-Zwischenschritt der Code auch für nicht Hochsprachenkundige (notfalls) nachvollziehbar bleibt, während ohne AWL-Zwischenschritt optimaler (schneller, kurzer) Maschinencode erzeugt wird.

Der AWL Code ist lesbar, aber nachvollziehbar? ... das ist dann ein
riesiger Aufwand.

Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.

Ja, das auf CoDeSys basierende ProSys hat STEP5-AWL
und STEP7-AWL erzeugt, das AWL war auch lesbar.

Aber wie jeder automatisch generierte Code war dieser
AWL-Code nicht wartbar. Wurde von manchmal eher als
Kopierschutz betrachtet.

Keine Kommentare, der Compiler macht manches um-
ständlicher als ein Programmierer - oder so effizient,
dass es auch wieder schwer zu verstehen ist.

Das die Zukunft dem Pascal-ähnlichen ST/SCL gehört,
kann ich mir auch vorstellen.

Viele Grüße

Gerhard Bäurle

 

[harrylask]

Auch wenns eher an der Anfangsfrage vorbeigeht:

Ich bin nun seit 15 Jahren in der Steuerungstechnik tätig und programmiere nun seit gut 5 Jahren unsere SPSn ausschliesslich in C. Anfänglichs skeptisch weil ich dabei doch einiges mehr an Tipparbeit leisten muss (zumindestens meine IDE behandelt C eher stiefmütterleich). Ich habe in dieser Zeit die Sprache C lieben gelernt und möchte es nicht mehr missen. Richtig strukturiert erübrigen sich fast jeder zusätzlicher Kommentar.

Beim Debugging einer S7 (für mich nicht das Maß aller Dinge, aber ein Beispiel, das alle kennen) kannst du die Registerinhalte nach jedem Schritt (Verknüpfung, Rechnung) ansehen.

Das sollte eigentlich jeder Debugger ein Hochsprache auch können. Kommt eigentlich nur darauf an wie man programmiert. Der klassische Debugger einer Hochsprache bleibt ja bei einer Programmzeile stehen und je länger diese ist desto umständlicher das debuggen.

Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.

Was man nicht kennt erschliesst sich nicht jedem sofort, soll heissen, je öfter du damit konfrontiert wirst desto weniger Probleme hast du damit. Ein Programmierer sollte aber mit logischen Ausdrücken wie

A = ((B && C) || D) && E;

eigentlich keine Probleme haben (das sind mE absolute Basics).

Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen.

Viele dieser Objekte werden eh nur einmal beim Start generiert und bleiben dann bis zum Schluss am Leben. Wichtig ist doch das man sich um die Speicherverwaltung nicht mehr selbst kümmern muss. Dass man dazu nicht unbedingt eine Hochsprache verwenden muss (Instanz DBs, lokaler Speicherbereich) ist klar, nur bei den meisten Anlagen mit Siemens SPSn seh ich noch fast immer den klassischen Stil mit absoluten Adressen.

Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings.
Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.

Vererbung, überladene Methoden, Namespaces ... klingt interessant!

Grüsse, Harrylask

 

[pvbrowser]

Wenn man Hochsprachen in der Programmierung von Automationen einsetzen will,
muss man auf folgendes achten:

- Das Wartungspersonal muss sich in der Hochsprache auskennen
- Man braucht eine Bibliothek für die gängigen Funktionen,
die einfach zu nutzen ist.
- Das Grundgerüst des Programms sollte vorgegeben sein.
- Das Lesen und Schreiben der Prozessvariablen,
sollte durch einfache Parametrierung in einer INI-Datei gemacht werden.

Dann könnten die Aktionen die in das Grundgerüst eingesetzt werden wie folgt aussehen:

//---------------------------------------------------------
#include "spslib.h" // hier sind die Klassen und Funktionen der SPS-Bibliothek definiert
#include "spsdefines.h" // hier wird z.B. DRUCK, DRUCK_LIMIT definiert
extern SPSEingaenge eingaenge;
extern SPSAusgaenge ausgaenge;
extern SPSMeldungen meldungen;

void SPSZyklus() // nur hier drin muss der Anwendungsprogrammierer programmieren
// das Hauptprogramm ist fertig vorgegeben
{
eingaenge.lesen();

// Hier kommen die Aktionen
// zum Beispiel
if(eingaenge.variable(DRUCK) > DRUCK_LIMIT)
{
meldungen.printf("DRUCK zu hoch %d Bar",eingaenge.variable(DRUCK)); // zeigt Meldung in HMI an
}

ausgaenge.schreiben();
}
//---------------------------------------------------------

Das kann meines Erachtens einfacher lesbar sein,
als ein konventionelles SPS Programm.

Bei der Programmierung von Level 2 und 3 einer Automation,
wird sowieso eine Hochsprache eingesetzt.
Wenn man auch in Level 1 der Automation,
die gleiche Hochsprache einsetzen würde,
braucht das Wartungspersonal nur in einer Sprache zu denken.
Das wäre meines Erachtens ein Vorteil.

 

[Gerhard Bäurle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei der Programmierung von Level 2 und 3 einer Automation,
wird sowieso eine Hochsprache eingesetzt.
Wenn man auch in Level 1 der Automation,
die gleiche Hochsprache einsetzen würde,
braucht das Wartungspersonal nur in einer Sprache zu denken.
Das wäre meines Erachtens ein Vorteil.

Hallo,

in der Literatur gibt es ja verschiedene Automatisierungs-
pyramiden mit drei, vier, fünf oder gar noch mehr
Ebenen – je nach Hersteller oder Hochschullehrer .

Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
verstehen – damit wir eine einheitliche Basis haben.

Dummerweise ist in Wikipedia bei SCADA zwar von davon die
Rede, dass Automationen verschiedene Schichten
haben, bei den Automationen selbst steht aber nichts
Genaueres dazu.

Viele Grüße

Gerhard Bäurle

 

[pvbrowser]

> Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
> verstehen – damit wir eine einheitliche Basis haben.

- Level 1
Feldebene, physikalische IO's, geschlossene Regelkreise, Echtzeit ...

- Level 2
Modellrechnungen, Optimierung, Sollwerte für Level 1 bereitstellen,
Data Logging, HMI ...

- Level 3
Produktionsplanung, Qualitätssicherung ...

 

[zotos]

Ich habe mir überlegt das man eine pro contra Liste zum diesem Thema anfangen sollte.

Also PC-basierende Automatisierung:
IEC 61131-3 vs. Hochsprachen

Aber das ist viel zu allgemein gefasst.

Also nimmt man eine Hochsprache wie C/C++ mit der kann man ja nun wirklich fast alles machen. Nur man muss eben auch alles selbst machen. Man benötigt um damit arbeiten zu können so was wie ein (auf neudeutsch) Framework. Das Beispiel von pvbrowser ist wohl so ein Grundgerüst das die Anbindung an die Hardware (IOs, etc.), Timer und sonstige Bausteine zu verfügung stellt. Allso alles aufgaben die, die SoftSPSen in Verbindung mit den Entwicklungsumgebungen von Haus aus mit sich bringen.

Solche Grundgerüste für C sind wohl in großer Zahl im Einsatz. Ich selbst habe eine Zeitlang mit einem solchen System gearbeitet. Nun findet man in einem solchen System oft nur schwer den durchblick da die gegebenen Funktionen die man benötigt nicht genormt sind.

Die Programmiersysteme die sich an die IEC 61131-3 anlehnen (also mit zwei zugekniffenen Augen auch Step7) bieten also eine reihe an genormten Funktionen die meist auch gut dokumentiert sind und die "großen" darunter sind auch noch weit verbreited. Dazu kommt das man mit diesen Systemen eben nicht nur eine PC-basierende Steuerung sondern eben auch die klassischen SPSen programmieren kann.

Das Argument das man wenn man auf allen Ebenen der Automatisierung nur eine Sprache benutzen könnte:

...
Bei der Programmierung von Level 2 und 3 einer Automation,
wird sowieso eine Hochsprache eingesetzt.
Wenn man auch in Level 1 der Automation,
die gleiche Hochsprache einsetzen würde,
braucht das Wartungspersonal nur in einer Sprache zu denken.
Das wäre meines Erachtens ein Vorteil.

...kann ich zwar nachvollziehen. Ich denke aber man bei einer SPS immer das passende Tool (Programmiersprache) verwenden sollte.

z.B.:
Bitverknüpfungen (FUP/KOP)
Komplexe Sachen (ST/SCL)
Schrittketten (AS/GRAPH7)
Schnelle trickreiche Sachen (AWL)

Kann man so machen muss man aber nicht.

Das Kredo alles was in der Sprache XYZ geht auch in dieser zu machen halte ich für unpraktisch. Wird aber oft verlangt ;o(


Gibt es eigentlich ein offenes C/C++ "Framework" für die Automatisierung das von verschiedenen Firmen angewand wird?

 

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
Da gibt es x Karten für y Feldbusse.
Dann erwartet man von einer SPS ein gesichertes Anlaufverhalten, remanente Daten, Programmänderung ohne den Prozess anzuhalten, Variablen beobachten ohne den Prozess anzuhalten...
Wenn man das alles gelöst hat, dann kann man mit der Applikation anfangen.
Oder man nimmt eben gleich ein Standardtool.

Bernhard

 

[zotos]

Hallo,

wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
Da gibt es x Karten für y Feldbusse.
Dann erwartet man von einer SPS ein gesichertes Anlaufverhalten, remanente Daten, Programmänderung ohne den Prozess anzuhalten, Variablen beobachten ohne den Prozess anzuhalten...
Wenn man das alles gelöst hat, dann kann man mit der Applikation anfangen.
Oder man nimmt eben gleich ein Standardtool.

Bernhard

Das Echtzeitproblem ist ja nicht Hardware bedingt. Man muss ja nicht zu einem OS greifen das keine Echtzeit unterstützt ;o) Aber wenn man z.B. zu RTLinux greift muss man das ja auch erstmal im Griff haben.

Ich denke auch das der Griff zu einem Standart Tool zur Programmierung wie CoDeSys (mit der CoDeSys-RTE) oder Step7 (mit WinAC/ACCONtrol) oder TwinCAT oder eines der anderen zahlreichen Systeme.

Die von Bernhard Angesprochenen Aufgaben die solche Systeme schon gelöst haben sind nicht gerade trivial.

In der heutigen Zeit wird oft bei der Entscheidung "make or buy" zu kaufen tendiert und in diesen Systemen stecken ja Mannjahre an Entwicklung und man muss diese Dinge oft erstmal auf eigene Kosten entwickeln bevor man damit Geld verdienen kann.

Der Bereich der Automatisierung ist sehr groß es gibt sicher die eine oder andere Anwendung wo es sich lohnt C/C++ anstelle eines SPS-Systems zu nehmen.

Meiner Meinung nach sind die vorhandenen SPS-Systeme so ausgelegt das sie die meisten Anwendungen abdecken können.