Globale oder Lokale Variablen für Hardware und MotionControl IO

[Burkhard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe SPS-Software-Entwickler,

ich soll ein mittelgroßes Projekt für eine Metallbearbeitungsmaschine mit Beckhoff TwinCat entwerfen. Bisher habe ich die Hardware IO, also die Eingänge und Ausgänge von den Reihenklemmen, aber auch die Schnittstelle zur MotionControl (NCI) immer über globale Variablen gemacht.

Ich möchte einen Objekt-Orientierten Aufbau erzeugen, mit mehreren Ebenen.

MAIN --> Maschine --> Antrieb1
MAIN --> Maschine --> Antrieb2
usw...

Mit lokalen Variablen würde ich alle Eingänge und Ausgänge sowie deren Adressen auf der Ebene MAIN deklarieren und müsste diese dann zur Schnittstelle von "Maschine" routen. Dann auf der Ebene des Maschinen-Objektes, würde ich die Ein- und Ausgänge weiter routen zu den Objekten "Antrieb1" und "Antrieb2".

Natürlich könnte ich das Objekt "Maschine" auch weglassen und gleich die Antriebe auf der Ebene MAIN deklarieren. Das Objekt "Maschine" würde ja nur Sinn machen, wenn es auf dieser Ebene noch andere Objekte geben würde.

Mein Gedanke ist nur: mit den lokalen Variablen hätte ich viel mehr Aufwand für die Erstellung der Interfaces und das Routing. Da können auch Fehler passieren.

Mit den globalen Variablen müsste ich diese nur einmal deklarieren, adressieren und könnte sie dann überall in jedem anderen Objekt sofort verwenden.

Ich glaube der Aufwand wäre geringer. Wie ist eure Meinung?

 

[roboticBeet]

Der Ansatz mit globalen Variablen würde in meinen Augen die Wiederverwendbarkeit deiner Bausteine erheblich einschränken. Ich würde stattdessen die Variablen oder Achsschnittstellen direkt im jeweiligen Baustein deklarieren und über das Mapping der IO-Konfiguration dann direkt mit der Hardware verbinden.

 

[Burkhard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für deine Antwort. Aber Wiederverwendbarkeit steht jetzt nicht so weit oben auf meiner Liste der Prioritätein.

 

[Larry Laffer]

Also wenn ich an Objekte denke dann denke ich immer und zuerst an Wiederverwendbarkeit.
Wenn du das nicht tust dann ist es mehr Spielerei und möglicherweise eine Art "Kopierschutz", der das Konstrukt am Ende unübersichtlich macht ...

 

[Burkhard]

Vielleicht verwende ich sie wieder. Aber vielleicht auch nicht. Wiederverwendbarkeit ist jedenfalls nicht meine höchste Priorität.

Der objektorientierte Aufbau soll der Übersicht dienen, damit das Softwaremodell der Anlage und ihrem logischen Aufbau entspricht.

Aber ich bin dennoch dankbar für den Hinweis. Ich werde es wohl so machen, dass ich die Variablen lokal definiere und die Software objektorientiert aufbaue und dann die Variablen von Ebene zu Ebene über die entsprechenden Interfaces weiter leite.

Außerdem gibt es in der IEC1131 ja die sog. Aktionen, die ich als Methoden verwenden kann, so wie es das OOP Modell vorsieht. Objekte mit Methoden und Properties.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht verwende ich sie wieder. Aber vielleicht auch nicht. Wiederverwendbarkeit ist jedenfalls nicht meine höchste Priorität.

Der objektorientierte Aufbau soll der Übersicht dienen, damit das Softwaremodell der Anlage und ihrem logischen Aufbau entspricht.

Aber ich bin dennoch dankbar für den Hinweis. Ich werde es wohl so machen, dass ich die Variablen lokal definiere und die Software objektorientiert aufbaue und dann die Variablen von Ebene zu Ebene über die entsprechenden Interfaces weiter leite.

Außerdem gibt es in der IEC1131 ja die sog. Aktionen, die ich als Methoden verwenden kann, so wie es das OOP Modell vorsieht. Objekte mit Methoden und Properties.

Meiner Meinung nach, ist die Wiederverwendbarkeit ein Bestandteil des objektorierntierten Aufbaus, selbst wenn ich aktuell nicht absehe Gewisse Dinge mehr als einmal zu verwenden, außer es sind irgendwelche Sonderlocken.. dann mache ich die Wiederverwendbarkeit direkt mit.

 

[roboticBeet]

ja die sog. Aktionen, die ich als Methoden verwenden kann

es gibt sogar Methoden, die man als Methoden verwenden kann. Dabei wäre ich aber allerdings etwas vorsichtiger, denn Methoden lassen sich schlecht(er) Debuggen und Beobachten.

 

[Burkhard]

Aber nicht im TwinCat2. Da gibt es nur Aktionen. Die sind doch super, oder?