IO Liste

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber ich hab eigentlich auch keine Ahnung

...

Klär mich mal auf

ob das genau so geht müssen dir anderen sagen. Wie gesagt suche ich noch dem Killer Feature.

 

[Glon]

Du Deklarierst deine Instanzen von deinen FBs (Zylinder, Ventil, Analogsensor) und deine IO-Liste baut sich selber.
Zusätzlich kannst du deine Hardware wie wild tauschen ohne das sich das PLC Projekt ändert.

Deine SPS ist zu schwach? Einfach andere rein selbes Projekt aufspielen.

Drei SPS Instanzen auf einem IPC mit selber Hardware laufen lassen? Kein Problem.

Durch die Abstraktionsschicht kann man da sehr viel machen.

 

[roboticBeet]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist imho ein Killer Feature. Ich versuche es auch nochmal zu erklären. Angenommen, du möchtest einen wiederverwendbaren FB für einen Druckluftzylinder erstellen, der über ein 5/2-Wegeventil angesteuert wird und zwei Endlagensensoren hat.

Für die Umsetzung im TIA Portal siehst du dann in der Bausteinschnittstelle VAR_IN zwei boolesche Eingänge vor, an welche du eine absoluten Eingangsadressen der Sensoren hängst. Gleiches für die Zylinderspule an VAR_OUT. Die Ein- und Ausgangssignale kannst du nicht direkt im FB deklarieren und benennen, da dann der Baustein nicht mehr wiederverwendbar ist.
Bei diesem Vorgehen kann jedoch deine Bausteinschnittstelle schnell unnötig groß werden, wenn du andere Feldgeräte mit mehr IOs hast und diese IOs nicht in einem UDT oder so sortierst. Noch deutlicher wird das Problem, wenn du den Zylinder FB in einem anderen FB verwendest, der auch wiederverwendbar sein soll, weil der FB bspw. für eine gesamte Prozessstation ist. Dann musst du "unnötig" durch den FB die IOs händisch durchschleifen. Man stelle sich das über noch mehr Ebenen vor.
Gleichzeitig fehlt dir die Information, ob die Bausteinschnittstelle auch korrekt verschaltet wurde. Man kann zwar im TIA Portal seit kurzem mit GetSymbolName() den Symbolnamen an einer Bausteinschnittstelle auslesen. Das funktioniert aber bei kaskadierten FB (Prozessstation -> Zylinder) nur dann sinnvoll, wenn ich auch an allen Stellen das prüfe. Nur im Zylinder macht es nur bedingt Sinn, da ja innerhalb der Prozessstation wahrscheinlich eine Verschaltung vorhanden ist, der Prozessstations-FB aber vielleicht die nötigen IOs für den Zylinder nicht von außen angebunden hat.

Bei TwinCAT / Codesys funktioniert das, wie bereits erwähnt, komplett anders. Sinnvollerweise deklarierst du die nötigen IOs (bspw. Ventilspule und Endlagenschalter) direkt in deinem Zylinder-FB. Der Zylinder-FB ist komplett wiederverwendbar und man muss die IOs nicht eventuell durch mehrere FB-Ebenen durchschleusen. Das hält deine Bausteinschnittstelle auf das Wesentliche beschränkt. Beim (späteren) Mapping der IOs in der Hardwarekonfiguration sieht man alle im Programm verwendeten Ein- und Ausgangssignale und hat damit gleich eine Art "Checkliste", ob man auch alles verbunden hat.
Auch die Prüfung, ob die definierten IOs gemappt sind, liefert eine echte Aussage zum Verbindungszustand zur Hardwarekonfiguration und nicht nur, ob es eine Beschaltung innerhalb des SPS Programms gibt.
Wenn man Serienmaschinen mit immer gleichem Hardwareaufbau hat, kann man sogar die gesamte Hardwarekonfiguration automatisieren und im SPS-Programm angeben, dass bspw. die Ventilspule am Digitalausgang Nr. 5 von der dritten DQ-Karte an der RIO-Station 4 angeschlossen ist.

