Objektorientierung + SPS

Werner29

Level-1
Beiträge
297
Reaktionspunkte
117
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich bin Software-Entwickler bei 3S. Wir arbeiten gerade ein einer neuen CoDeSys-Version. In dieser Version wird es echte objektorientierte Erweiterungen geben.
Das heisst:
- ein Funktionsblock kann beliebig viele Methoden haben (die in einer beliebigen IEC-Sprache geschrieben sind).
- ein Funktionsblock kann von einem anderen abgeleitet werden.
- man kann Interfaces für einen Funktionsblock definieren (wie in Java)
Im wesentlichen war's das.
Mich würde eure Meinung dazu interessieren.
Braucht ihr das?
 
Es gibt zwei oder drei Beitäge zu diesem Thema.

Ich denke, gelernte Informatiker freuen sich, viele andere werden sich schwer tun, meine Einschätzung.

Bin gespannt.

Gruß pt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Werner,

persönlich finde ich die Sache recht interessant, aber nach meinen Erfahrungen fehlt den meisten Leuten, die auf dem SPS-Sektor tätig sind, das nötige Hindergrundwissen um damit etwas anfangen zu können. Der "normale" SPS-Programmierer hat eben kein Informatikstudium, sondern ist oft genug Elektriker oder Techniker mit ein paar SPS-Kursen und hat sich dann mehr oder weniger gut in Materie eingearbeitet. Das soll keine Abqualifizierung von irgendjemanden sein, das ist einfach meine Erfahrung.

Auch bin ich nicht so recht davon überzeugt, dass Objektorientierung wirklich der richtige Weg ist um eine SPS zu programmieren.
In den meisten Fällen hat man sowieso keine Zeit sich ausführlich Gedanken um den sauberen Aufbau einer Klassenhirachie etc. zu machen, man kommt an eine Maschine die schon längst fertig sein sollte und die so schnell wie möglich zum laufen gebracht werden muss.
Bei einem Serienprodukt mag das anders aussehen, aber ich habe mein ganzes Berufsleben im Anlagen- und Sondermaschinenbau verbracht und da ist es so.
Ich denke das Ergebniss wäre dann ein Mischprogramm, das einen mehr oder minder OO-artigen Teil hat, der irgendwann mal im Büro entwickelt wurde, und viele Ergänzungen und Erweiterungen die auf die Schnelle von verschiedenen Leuten rein geflickt worden sind.
Es ist natürlich auch eine Frage wie sich die OO im zukünftigen CoDeSys darstellt.

Ein weiteres Thema ist der Resourcenverbrauch, so lange ich eine Soft-SPS auf PC-Basis habe brauche ich mir darum im Allgemeinen nicht so viele Gedanken zu machen. Habe ich aber eine Mittelklasse SPS, wie z.B. eine S7-300, dann sieht die Sache vielleicht schon anders aus.

Vielleicht sehe ich die Sache auch zu negativ?
Jedenfalls bin ich gespannt wie das Ergebniss aussehen wird.
Wann ist mit einer Demo zu rechnen?

Gruß Günter
 
Ich denke das die SPS und die umgebende Automatisierungswelt bestens geeignet ist um mit Objekt orientierter Programmierung (OOP) anzuwenden. Nur muss es sich erst einmal beweisen und in die Gänge kommen. Ein so materielles Umfeld besteht doch aus Objekten die man fassen und begreifen kann. Ich habe mittels c++ versucht die OOP Welt zu begreifen und da werden dann in den Büchern oft Konten oder ähnlich abstrakte Dinge als Einführungsbeispiel gewählt. Ich freue mich auf CoDeSys 3.0 und bin auf die Beispiele zu OOP gespannt.
 
zotos schrieb:
.. materielles Umfeld besteht doch aus Objekten die man fassen und begreifen kann.
Die Abbildung des natürlichen Umfelds auf ein Programm scheitert meiner Meinung nach am ehesten an Mehrfachvererbung:
1. Ich definiere eine Standardpumpe mit Stern-Dreieckanlauf (bzw einen FB der sie steuert)
2. Ich erweitere die Standardpumpe, weil ich einen FU statt Stern/Dreieck habe.
3. Ich erweitere die Standardpumpe, weil ich einen Kompressor habe, der nach Abschalten erst nach Abbau des Drucks wiederanlaufen darf.
4. Jetzt bekomme ich einen Kompressor mit FU. Leite ich den von 2 oder 3 ab?
zotos schrieb:
Ich habe mittels c++ versucht die OOP Welt zu begreifen...
[/quote="zotos"]
C++ kann die Mehrfachvererbung, indem von mehreren Basisobjekten abgeleitet wird. Leider führt das oft zu gewaltigem Chaos.

Daher ist es sehr sinnvoll, den JAVA-Ansatz mit den Interfaces zu verfolgen. In AVA sähe das etwa so aus:

Interface FUcontrolled {
double:maxSpeed;
setMaxSpeed(double);
int rampTime;
setRampTime(int);
void start();
}

Interface KompressorControl {
int waitSecondsAfterHalt;
setWaitSecods(int);
boolean canRestart();
}

class FUcontrolledCompressor extends PumpenSteuerung implements FUcontrolled, KompressorControl{
// diese PumpenSteuerung erbt nun von beiden.
}

