roboticBeet
Level-2
- Beiträge
- 484
- Reaktionspunkte
- 196
-> Hier kostenlos registrieren
Hallo zusammen,
wie strukturiert ihr eure Beckhoff TwinSAFE Projekte? Bislang haben wir TwinSAFE vor allem in Projekten mit (einfachen) fehlersicheren Ein- und Ausgängen eingesetzt. Auch die Antriebe verfügten in der Regel über eine Hardwareschnittstelle für STO/SS1, die von fehlersicheren Ausgängen entsprechend beschaltet wurde. Komplexere Sachen hatten in der Regel komplett eine S7 F Steuerung verbaut.
Nun kommt aber ein größeres Projekt, welches mit Beckhoff TwinCAT umgesetzt werden soll und ich bin mir unsicher, ob unsere allgemeine TwinSAFE Projektstruktur dazu gut passt und skaliert. Der Grund dafür ist, dass rund 60 Beckhoff Servoachsen mit dezentralen Safety Funktionen und FSoE Kommunikation eingesetzt werden.
Grundsätzlich strukturieren wir unsere TwinSAFE Projekte auf einer EL6910 bislang in vier TwinSAFE Gruppen: Inputs, Logic, Outputs und Diag. In Inputs werden die F-DIs vorverarbeitet, bspw. mit den entsprechenden EStop bzw. SafeMon Bausteinen. In der Gruppe Logic werden diese Signale danach weiterverarbeitet und mit Betriebsartenfreigaben, Zustimmtaster u. ä. logisch verknüpft bevor die Signale in Output dann an die F-DQ Baugruppen gehen. In der Gruppe Diag findet eine allgemeine Diagnose statt und es werden allgemeine Signale, wie bspw. ein AlwaysTrue, generiert.
Aliasgeräte deklarieren wir in der Regel in derjenigen Gruppe, in der sie primär benötigt werden. Der Austausch von Variablen zwischen den TwinSAFE Gruppen findet über entsprechende globale Variablen statt.
Bei dem neuen Projekt kommen nun Beckhoff Achsen mit dezentraler Safety dazu. Prinzipiell ist aktuell der Plan, für die Achsen mit gleichen Sicherheitsfunktionen das jeweilige Safety Projekt mit dem Safe Motion Wizards zu erstellen und über die Multilink Funktion mit der übergeordneten EL6910 zu verbinden. Die EL6910 sollte dabei idealerweise der gleichen Struktur wie oben folgen und natürlich die allgemeinen Sicherheitsauswertungen (Not-Halt, Schutztüren, ...) ausführen und nötige Freigaben für Pneumatikgruppenventile etc. geben.
Wie bindet man in dieser Struktur die dezentralen Beckhoff Servoachsen oder allgemein (komplexe) FSoE Teilnehmer am besten ein? Das FSoE Signalabbild lässt sich nicht so einfach Input, Logic und Output zuordnen bzw. es ist eine aufwändigere Querkommunikation zwischen den TwinSAFE Gruppen mit entsprechend vielen globalen Variablen notwendig.
Wie würde man, wenn man doch viele Variablen benötigt, diese am besten benennen? Die Idee hierzu war, für jeden Umrichter eine eigene Variablenliste anzulegen mit dem BMK als Namen. Dann werden aber Variablen wie =PLC.2+S1-1T1.STO_active_ChA abgeschnitten und das Projekt schwer lesbar...
Danke für eure Ideen.
wie strukturiert ihr eure Beckhoff TwinSAFE Projekte? Bislang haben wir TwinSAFE vor allem in Projekten mit (einfachen) fehlersicheren Ein- und Ausgängen eingesetzt. Auch die Antriebe verfügten in der Regel über eine Hardwareschnittstelle für STO/SS1, die von fehlersicheren Ausgängen entsprechend beschaltet wurde. Komplexere Sachen hatten in der Regel komplett eine S7 F Steuerung verbaut.
Nun kommt aber ein größeres Projekt, welches mit Beckhoff TwinCAT umgesetzt werden soll und ich bin mir unsicher, ob unsere allgemeine TwinSAFE Projektstruktur dazu gut passt und skaliert. Der Grund dafür ist, dass rund 60 Beckhoff Servoachsen mit dezentralen Safety Funktionen und FSoE Kommunikation eingesetzt werden.
Grundsätzlich strukturieren wir unsere TwinSAFE Projekte auf einer EL6910 bislang in vier TwinSAFE Gruppen: Inputs, Logic, Outputs und Diag. In Inputs werden die F-DIs vorverarbeitet, bspw. mit den entsprechenden EStop bzw. SafeMon Bausteinen. In der Gruppe Logic werden diese Signale danach weiterverarbeitet und mit Betriebsartenfreigaben, Zustimmtaster u. ä. logisch verknüpft bevor die Signale in Output dann an die F-DQ Baugruppen gehen. In der Gruppe Diag findet eine allgemeine Diagnose statt und es werden allgemeine Signale, wie bspw. ein AlwaysTrue, generiert.
Aliasgeräte deklarieren wir in der Regel in derjenigen Gruppe, in der sie primär benötigt werden. Der Austausch von Variablen zwischen den TwinSAFE Gruppen findet über entsprechende globale Variablen statt.
Bei dem neuen Projekt kommen nun Beckhoff Achsen mit dezentraler Safety dazu. Prinzipiell ist aktuell der Plan, für die Achsen mit gleichen Sicherheitsfunktionen das jeweilige Safety Projekt mit dem Safe Motion Wizards zu erstellen und über die Multilink Funktion mit der übergeordneten EL6910 zu verbinden. Die EL6910 sollte dabei idealerweise der gleichen Struktur wie oben folgen und natürlich die allgemeinen Sicherheitsauswertungen (Not-Halt, Schutztüren, ...) ausführen und nötige Freigaben für Pneumatikgruppenventile etc. geben.
Wie bindet man in dieser Struktur die dezentralen Beckhoff Servoachsen oder allgemein (komplexe) FSoE Teilnehmer am besten ein? Das FSoE Signalabbild lässt sich nicht so einfach Input, Logic und Output zuordnen bzw. es ist eine aufwändigere Querkommunikation zwischen den TwinSAFE Gruppen mit entsprechend vielen globalen Variablen notwendig.
Wie würde man, wenn man doch viele Variablen benötigt, diese am besten benennen? Die Idee hierzu war, für jeden Umrichter eine eigene Variablenliste anzulegen mit dem BMK als Namen. Dann werden aber Variablen wie =PLC.2+S1-1T1.STO_active_ChA abgeschnitten und das Projekt schwer lesbar...
Danke für eure Ideen.