Thema Adressen: Beim Mapping in TwinCAT und Codesys werden tatsächlich auch Adressen im Hintergrund verwendet. Darum muss man sich als Programmierer aber überhaupt nicht kümmern, da sowohl die verwendeten Adressnummern als auch die Zuordnung dann automatisch im Hintergrund von TwinCAT gemacht wird. Das macht es sehr komfortabel. Ein BMK oder ein sprechender Name wie St010_Cylinder5_SensorWorkPos ist halt viel besser lesbar als I5.6

 

[roboticBeet]

Nachtrag: Diese Form der IO-Konfiguration bekommt beim objektorientierten Programmieren eine noch wichtigere Bedeutung. Dann deklarierst du den FB nur noch im Bereich VAR des übergeordneten FBs und rufst den FB-Rumpf mit seinen VAR_IN, VAR_OUT und VAR_INOUT möglicherweise in deinem Programm gar nicht mehr auf. Damit hast du diese Schnittstellen (VAR_IN, VAR_OUT usw.) auch nicht mehr zur Verfügung. Stattdessen ruft man dann bspw nur noch Methoden wie ToWorkPos() auf, ggf. ohne irgendwelche weiteren Parameter.

 

[asci25]

Wenn man es erst mal verstanden, will man nichts anderes mehr. Nachdem ich 15 Jahre parallel mit Siemens und Beckhoff gearbeitet habe, habe ich angefangen alle meine Kunden von Beckhoff zu überzeugen und heute mache ich fast gar nichts mehr mit Siemens-Steuerungen. ALs Ex-Siemensianer bin ich zwar nach wie vor von Siemens überzeugt, aber auf dem Gebiet der Automatisierung ist Beckhoff halt immer mindestens 10 Jahre voraus. Und überzeugt gleichzeitig mit wahnsinniger Performance.

Und jetzt kommt PLC++. Die sind einfach nur Irre. https://www.beckhoff.com/de-de/produkte/automation/twincat-plc/

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir hatten eine Live Vorstellung von PLC++ das ist schon wahnsinn.
Dadurch hat Beckhoff die Kontrolle über die IDE und den Compiler und muss sich nicht mit Gegebenheiten von Codesys rumschlagen. Gerade das ganze XML Zeugs fliegt aus den Dateien raus. Da freut sich die Versionsverwaltung.

 

[Mrtain]

Danke @roboticBeet.
Das System gefällt mir.
Was ich noch nicht ganz verstanden habe, ist wie das mapping der tatsächlichen IOs mit dem Symbolen funktioniert.
Das der Eingang des Zylinders auf Karte xy, Eingang n liegt, muss noch händisch passieren(sofern man keine Standardbelgung hat) oder?

PS: GetSymbolName hat auch den Nachteil, dass es sich auf die Zykluszeit auswirkt. Also nicht, was man jeden Zyklus machen sollte

 

[asci25]

wie das mapping der tatsächlichen IOs mit dem Symbolen funktioniert.

Über einen komfortablen Mapping-Dialog. Das Ganze ist Bidirektional, Du kannst von der Hardware auf die Variable verknüpfen oder von der Variablen aus auf die Hardware.

PS: GetSymbolName hat auch den Nachteil, dass es sich auf die Zykluszeit auswirkt. Also nicht, was man jeden Zyklus machen sollte

Das Mapping ist zwar symbolisch, aber nicht wie Du denkst. Da das symbolische Mapping später kam, wäre es ja sinnfrei, wenn es sich auf die Performance negativ auswirken würde. Nein, dass hat Beckhoff sicher anders gelöst.

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke euch für die zahlreichen Erklärungen,so ganz habe ich noch kein Fuß im Thema. Wenn ihr also Literatur oder Tutorials zum Thema habt gerne her damit.

Leider gibt bei Codesys und den Arbeits PCs ein Kompatibilitäts Problem mit Codemaster. Das bekomme ich auf 3 Arbeits PCs nicht zum laufen.

 

[Mrtain]

Ich habe vor Siemens Jetter programmiert (basiert auch auf codesys). So manches vermisse ich wirklich

 

[asci25]

