IO Liste

LordHelmchen

Level-2
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen, ich benötige für ein Test Projekt eine IO Liste aus einer Beckhoff Steuerung. Könnte mir einer eine Liste schicken per xlsx? Ich habe sonst keine Möglichkeit an solche Listen zu kommen. Ich brauche sie nur zu testzwecken mit ein paar Variablen drin Namen und I/O Adresse :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Außerdem: I/O Adressen sind überbewertet. Die spielen bei Beckhoff-Steuerungen eine Nebenrolle und werden automatisch zugewiesen. Seid TC3.1.4024 wird bevorzugt symbolisch Adressiert. I/O-Adressen sind also weitestgehend Geschichte.
 
Mir geht es um die Listen für einen IO Check :) die kann man sich ja irgendwo ausgeben lassen und notfalls wieder importieren. Brauche die für testzwecken für ein macro für Excel

Ich sehe gerade dein Link hilft mir schon sehr gut. Eine original exportierte Datei wäre zu Testzwecken denke ich aber besser
 
Nein, so was gibt es meines Wissens nach nicht. Vielleicht als Drittanbieter-Tool?

Ich weiß nicht, wie ich es erklären soll, vielleicht so:

Das IO-System ist viel flexibler, als man das von anderen Herstellern, wie. z.B. Siemens kennt. Die SPS-Software ist null an die Hardware gebunden. Das heißt jede HW-Konfiguration kann bei gleicher SPS-Software völlig anders aussehen. Das ist eine Stärke von TwinCAT.
Sehr viele Programmierer machen aber den Fehler und legen eine komplette Kopie der IO's in einer GVL an und mappen das ganze dann 1:1 - totale Zeitverschwendung. Siemens-like eben.

Dazu kommt: Ich persönlich brauche keinen extra IO-Check, das macht meine SPS-Software gleich vollautomatisch im Hintergrund bei der Inbetriebnahme. Vielleicht wäre das ein Weg für euch. Das spart eine Menge Zeit. Ist aber auch eine Frage der Architektur.

Vielleicht kennt hier jemand anderes ein Drittanbieter-Tool, oder mal Google oder ChatGPT fragen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Außerdem: I/O Adressen sind überbewertet. Die spielen bei Beckhoff-Steuerungen eine Nebenrolle und werden automatisch zugewiesen.
Für die Listen für eine Inbetriebnahme oder IO-Check müssen die IO aber trotzdem irgendwie eindeutig identifizierbar sein. Vielleicht braucht der Programmierer nicht mehr die Adressen wissen, aber der Elektriker an der Anlage braucht was - der kann nicht schreiben, er hat I* überprüft ...

Ich persönlich brauche keinen extra IO-Check, das macht meine SPS-Software gleich vollautomatisch im Hintergrund bei der Inbetriebnahme.
Interessant. Wie überprüft die Software vollautomatisch die Verdrahtung von Sensoren u.Ä.?
 
Für die Listen für eine Inbetriebnahme oder IO-Check müssen die IO aber trotzdem irgendwie eindeutig identifizierbar sein.
Naja, so wie ein Elektriker halt denkt: Über das BMK und den Anschlusspunkt.

Interessant. Wie überprüft die Software vollautomatisch die Verdrahtung von Sensoren u.Ä.?

Indem die Software die Signal-Erwartung mit dem realen Signal vergleicht und ganz konkret über das Meldungssystem das Problem spezifiziert. Bei der Inbetriebnahme sieht das dann so aus: System in Hand, alle Funktionen eines Objektes (Zylinder, Antrieb usw.) einmal durchprobieren. Wenn das ganze ohne Fehler durchläuft, ist die Inbetriebnahme der Komponente inklusive IO-Check sicher abgeschlossen. Man muss das nur einmal in dem Software-Objekt richtig vorbereiten - das spart einen Haufen Zeit.
Und das Beste ist, wenn später mal ein Sensor kaputt ist, einen Wackelkontakt hat oder ähnlich, kommt gleich die richtige Fehlermeldung. Das spart Maschinenstillstandzeit und qualifiziertes Personal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja, so wie ein Elektriker halt denkt: Über das BMK und den Anschlusspunkt.



Indem die Software die Signal-Erwartung mit dem realen Signal vergleicht und ganz konkret über das Meldungssystem das Problem spezifiziert. Bei der Inbetriebnahme sieht das dann so aus: System in Hand, alle Funktionen eines Objektes (Zylinder, Antrieb usw.) einmal durchprobieren. Wenn das ganze ohne Fehler durchläuft, ist die Inbetriebnahme der Komponente inklusive IO-Check sicher abgeschlossen. Man muss das nur einmal in dem Software-Objekt richtig vorbereiten - das spart einen Haufen Zeit.
Und das Beste ist, wenn später mal ein Sensor kaputt ist, einen Wackelkontakt hat oder ähnlich, kommt gleich die richtige Fehlermeldung. Das spart Maschinenstillstandzeit und qualifiziertes Personal.

