[Streitthread] Verwendung von Instanzdaten und Globaldaten

rostiger Nagel

Forums-Knochenbrecher
Teammitglied
Beiträge
16.377
Reaktionspunkte
5.989
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
da ja jetzt sehr häufig Themen mit der richtigen verwendung von Globaldaten und Instanzdaten,
zerpflückt werden, kann ja mit einen Verweis im diesen Thread weitergestritten werden.



siehe auch:
http://www.sps-forum.de/showthread.php?t=41580
http://www.sps-forum.de/showthread.php?t=42841
http://www.sps-forum.de/showthread.php?t=38263&highlight=instanzdaten



PS. ein Tip, mann könnte sich auf seinen Desktop einen icon mit einen link
zu diesen Thema anlegen und sofort loslegen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wolln wir für diesen "Streit"thread erstmal klären, wovon wir reden?

Mein Standpunkt gilt für Automaten, die Einzelmaschinen darstellen. z.B. Förderanlagen, Palettierer (kein Roboter), Dosierer, Kartonierer, Handlings, Schlauchbeutelverpackung, etc. Typisch sind 300er CPU, Programmgrößen bis 128kB, Flexible-Panels.

Operandenvorrang Symbol im SPS-Programm und symbolische Anbindung der HMI-Variablen.

Nachtrag: Struktur des Programms ablauforientiert. Beispiel kontinuierlich laufender Kartonierer: es gibt einen übergeordneten FB namens "Kartonierer", in dem die für die verschiedenen Stationen global bedeutsamen Signale gehalten werden, wie z.B. Schieberegister, Maschinengeschwindigkeit und Winkelstellung. Von dort aus werden Untereinheiten wie Leimung, Einschub, Einleger, Ausschleusung etc. aufgerufen. Den Gegensatz zur ablauforientierten Programmierweise sehe ich in der aufgabenorientierten Programmierweise: Indizien dafür sind Bausteine, die z.B. für Flankenerkennung zuständig sind, im Falle des Kartonierers ein Extrabaustein, der dafür zuständig ist, sämtliche Nockensignale zu erzeugen. Mein Programmierstil ist NICHT, einen Baustein zu haben, der Nocken für Leimung, Ausschleusung, Kartonabzug etc. erzeugt, sondern dem jeweiligen Baustein das Winkelsignal zuzuführen und in dem jeweiligen Baustein die Nocke für diese jeweilige Teilfunktion zu erzeugen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das, worüber wir streiten, ist einfach ein Mangel bei Siemens STEP7.

In STEP7 gibt es einfach nur STAT variablen (VAR in SCL).
In IEC61131-3 gibt es VAR, und dazu auch VAR_EXTERNAL und VAR_GLOBAL. Wenn ich es richtig verstanden habe, dann kann man VAR_EXTERNAL deklarieren in ein FB, wonach man diese adressen ausserhalb von der FB mit VAR_GLOBAL daten beschreiben kann.
Z.B.:
"Motor1".externvar1 := globalvar1 ;

Also, was zu tun wenn es diese Funktionalität einfach nicht gibt.
Soll man sich selbst einschränken und andere Wege finden ? Die Mehrheit scheint so zu meinen.
Oder einfach die Daten direkt übertragen, und dann eine gewisse Disziplin einhalten ? Ich erlaube mich selber die daten zu verwenden als ob sie VAR_EXTERNAL sind.
 
... IEC61131-3 ...

Das war die Norm die keiner exakt einhällt, oder? *ROFL*
Das nichteinhalten können auch Andere!

Ich habe noch nie jemanden gesehen, der ein komplexes Programm von SIEMENS nach Rockwell, OMRON, Schneider, u.s.w. 1:1 umgesetzt hat. also bitte, die IEC61131-3 ist letztendlich reines Wunschdenken. Gut ist, das es bei vielen sehr ähnlich ist, aber nicht 1:1 halt!
 
Ich habe noch nie jemanden gesehen, der ein komplexes Programm von SIEMENS nach Rockwell, OMRON, Schneider, u.s.w. 1:1 umgesetzt hat. also bitte, die IEC61131-3 ist letztendlich reines Wunschdenken. Gut ist, das es bei vielen sehr ähnlich ist, aber nicht 1:1 halt!

Hallo,

die Portabilität ist nicht Inhalt der EN 61131-3.

In der 61131-3 sind nur die einzelnen Programmiersprachen
festgelegt und welche Elemente die haben müssen. Wie das
das die einzelnen Hersteller umsetzen, bleibt denen überlassen.

Die PLCopen hat zwar mal versucht, dass mit dem sogenannten
PORTABILITY Level in den Griff zu bekommen, aber ich weiß
nicht, was der aktuelle Stand dieser Bemühungen ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe noch nie jemanden gesehen, der ein komplexes Programm von SIEMENS nach Rockwell, OMRON, Schneider, u.s.w. 1:1 umgesetzt hat. also bitte, die IEC61131-3 ist letztendlich reines Wunschdenken. Gut ist, das es bei vielen sehr ähnlich ist, aber nicht 1:1 halt!

IEC ist so ein Konstrukt, dessen Sinn sich nicht jedem erschließt. Mir auch nicht.

Also ich hatte schon das Vergnügen eine Maschine, die ich mit einer 840D entwickelt habe, eine neue Steuerung Fanuc und dann Bosch/Indramat zu verpassen.
Doch ich war so klug? nicht das Siemensprogramm um zusetzen, sondern vernünftig die Besonderheiten jeder Steuerung zu berücksichtigen und neu zu schreiben.

Ich denke jede Steuerung soll ihre Besonderheiten haben, sonst genügt ja eine Steuerung.

Also es lebe die Vielfalt.


bike
 
Zurück
Oben