Danke euch für die zahlreichen Erklärungen,so ganz habe ich noch kein Fuß im Thema. Wenn ihr also Literatur oder Tutorials zum Thema habt gerne her damit.

Leider gibt bei Codesys und den Arbeits PCs ein Kompatibilitäts Problem mit Codemaster. Das bekomme ich auf 3 Arbeits PCs nicht zum laufen.

Wichtig: Die Erklärungen beziehen sich nur auf TwinCAT, nicht Codesys. TwinCAT ist zwar ein Codesys-Derivat, aber im Bereich der Hardwareanbindung unterscheidet es sich fundamental.

 

[Stadtranduser]

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 ...

IMO ist es schneller, diese Liste aus Eplan zu generieren. Idealerweise hat sich der Programmierer beim Mapping dran gehalten.

 

[PN/DP]

Auf jeden Fall irgendwie eine vollständige Liste machen, zum abhaken.
Von wegen "das SPS-Programm macht den IO-Check automatisch mit und meldet alle Fehler": das kann ich mir nur bei Mini-Maschinen mit höchstens 100 IO-Punkten vorstellen. Ohne einen IO-Check vorher würde ich keine Knöpfe auf dem HMI drücken, geschweige denn Auto einschalten... Elektriker können unvorstellbare Fehler....

 

[Stadtranduser]

Elektriker können unvorstellbare Fehler....

Was kennst Du denn für Leute?

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auf jeden Fall irgendwie eine vollständige Liste machen, zum abhaken.
Von wegen "das SPS-Programm macht den IO-Check automatisch mit und meldet alle Fehler": das kann ich mir nur bei Mini-Maschinen mit höchstens 100 IO-Punkten vorstellen. Ohne einen IO-Check vorher würde ich keine Knöpfe auf dem HMI drücken, geschweige denn Auto einschalten... Elektriker können unvorstellbare Fehler....

Wie ich schon schrieb, das ist alles eine Frage der Architektur. Wenn man allerdings noch wie vor 30 Jahren arbeitet ...

Der Thread ist sowieso irgendwie durch, was soll's.

Ich hatte während der Corona-Zeit eine recht große Maschine in China in Betrieb genommen, ohne jemals vor Ort gewesen zu sein. Nur über den Teamviewer aus dem Büro - wegen den Reisebeschränkungen.
Die Servosysteme haben mehrere Tonnen bewegt, große Schleppketten unterstützt und geführt. Allein das Substrat wog 1,5 Tonnen. Die Beschichtungseinheit musste im Schleusenberech von einem Antrieb auf einen 2-Achsrahmen durch eine Schleuse übergeben werden. Alles im Bereich der Nano-Beschichtung, mit Hochvakuumpumpen, Prozessgassystem und Plasmaerzeuger. Und völlig ohne zusätzlichen EA-Check. Mit dem Elektriker habe ich über Notepad gechattet und losgeschickt, wenn mir ein Signal gefehlt hat. Das lief völlig problemlos durch. Die Software selbst habe ich im digitalen Zwilling vorab getestet.
Ich habe die Datenpunkte nicht gezählt, das waren aber definitiv über 5000.

Jeder Fehler hätte schnell einen Schaden von mehreren 100000 Euro verursachen können. Zum Beispiel 25 Turbomolekularpumpen zu je 25000 Euro. Ein Druckstoß und die fliegen auseinander.

Sonst bin ich eigentlich eher vor Ort, zumindest für die Inbetriebnahme der funktionalen Sicherheit und der grundlegenden Tests.

 

[the_muck]

klingt ja gut... Aber wie macht man denn die Überprüfung ob Taster A nun Band A einschaltet. In der Steuerung sieht alles normal aus, aber A wurde im Tableau auf B geklemmt. Da muss ich doch eine Art IO Check machen und auf Plausibilität prüfen? Manche Dinge kann man ja in der Software, IMHO mit sehr viel arbeit logisch abfangen. Aber alles nicht. Ähnlich mit Leuchten. Ist ja schön wenn der Eingang kommt aber ist nun rot oder grün an? Wie testet man das nur remote?