Dann sind aber noch doppelte Fehler möglich.
Zum Beispiel wenn bei der Vor-Inbetriebnahme gepfuscht wurde und der Programmierer einfach die Eingänge umgemappt hat, statt sich nach dem Schaltplan zu richten.
 
Zum Beispiel wenn bei der Vor-Inbetriebnahme gepfuscht wurde und der Programmierer einfach die Eingänge umgemappt hat, statt sich nach dem Schaltplan zu richten.
Was für eine Vor-Inbetriebnahme? Alles in einem Rutsch. Ich mache die Inbetriebnahme des ersten Protoyps immer selbst, falsche Verlinkungen falle dabei genauso sofort auf, wie fehlerhafte Verdrahtung und defekte Sensoren.

Ich nehme auch selbst mal das Werkzeug in die Hand bei einem Verdrahtungsfehler. Saubere Dokumentation ist dabei Ehrensache.

Der Elektriker spart sich den IO-Check und ich brauche bei der Inbetriebnahme auch nicht länger - im Gegenteil, ich wage es zu behaupten dass ich mit der Inbetriebnahme sogar schneller bin.
Ab Maschine #2 machen die Elektriker und Mechaniker die Inbetriebnahmen sogar selbst. Und es sind keine 100% gleiche Maschinen. Da übernehme ich nur die Erweiterungen, die es bisher noch nie gab.
Aber, ich denke, das liegt an der grundsätzlichen Architektur, ob das so einfach möglich ist - oder nicht.

Jetzt sind wir aber ganz schön OffTopic.
 
Ich kämpfe auch damit meinen Siemens Kollegen und E-Planern zu erklären, dass mir Adressen egal sind.

IO-Check mache ich aber trotzdem nach E-Plan und Hardware. Entweder mittels TwinCAT XAE über den Hardware-Baum oder TE2000 und EcDiagnose.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für die Listen für eine Inbetriebnahme oder IO-Check müssen die IO aber trotzdem irgendwie eindeutig identifizierbar sein. Vielleicht braucht der Programmierer nicht mehr die Adressen wissen, aber der Elektriker an der Anlage braucht was - der kann nicht schreiben, er hat I* überprüft ...
muss er auch nicht, wir haben uns auch von den Absoluten Adressen gelöst,
das ist ein überbleibsel aus den S5 Zeiten. Braucht kein Mensch.
Naja, so wie ein Elektriker halt denkt: Über das BMK und den Anschlusspunkt.
so reicht es vollkommen aus.

Wie beschrieben kennt es Beckhoff nicht mehr und Siemens will es
eigentlich auch nicht mehr kennen.
Wenn man dann Anlagen hat, die mal mit Beckhoff oder Siemens
ausgeliefert werden, ist die Nachbearbeitung im CAE, Messprotokolle
wesentlich geringer.
 
... Ich weiß nicht, wie ich es erklären soll, vielleicht so:

Das IO-System ist viel flexibler, als man das von anderen Herstellern, wie. z.B. Siemens kennt. Die SPS-Software ist null an die Hardware gebunden. Das heißt jede HW-Konfiguration kann bei gleicher SPS-Software völlig anders aussehen. Das ist eine Stärke von TwinCAT.
Sehr viele Programmierer machen aber den Fehler und legen eine komplette Kopie der IO's in einer GVL an und mappen das ganze dann 1:1 - totale Zeitverschwendung. Siemens-like eben....
Das macht jetzt aber neugierig. Wie sieht denn nun so eine Zuordnung aus? Ausgangspunkt ist ja ursprünglich sicherlich der Schaltplan. Dort gibt es beispielsweise einen Eingang "ENDLAGE_OBEN". Jetzt muss man doch irgendwie, egal ob Siemens oder Beckhoff, der Steuerung bekannt geben, wo sie dieses Signal findet? Mit nur "ENDLAGE_OBEN" kann doch eine Steuerung nichts anfangen? Was verstehe ich hier falsch?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du schreibst jetzt einen FB_Cylinder
Dort deklarierst du einen Ein- bzw Ausgang.
"Endlage_oben AT %I*:BOOL;"
"Vetnil_hoch AT %Q*:BOOL;"
Das können auch ganze Strukturen sein.

