Objektorientiert arbeiten

[Bensen83]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, wie würdet ihr denn Vorgene, um Objektorientiert bspw ventile anzusteuern?`

nen FB erzeugen und diesen dann mit freigaben ansteuerungen usw instanzieren, oder nen FC mit ner INOUT UDT?

oer sonst wie?

 

[MCerv]

Objektorientiertes arbeiten ist ein super Sache. Bau Dir Module, die Du immer wieder verwenden kannst, das macht die Programmierung einfacher, hast mehr Standard und sparst bei Wiederverwendung jede Menge Zeit. Nur ein mal testen, beim nächsten Einsatz ist die Funktionssicherheit schon gegeben!

Ich greife bei unseren Anlagen immer wieder auf solche Module zurück, z. B. Ansteuerung von Servos, Berechnungsfunktionen oder ganz banale Dinge wie ne ELTAKO-Schaltung.

 

[SoftMachine]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi !
ich denke, wegen der Beobachtbarkeit solltest du auf FB´s zurückgreifen, weil das bei FC´s etwas umständlich wird...
das gilt vor allen Dingen, wenn du EIN Ventil von mehreren verschiedenen FB´s aus ansteuern musst wie bei sich überschneidenden Förderstrecken.

Selbst wenn du viele Ventile benutzt, bei den modernen CPU´s dürften die dann erforderlichen IDB´s kein Speicherproblem darstellen.
Evtl. Multiinstanzen ?

Gruss

 

[bike]

Diese Thema wird doch von den Programmierrichtlinien der Kunden vorgegeben.

Mich würde dennoch interessieren: Was ist der gravierende Unterschied zwischen Aufrufen von fertigen und funktionierenden Bausteinen zu Objekten?
Klar ist mit schon was Vererbung ist, doch ich sehe in der Steuerungstechnik den Vorteil nicht.

Man muss beim Programmieren an die Instandhalter denken.
Ob die bei einer Störungssuche in der Nacht sich um Parent und Child Prozesse kümmern wollen?


bike

 

[MCerv]

Diese Thema wird doch von den Programmierrichtlinien der Kunden vorgegeben.

Bei uns glücklicherweise nicht

Mich würde dennoch interessieren: Was ist der gravierende Unterschied zwischen Aufrufen von fertigen und funktionierenden Bausteinen zu Objekten?

Ist damit nicht das Gleiche gemeint?

Man muss beim Programmieren an die Instandhalter denken.

Möglichst gleich eine vielumfassende Selbstfehlererkennung einbauen und visualisieren, dann haben die Jungs auch keine Probleme!

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei uns glücklicherweise nicht

Dann gehörst du zu den Glücklichen, wir leider nicht.

Ist damit nicht das Gleiche gemeint?

Unter Objekten verstehe ich etwas anderes. Und von einem Parent ein oder mehrere Child anzuleiten, vereinfacht die Störungssuche nicht unbedingt.

Möglichst gleich eine vielumfassende Selbstfehlererkennung einbauen und visualisieren, dann haben die Jungs auch keine Probleme!

Das mit der Diagnose ist richtig und wird auch von jedem gemacht.
Doch alle Probleme kannst du nicht immer und komplett im Programm erkennen und dann eine eindeutige Meldung ausgeben.
Daher ist ab und an ein PG notwendig.
Und um diese Situation für die Instandhalter zu vereinfachen, versuchen wir so einfach und so klar wie möglich zu programmieren.


bike

 

[Sockenralf]

Hallo,

Das mit der Diagnose ist richtig und wird auch von jedem gemacht.

*ROFL*


Du sprichst aber nur für DEINE Firma, oder?

Meine Erfahrung sagt:
Je mehr "Einkauf mitwirk" desto schwieriger "Instandhalt"


MfG

 

[bike]

Hallo,
*ROFL*


Du sprichst aber nur für DEINE Firma, oder?

Meine Erfahrung sagt:
Je mehr "Einkauf mitwirk" desto schwieriger "Instandhalt"


MfG

Ich dachte das sei Standard.
Wir haben den Ehrgeiz auch bei "schneid" an Kosten, Den Jungs von der Instandhaltung solch ein Projekt zu überlassen, mit dem sie leben können.(müssen tun sie eh)


bike

 

[Sockenralf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

dieser Ehrgeiz ist aber lange nicht bei jedem Lieferanten zu sehen --> manche muß man fast dazu zwingen, und dann geht das Gejammere und Geschachere los (weil man ja unbedingt den günstigsten Lieferanten nehmen musste, und nicht denjenigen, zu dem man Vertrauen hat und den man kennt)


MfG (von jemandem, der schon dafür gezahlt hat, daß er die Störungen der SINAMICS-Achsen am Bedienpanel der Anlage lesen kann und nicht nur die Maschiene "stumm" stehen bleibt)

 

[bike]

Also dann sind wir vielleicht doch eine Ausnahme.
Nicht nur ich haben bei einer IBN im Hotel einiges nachgebaut, ohne Berechnung, damit wir mit gehobenen Haupt beim Kunden wegfahren konnten und wieder als Gast zurück kommen dürfen.

Du hast recht, Alles wird auch bei uns nicht mit den Kaufleuten zuvor geklärt.


bike

 

[UniMog]

Also dann sind wir vielleicht doch eine Ausnahme.
Nicht nur ich haben bei einer IBN im Hotel einiges nachgebaut, ohne Berechnung, damit wir mit gehobenen Haupt beim Kunden wegfahren konnten und wieder als Gast zurück kommen dürfen.

Du hast recht, Alles wird auch bei uns nicht mit den Kaufleuten zuvor geklärt.


bike

Wir machen das auch immer so..... muß man ja wenn man weiter Aufträge bekommen will.

Und Störungen sollte man alle anzeigen die man mit der Steuerung erfassen kann....

gruss

 

[Pikador]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo


Objektorientiert geht in S7 leider nicht. FB's oder FC's sind keine Objekte. Eher Module mit oder ohne Gedächtnis. In Codesys wurde was versucht aber nicht wirklich. Bei B&R kann man mit C programmieren, aber Objektorientiert ist es auch nicht. Bei Simotion mit ST sowieso nicht. Obwohl zum Teil von dem großen S was anderes behauptet wird.
Ich finde Beckhoff hat den richtigen weg mit der Integration ins Visual Studio eingeschlagen. Wir haben vor, uns das demnächst genauer anzuschauen.
Bei S7 machen wir bei uns immer so, dass wir eine gemeinsame Datenbasis erstellen, auf die verschiedene Funktionen zugreifen.
Ein Beispiel für ein FU:
Man erstellt ein UDT mit allen Daten die benötigt werden, auf die mehrere Funktionen zugreifen. An jede Funktion wird das UDT als Parameter übergeben. Funktionen werden nach und nach erstellt. Was man so gerade braucht. Nach einer Weile hat man ganz viele, für fast alle Aufgaben.
FU_PB_Recive
FU_GET_F
FU_SET_F
FU_SET_Mmin
FU_SET_Umin
FU_SET_Param
FU_RUN
FU_GET_STATUS
FU_GET_ERROR
Usw.
Wenn man jetzt gaaaaaaaaaaaanz weit rausholt, dann ist das ein möchte gerne Objekt. UDT mit Feldern(nur public) und die Funktionen als Instanzfunktionen die auf die Felder zugreifen. Wichtig ist, dass man auf die Daten nur mit den Funktionen zugreift(Saubere Schnittstelle halten.)

Wir haben letztes Jahr eine Anlage zum Teil mit C# programmiert. So konnte ich mir die Zukunft vorstellen Leider mit TIA Portal hat man uns von Programmieren zum Klickern degradiert. Mindestens ich sehe das so!

PS.
Wir Bauen Maschinen für uns selbst deshalb müssen wir uns mit „fremden“ Vorgaben nicht herumplagen.

 

[Michael.Uray]

Von B&R gibt es übrigens inzwischen schon eine C++ Erweiterung für das Automation Studio, mit welchem man OOP kann. Diese ist allerdings nicht für die breite Masse gedacht und ich denke da muss man erst mit seinem Vertriebsingenieur darüber reden, bevor man so etwas einsetzen kann.

 

[rostiger Nagel]

OOP ist schon bei Siemens möglich, was man da braucht ist allerdings
einen PC mit der Soft SPS 'RTX' und dem ODK. Dann kann in hochsprache
Programmiert werden VB, C# oder C++ je nachdem was man bevorzugt.

Die Einbindung der Hochsprachen Applikation ist dann über 4KB PEW/PAW
Shared Memory 'SMX' oder über der Custom Code Extation Interface 'CCX'
als Windows-DLL oder Realtime-DLL, asynchron oder synchron möglich, das
muss Mann sich so vor stellen das einfach 'SFBs' im SPS Programm mit der
Anwendung abgearbeitet werden.

 

[Chefmech]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mich würde dennoch interessieren: Was ist der gravierende Unterschied zwischen Aufrufen von fertigen und funktionierenden Bausteinen zu Objekten?
Klar ist mit schon was Vererbung ist, doch ich sehe in der Steuerungstechnik den Vorteil nicht.

Wenn du 2 ähnliche Ventile hast, macht Vererbung durchaus Sinn. Du kannst die grundfunktionalitäten in einer Klasse Ventil implementieren, die beiden Ventiltypen erben das Grundverhalten der Parentklasse und implementieren nur noch die jeweiligen Besonderheiten.

Ebenfalls besitzt eine Klasse mehrere Methoden, diese können dann auch teilweise von den ChildKlassen überschrieben werden.

OOP macht auch im SPS Bereich durchaus Sinn, leider hat das die Siemens noch nicht begriffen.

 

[Pikador]

OOP ist schon bei Siemens möglich, was man da braucht ist allerdings
einen PC mit der Soft SPS 'RTX' und dem ODK. Dann kann in hochsprache
Programmiert werden VB, C# oder C++ je nachdem was man bevorzugt.

Ja. Das kenne ich auch. Komplizierter geht es aber nicht

Von B&R gibt es übrigens inzwischen schon eine C++ Erweiterung

Hmm. Wusste ich nicht. Mal schauen.

OOP macht auch im SPS Bereich durchaus Sinn, leider hat das die Siemens noch nicht begriffen.

Sehe ich ganau so!
Aber, nicht nur Siemens.

 

[rostiger Nagel]

Ja. Das kenne ich auch. Komplizierter geht es aber nicht

Was ist den daran kompliziert, Programm in Hochsprache erstellen, DLL auf den Rechner
Spielen und den SFB in Step 7 aufrufen. Das
bekomme sogar ich noch hin.

 

[Pikador]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soft SPS und ODK!

Einfach wäre es:
1. In Simatic Manager in C++ oder anderen Objektorientieren Sprache Bausteine oder ganze Software programmieren.
2. Auf jede belibige S7 CPU übertragen.
3. Fertig!

Mit Soft SPS ist so eine Sache. Wir haben einige Siemens PC Panels wo Soft SPS und WinCC läuft. Zum Teil laufen sie noch unter Windows NT. Wenn einer kaputt geht dan haben wir richtiges Problem. Die alten sind nicht mehr erhätlich und auf den neuen läuft unsere alte Software nicht mehr.
Die Aussage von einem Siemens Mitarbeiter war.
"Das Problem haben viele. Nutzen Sie besser S7 300/400. Die kann man immer tauschen"
Das machen wir jetzt.

 

[rostiger Nagel]

Die Aussage von einem Siemens Mitarbeiter war.
"Das Problem haben viele. Nutzen Sie besser S7 300/400. Die kann man immer tauschen"
Das machen wir jetzt.

Das halte ich aber für einen Irrtum, mit den Konvektionellen CPU's ist es leider
nicht besser wie in der PC Variante auch, wie hier in diesen Thread sehr gut
erkennen kann http://www.sps-forum.de/showthread.php?t=48581
Dort werkelt einer unsere Versiertesten Forums Mitglieder und der Kämpft auch.

Grundsätzlich kannst du ein S7 Programm eines älteren Rechners, auf einen
neuen Draufspielen, der einzigste Punkt den du beachten muß ist das du die
Hardware Konfig auf den neuen Rechner anpassen musst, aber dieses musst
du bei den S7 Steuerungen der 300/400er Baureihe auch.

In Simatic Manager in C++ oder anderen Objektorientieren Sprache Bausteine oder ganze Software programmieren.

Warum sollte man nicht den Hochspracheneditor seiner Wahl nutzen dürfen, das können andere besser wie Siemens.
Hier sind Sie meiner Ansicht nach den richtigen Weg gegangen und zwingen einen nicht einen Editor auf der ziemlich
sicher schnell an Grenzen kommt.

 

[Michael.Uray]

Von B&R gibt es übrigens inzwischen schon eine C++ Erweiterung für das Automation Studio, mit welchem man OOP kann.

Hmm. Wusste ich nicht. Mal schauen.

Hier gibt es ein bisschen darüber zu lesen:
http://www.br-automation.com/cps/rd...catalogue/hs.xsl/products_151728_DEU_HTML.htm
http://www.br-automation.com/cps/rd...es_allowed.htm?caller=news_15527_DEU_HTML.htm

Mich würde dennoch interessieren: Was ist der gravierende Unterschied zwischen Aufrufen von fertigen und funktionierenden Bausteinen zu Objekten?
Klar ist mit schon was Vererbung ist, doch ich sehe in der Steuerungstechnik den Vorteil nicht.

Man muss beim Programmieren an die Instandhalter denken.
Ob die bei einer Störungssuche in der Nacht sich um Parent und Child Prozesse kümmern wollen?

Ich meine die leichte Wiederverwendbarkeit von Programmcode ist unter anderem ein großer Vorteil.
Wenn Leute wie Instandhalter darauf auch arbeiten müssen, dann wird es eher ein Problem. Aber ich nehme an, dass diese Techniker auch mit normalen C schon Schwierigkeiten haben werden.
Ich denke, dass die Vorteile eine OOP nicht einfach in ein paar Worten verständlich gemacht werden können und dass man sich damit genauer beschäftigen muss, um die Anwendungsmöglichkeiten bei seiner eigenen Applikation dafür sehen zu können.