Bei uns sind 50 IOs schon viel. Bei einem bekannten sind 3000 IOs normal.

 

[roboticBeet]

Hält dich ja niemand von ab einen IO-Test zu machen. Das mache ich auch. Die Liste generiert man aber am besten nicht aus der SPS-Symbolik sondern direkt aus EPLAN.

In deiner Hardwarkonfiguration siehst du den aktuellen Signalzustand an allen IO-Kanälen und kannst auch forcen. Der Signalzustand wird als als Sparkline angezeigt und ermöglicht dir den Signalverlauf über die letzten (ca. 30?) Sekunden nachzuvollziehen.

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hält dich ja niemand von ab einen IO-Test zu machen.

Es ging ja darum, das man durch moderne Implementierung sich das sparen. Und da Frage ich mich halt wie.

Ähnlich ja bei einem Zylinder den ich Software technisch abfangen kann. Aber wenn Endschalter und Schläuche verdreht sind müsste ich ja weitere Mechanismen implementieren...

Mich interessiert es gerade einfach da ich nächstes Jahr das erste Codesys Projekt mache. Da finde ich es spannend was wirklich anders und "beste practice" ist.

 

[asci25]

Mich interessiert es gerade einfach da ich nächstes Jahr das erste Codesys Projekt mache. Da finde ich es spannend was wirklich anders und "beste practice" ist.

Völlig losgelöst von der Plattform wäre meine Rat:
1. Denke objektorientiert, suche Dir reale Objekte und baue geschlossene Funktionseinheiten drumherum. Zersplittere die Funktionen nicht all zu sehr. Ein Objekt kann sein: Ein Antriebsstrang mit allen IO-Signalen, Einstellungen und eigener HMI-Schnittstelle. Mit ein paar zusätzlichen Parametern kann ein Zylinderbaustein auch einen einfachen Motorantrieb oder einen Wendeantrieb steuern. Das vereinfacht einiges.
2. Versuche an alle Möglichkeiten zu denken, die schief gehen können und den Ablauf stören. Baue von Anfang an für jede Möglichkeit eine Diagnosemeldung ein. Versuche nicht dass nachträglich zu implementieren. Da vergisst man die Hälfte.
3. Denke modular. Baue eine einen Funktion universell und implementiere nachträglich die Schnittstelle zur Hardware. Wenn Du das ganze umschaltbar gestaltest, kannst Du z.B. einfach den verwendeten Antriebsregler umschalten, ohne die Software zu tauschen, Also heute ein Bosch- morgen ein Lenze- und übermorgen Schneider-FU. Ich kapsele die Hardware-Schnittstelle, so kann ich die zur Laufzeit umschalten. Die HMI-Schnittstelle bleibt dabei immer gleich.

Ähnlich ja bei einem Zylinder den ich Software technisch abfangen kann. Aber wenn Endschalter und Schläuche verdreht sind müsste ich ja weitere Mechanismen implementieren...

Ich denke, hier gibt es ein Missverständnis. Ich sehe keine Notwendigkeit einen separaten IO-Check vor der eigentlichen Inbetriebnahme zu machen. Wenn die Architektur stimmt, kann man das vom HMI aus machen. Natürlich muss man jede einzelne Funktion auf Richtigkeit einmal überprüfen, also ob der Zylinder in die richtige Richtung wirkt und ob auch der richtige Antrieb läuft. Nur, wenn das auch gleich der Elektriker oder Mechaniker mit machen kann, und dabei schon die Inbetriebnahme erfolgt, ist das enorm entlastend. Dann kannst Du Dich auf die eigentliche Herausforderung konzentrieren. Der Elektriker wird es Dir auch danken, weil der sich nicht durch die IDE wühlen muss.

Die grundlegende Architektur entscheidet massiv über Top oder Flop. Und man wird eine doofe Architektur nur schwer wieder los.

 

[PN/DP]

Also gemacht werden muss der Check schon, nur nicht von dem teuren Programmierer, weil der sich ja schon auf moderne Implementierung konzentriert und den Elektrikern bei Checklisten nicht zuarbeiten kann.