Unterdrückung von Befehlen einzelner Bedienebenen

[gerät1234]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

Ich habe Aufgabe bekommen eine Automatisierungsanlage zu programmieren. Dabei verwende ich eine Siemens - 1515F-2. Unter TIA V15.1.
Die Anlage besteht aus 4 Bedienebenen (Leitstand, TouchPanel im Betriebsraum sowie 2 MobilePanels). Während des Betriebs darf die Anlage immer nur von einer Bedienebene gesteuert werden. Über die anderen Bedienebenen kann der Anlagenführer zwar den Anlagenzustand einsehen aber nicht aktiv eingreifen. Die Befehle von den inaktiven Bedienebenen müssen deshalb ignoriert werden.
Meine Frage dazu:

• Wie schaffe ich es, dass die Befehle von den inaktiven Bedienebenen ignoriert werden?
• Gibt es die Möglichkeit einer Bedienebene die Schreiberlaubnis von Variablen zu entziehen aber gleichzeitig die Leseerlaubnis aufrechtzuhalten?

Mein Ansatz wäre aktuell z.B. beim Steuerung einer Lampe: (Siehe Anhang)

• Für jede Bedienebene eine eigene Variable anlegen und diese dann im SPS-Programm zu einer „zentralen“ Variable zusammenzuführen. Dabei müsste gleichzeitig abgefragt werden, welche Bedienebene aktuell aktiv ist.
• Das Problem bei dieser Lösung ist, dass dies ein enormer Programmieraufwand ist, weil ich alles 4-fach anlegen muss.

Vielleicht hat ja jemand eine einfachere Variante und kann mit weiterhelfen

Danke schon mal im Voraus

 

[Mrtain]

Mit OOP wüsste ich eine Möglichkeit

 

[Holzmichl]

Zuviel Werbung?
-> Hier kostenlos registrieren

• Für jede Bedienebene eine eigene Variable anlegen und diese dann im SPS-Programm zu einer „zentralen“ Variable zusammenzuführen. Dabei müsste gleichzeitig abgefragt werden, welche Bedienebene aktuell aktiv ist.
• Das Problem bei dieser Lösung ist, dass dies ein enormer Programmieraufwand ist, weil ich alles 4-fach anlegen muss.

Vielleicht hat ja jemand eine einfachere Variante und kann mit weiterhelfen
[/QUOTE]

Wenn Du das machen willst musst Du dir auch ein Konzept überlegen, was passiert beim Umschalten von einem Bediengerät zum nächsten.
Nicht das beim Gerät mit der neuen Hoheit etwas angewählt ist und unkontrolliert anläuft.

Ich mache das bei größeren Anlagen meistens mit je einem Global-DB, z.B. "DB HMI BP1" bis "DB HMI BP4", die alle identisch sind, und sobald abgewählt wird werden alle Vorwahlen gelöscht.
Allerdings sind das Anlagen, in denen vor Ort meistens nur Handfunktionen, solange ein Taster bzw eine Schaltfläche gedrückt wird, gemacht werden.
Globale Einstellwerte sind nur vom Hauptpult aus zu verändern oder werden gleichwertig behandelt.

Am Einfachsten für dein Anliegen könnte ich mir vorstellen wäre ein transparentes Rechteck über allen Eingabefeldern, das nur bei Anwahl des jeweiligen Bediengerätes unsichtbar geschaltet wird.
Eventuell zusätzlich mit dem Verweis, dass ein anderes Gerät die Bedienhoheit hat.

 

[PN/DP]

Bedienelemente mit transparenten Objekten überdecken garantiert nicht, daß das Panel nicht bedienen kann. Man könnte z.B. eine USB-Tastatur anschließen und die Bedienelemente per Cursortasten + Enter anwählen und bedienen. Auch Animationen "Bedienbarkeit" der Bedienelemente schützen nicht 100% sicher vor Bedienhandlungen der eigentlich gesperrten Bedienstellen. Die Verknüpfung der Bedienhoheit muß in der SPS gemacht werden. Um das 4-fach Anlegen getrennter Bedienvariablen in der SPS kommt man nicht drum rum.

Achtung: die 1500-CPU hat keinen Zykluskontrollpunkt für HMI-Kommunikation! Wenn man sich die 4-fach-Verknüpfungen an jeder Programmstelle sparen will, könnte man die 4 Speicherbereiche der Bedienvariablen der 4 Bedienstellen "am Stück" auf nur einen Arbeits-Speicherbereich umkopieren - das muß dann aber so passieren, daß die HMI-Kommunikation da nicht dazwischenspringen kann.

Sollen die nicht bedienberechtigten Bedienstellen "für sich" unabhängig Bilder anschauen/wechseln können oder müssen die passiv die selben Bilder sehen wie die bedienberechtigte Bedienstelle anwählt? Man könnte ggf. nur eine einzige Visu-Runtime laufen lassen und alle Bedienstellen schauen per Smartviewer zu und nur eine Verbindung hat Schreib/Bedienrechte.

Harald

 

[PN/DP]

Wenn ich 1515F und MobilePanel lese - hat die Bedienhoheit was mit Safety zu tun? Gibt es eine Gefährdungsanalyse?

Man könnte auch mit Profinet-Direkttasten arbeiten, die haben einen Zykluskontrollpunkt. Da läßt sich sogar das ganze Profinet-IO-Device per D_ACT_DP deaktivieren.