Jede Deklarierte Instanz vom FB_Cylinder legt dann diese Ein und Ausgänge im SPS interface an.

Dieses Interface ist eine Liste mit Ein- und Ausgängen die beim Compilern angelegt wird.

Jetzt verknüpft man händisch oder "automatisch" dieses Interface auf die tatsächliche Hardware. (Mappen)

Die der IO-Task kopiert dann den Hardware Status auf das SPS interface bevor der eigentliche SPS-Task aufgerufen wird.
 
... Jetzt verknüpft man händisch oder "automatisch" dieses Interface auf die tatsächliche Hardware. (Mappen) ...
Und das wäre dann so etwas wie eine Adress- oder Hardwarezuweisung? Also, man schreibt erst das Programm mit symbolischen Namen und man mapt oder verbindet erst danach diese Symbole mit Adressen bzw. mit der Hardware? Das wäre gegenüber Siemens doch eigentlich nur eine andere Philosophie. Ob diese aber besser ist? Wie hält man dabei Namenskonventionen ein, also Regeln für die Benennung der Signale? Hat man nach der Programmerstellung wenigstens eine übersichtliche Liste, um die Symbolik zu überbearbeiten? Wie so etwas automatisch ablaufen kann, ist mir ebenfalls ein Rätsel.
 
Das mit den Namen wird schwieriger, wenn einem das wichtig ist.

Die variable heißt dann im Interface z.b.
Main.fbZylinder1.endlage_oben

Automatisches Mappen geht über Pragmas.
Man schreibt im Quellcode dann den Symbolischen Pfad zur Hardware. Das kann z.B. durch einen E-Plan generiert werden.

Das schöne ist, dass der Quellcode trotz unterschiedlichem Hardware Aufbau gleich bleibt. Und das alle benötigten Interface Symbole automatisch erzeugt werden.

PS: Es ist auch möglich zur Laufzeit zu prüfen ob ein Symbol tatsächlich mit der Hardware verknüpft ist.
Ich habe das schon verwendet um Endlagen zu Simulieren falls es physisch keine gibt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab versucht mich mit der KI darüber zu unterhalten. Aber "den" richtigen Unterschied noch nicht gefunden. Wenn ich das richtig verstanden habe geht es darum eine weitere Applikationsschicht zu haben. Das geht bei TIA IMHO ebenso, aber historisch kommt man wohl aus der eher direkten Arbeit mit den IOs.

Man macht sich also eine Hardware und eine Logik GVL, in einem Task werden diese beiden Tabellen dann zueinander gemappt. In diesem Task können die Zuweisung dann geändert oder manipuliert werden.

am Ende finde ich kann man das aber auch alles mit TIA machen wenn man "modern" implementiert.

Aber ich hab eigentlich auch keine Ahnung 😁
 
am Ende finde ich kann man das aber auch alles mit TIA machen wenn man "modern" implementiert.
Wir sind jetzt schon so was von OffTopic, das machte jetzt auch keinen Unterschied mehr.

Klär mich mal auf, ich meine die Entwicklung im TIA bleibt ja auch nicht stehen. Also, ich kann innerhalb eines Funktionsbaustein in der Deklaration STAT eine hardwarebezogene Variable anlegen, dann den Funktionsbaustein mehrfach instanziieren und dann diese eine Variable instanzbezogen mit mehreren verschiedenen Hardwareein- oder - ausgängen verknüpfen?

Also so:

Code:
//Funktionsbaustein
FB_Cylinder
VAR_INPUT
    //Bausteinschnittstelle
EN_VAR
VAR
    //Interne Variablen
    bI_InitalPos     AT%I : BOOL;
    bI_WorkPos     AT%I : BOOL;
    bQ_InitalMove     AT%Q : BOOL;
    bQ_WorkMove     AT%Q : BOOL;

Code:
//Instanzen erzeugen
VAR
    fbCyl1    : FB_Cylinder;
    fbCyl2    : FB_Cylinder;
    fbCyl3    : FB_Cylinder;
    fbCyl4    : FB_Cylinder;

Und jetzt hast Du 8 Eingänge und 8 Ausgänge, die Du frei auf die Hardware verlinken kannst. Kann Siemens das jetzt schon?
 
Zuletzt bearbeitet:
Nein, das kann TIA meines wissens nicht.
Aber ich sehe gerade auch nicht den Vorteil - wahrscheinlich fehlt aber auch einfach die Vorstellungskraft so früh am Morgen 😄

Was gehen würde, wäre über den Instanz-DB
dafür zu vergewaltigten. Fände ich aber mehr als unschön.
 
Zurück
Oben