Nachteilig ist aber, daß die Methoden beider Interfaces wieder implementiert werden müssen. Geht in eurem neuen CodeSys auch "delegation"? :

class FUcontrolledCompressor extends PumpenSteuerung
{

KompressorControl: myReRunHandler;
FUcontrolled: myStarter;
if (on && myReRunHandler.canRestart) {
myStarter.start();
}
}

Habe ich jetzt einen Kompressor mit Druckschalter oder Druckmessung, so kann ich neue von KmpressorCntrol abgeleitete reRunHandler definieren, die den Neustart nicht nach ener Zeit freigeben, sondern wenn der Eingang vom Schalter da ist oder wenn der Meßwert eine Schwelle unterschreitet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Hr. Werner,

die Kollegen haben ja schon Einiges gschrieben.

zu gebrauchen wäre das schon, drfunfrock wird es freuen, aber es gibt sehr
wenige Doc's in der Branche. Viele haben die Umstellung von S5 zu den
Möglichkeiten der S7 noch nicht gechafft.

Es wird zukünftig etwas leichter, da die Junioren in der Branche meist
in der Ausbildung mal irgendeine Hochsprache getippt haben.

Wie Günter schreibt, wird ein Prog in der Regel zu Hause wenn es gut geht entwickelt
und Vorort wird dann dazu/umprogrammiert. Vorort wird man keine Klasse erweitern,
ableiten oder so, sondern rundherum konventionell dazubasteln bis es läuft.
Auch wenn man fachlich dazu in der Lage wäre es ordentlich zu machen,
es muss schnell - nein ganz schnell gehen und es ist NULL Zeit Vorort und
in dieser Situation fällt man in die alten Praktiken zurück.

3S hat eine gewisse Marktmacht und kann hier sicher einen Meilenstein
setzen, besonders wenn auch die Fa. Beckhoff auf Codesys 3 umstellt.

Wichtig ist jedoch, dass das Eine das Andere nicht ausschliesst.
Also, dass ich mit CS3 auch wie in CS2 programmieren kann.
Es besteht die Gefahr einen zu großen Schritt zu machen.
ZB multiprog - Jemand der Klasse und Objekt und ableiten nicht zuordnen kann steht Anfangs
komplett daneben - die Einstiegshürde ist für diese Programmierer sehr hoch.

Aber ein Schritt in die richtige Richtung!

Gruss
Kurt
 
@Zottel

wie hoch schätzt du den Anteil der SPS-Programierer und Serviceleute "im freien Feld" die mit so etwas wie deinem Beispiel klar kommen?
Ich sehe ein Problem darin so was in eine Maschine einzubauen und dann kommt ein Servicemann mit seinem Siemens-PG unterm Arm und legt die Ohren an.
Siemens hat vor einigen Jahren mal einen Versuch gemacht mit einer Software für die S5 mit Namen "Objekt 5", aber das ganze ist dann ganz schnell wieder verschwunden. Ich weiss auch nicht ob das jemals verkauft wurde.
Aber ich lasse mich gerne eines Besseren belehren, wenn es soweit ist.

Günter
 
Sammelantwort

Ich freue mich über eure Antworten.

@ Zottel
- Mehrfachvererbung ist ausgeschlossen. Es gibt (vorerst) keine delegates. Du könntest Dir in Deinem Beispiel natürlich eine Instanz von einer FuControlled-Klasse anlegen und alle Methoden an die weiterleiten um doppelten code zu vermeiden.

[quote spz]
Ein weiteres Thema ist der Resourcenverbrauch, so lange ich eine Soft-SPS auf PC-Basis habe brauche ich mir darum im Allgemeinen nicht so viele Gedanken zu machen. Habe ich aber eine Mittelklasse SPS, wie z.B. eine S7-300, dann sieht die Sache vielleicht schon anders aus.
[/quote]

Ich bestreite, das OOP höheren Resourcenverbrauch bedeutet. Unter umständen ist der Code vielleicht etwas langsamer, weil ein Aufruf erst zur Laufzeit gelinkt wird, aber grundsätzlich ist das Ziel von OOP doppelten Code zu vermeiden.
Ausserdem darfst Du nicht vergessen, dass es weiterhin kein "new" gibt. Es gibt keine garbage collection, keine aufwändige dynamische Speicherverwaltung.

[quote Kurt]
Wichtig ist jedoch, dass das Eine das Andere nicht ausschliesst.
Also, dass ich mit CS3 auch wie in CS2 programmieren kann.
[/quote]

Das ist klar. Alte Programme sind weiterhin übersetzbar und verhalten sich auch gleich. Es wird niemandem eine Programmierphilosophie aufgezwungen.

[quote Zotos]
Ich denke das die SPS und die umgebende Automatisierungswelt bestens geeignet ist um mit Objekt orientierter Programmierung (OOP) anzuwenden.
[/quote]
Das ist eben auch meine Meinung. Eines der Hauptprobleme bei OOP ist herauszufinden, was gehört zu einer Klasse. In der Automatisierung scheint mir das oft sogar einfacher zu sein, weil die Softwareobjekte oft eine klare Hardwareentsprechung haben. (wie im Zottel-beispiel).
 
Zurück
Oben