Harald

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bedienelemente mit transparenten Objekten überdecken garantiert nicht, daß das Panel nicht bedienen kann. Man könnte z.B. eine USB-Tastatur anschließen und die Bedienelemente per Cursortasten + Enter anwählen und bedienen. Auch Animationen "Bedienbarkeit" der Bedienelemente schützen nicht 100% sicher vor Bedienhandlungen der eigentlich gesperrten Bedienstellen. Die Verknüpfung der Bedienhoheit muß in der SPS gemacht werden. Um das 4-fach Anlegen getrennter Bedienvariablen in der SPS kommt man nicht drum rum.

Achtung: die 1500-CPU hat keinen Zykluskontrollpunkt für HMI-Kommunikation! Wenn man sich die 4-fach-Verknüpfungen an jeder Programmstelle sparen will, könnte man die 4 Speicherbereiche der Bedienvariablen der 4 Bedienstellen "am Stück" auf nur einen Arbeits-Speicherbereich umkopieren - das muß dann aber so passieren, daß die HMI-Kommunikation da nicht dazwischenspringen kann.

Sollen die nicht bedienberechtigten Bedienstellen "für sich" unabhängig Bilder anschauen/wechseln können oder müssen die passiv die selben Bilder sehen wie die bedienberechtigte Bedienstelle anwählt? Man könnte ggf. nur eine einzige Visu-Runtime laufen lassen und alle Bedienstellen schauen per Smartviewer zu und nur eine Verbindung hat Schreib/Bedienrechte.

Harald

Du meinst man hätte für jede Bedienstelle einen gleich strukturierten DB und einen "zentralen"?
Also das der zentrale tatsächlich verknüpft wird im Programm, die anderen, je nach Anwahl aber dann auf diesen einen geschrieben werden?
Klingt für mich gerade ziemlich einleuchtend und man kann jederzeit zusätzliche Bedienstellen hinterherpflegen. Wäre bei einer Anmeldung ja nur das Setzen von einer Integer-Variable auf einen Wert.

Das mit dem dazwischenspringen wäre doch gelöst wenn am Zyklusbeginn einmalig der Umkopieren geschehen würde oder?

Müsste sowas bald auch machen (in 2 Monaten), die Frage kommt mir gerade recht, hätte wohl eher auf die Transparenz zurückgegriffen.

 

[PN/DP]

Du meinst man hätte für jede Bedienstelle einen gleich strukturierten DB und einen "zentralen"?
Also das der zentrale tatsächlich verknüpft wird im Programm, die anderen, je nach Anwahl aber dann auf diesen einen geschrieben werden?

Ja. Genau so.

Das mit dem dazwischenspringen wäre doch gelöst wenn am Zyklusbeginn einmalig der Umkopieren geschehen würde oder?

Das Problem ist daß die HMI-Kommunikation das Umkopieren unterbrechen kann, dann wäre das Umkopieren nicht mehr sicher konsistent. Das Umkopieren funktioniert eigentlich nur gut mit Bedienbits. Sobald da Einstellwerte hin und her gehen wird es im Detail "haarig". Weil es für die HMI-Kommunikation keinen Zykluskontrollpunkt gibt, ist die Verarbeitung von HMI-Eingaben ein Multitasking-Problem, was oftmals eigentlich Handshakes erfordert.

Harald

 

[escride1]

Ich hätte das Kopieren mittels MOVE_BLK gemacht. Da funkt die Kommunikation noch dazwischen? Gäbe es eine Lösung dafür?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn schon dann sollte man UMOVE_BLK nehmen. Doch auch dem traue ich nicht.

Theoretisch kann man für den Programm-OB eine Priorität einstellen, die nicht von HMI-Kommunikation unterbrochen werden kann. Damit habe ich aber keine Erfahrung. Frühere Diskussionen bzgl. Zykluskontrollpunkt und konsistente HMI-Kommunikation hier im SPS-Forum hinterlassen bei mir den (vielleicht falschen?) Eindruck, daß Programm-Unterbrechungen nicht wirklich verhindert werden können und daß sich da womöglich durch HMI verursachte Variablenänderungen einschleichen können. Vielleicht meldet sich noch jemand mit konkreten Erfahrungen.

Harald

 

[Howard]

Moin,

Du meinst man hätte für jede Bedienstelle einen gleich strukturierten DB und einen "zentralen"?
Also das der zentrale tatsächlich verknüpft wird im Programm, die anderen, je nach Anwahl aber dann auf diesen einen geschrieben werden?
Klingt für mich gerade ziemlich einleuchtend und man kann jederzeit zusätzliche Bedienstellen hinterherpflegen. Wäre bei einer Anmeldung ja nur das Setzen von einer Integer-Variable auf einen Wert.

Das mit dem dazwischenspringen wäre doch gelöst wenn am Zyklusbeginn einmalig der Umkopieren geschehen würde oder?

Müsste sowas bald auch machen (in 2 Monaten), die Frage kommt mir gerade recht, hätte wohl eher auf die Transparenz zurückgegriffen.

Genau so realisiere ich das aktuell. Jedes HMI hat einen Koppel-DB zur Steuerung und je ein HMI-FB pro HMI. Dieser FB macht aus den Eingaben des HMIs die eigentlichen Steuerbefehle. Nachgelagert gibt es dann eine Funktion die je nach Steuerhoheit quasi die zuvor gebildeten Steuerbefehle in den zentralen HMI-Interface-DB umkopiert. Der Rest des Programms arbeit dann nur mit diesem Zentralen HMI-Interface.