TIA S7-1500 HMI-Kommunikation (Zykluskontrollpunkt)

[steuerung]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen

Ist es möglich bei der 1500er CPU die Kommunikation nicht azyklisch sondern auf den Zykluskontrollpunkt zu legen gleich wie bei den S7-300er CPU´s.

Bei einigen der 300er CPU´s war es möglich dies über die Option "priorisierte BuB-Kommunikation" zu entscheiden.

Eine Möglichkeit die ich in der Hilfe fand ist die Priorität des OB´s zu erhöhen das dieser nicht durch die Kommunikation unterbrochen wird.
Da dies aber nicht für die Zyklus OB´s einstellbar ist und ich diese Variante nicht wählen will, suche ich nach anderen Möglichkeiten.

"CPU Eigenschaften->Zyklusbelastung durch Kommunikation"

Wirkungsweise des Parameters
Über den Parameter "Zyklusbelastung durch Kommunikation" geben Sie den Prozentsatz der gesamten CPU-Verarbeitungsleistung an, der den Kommunikationsprozessen zur Verfügung stehen soll.
Wenn die Kommunikation diese Verarbeitungsleistung nicht benötigt, steht sie der Programmbearbeitung zur Verfügung.
Für die Prioritätsklassen kleiner oder gleich 15 wird die Verarbeitungsleistung der Kommunikation ständig von der CPU zugewiesen.
Prioritätsklassen größer als 15 werden nicht durch Kommunikation unterbrochen.
Sie beeinflussen also durch die Zuweisung der Priorität eines Ereignisses bzw. eines OBs die Unterbrechbarkeit des OBs und der Bausteine, die von dem OB aufgerufen werden. Wenn auf diese Weise größerer Programmabschnitte nicht unterbrechbar gemacht werden, um die Zykluszeiten zu minimieren, verzögern sich Online-Funktionen von STEP 7!
Quelle: TIA V12 SP1 Hilfe

Gruß
steuerung

 

[PN/DP]

S7-1500 kenne ich nicht, aber Du könntest Dir selber ein "Prozessabbild_HMI" erzeugen, indem das HMI nur mit einem Koppel-DB kommuniziert und Du im OB1 den Koppel-DB in einen zweiten DB kopierst. Im Programm verarbeitest Du dann nur den zweiten DB.

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

S7-1500 kenne ich nicht, aber Du könntest Dir selber ein "Prozessabbild_HMI" erzeugen, indem das HMI nur mit einem Koppel-DB kommuniziert und Du im OB1 den Koppel-DB in einen zweiten DB kopierst. Im Programm verarbeitest Du dann nur den zweiten DB.

Jo, oder in dem jeweiligen FB mit zugehörigem DB zusätzliche HMI-Variablen anlegen, welche am Anfang der FB Bearbeitung gelesen (und in zusätzliche Variablen kopiert) und am Ende beschrieben werden. Also wie die Lösung von PN/DP nur pro Baustein...

So arbeite ich eigentlich schon immer, da mir auch bei 300/400 nicht immer genau klar war, wann das HMI die Variablen liest/beschreibt.

Gruß.

 

[Thomas_v2.1]

Jo, oder in dem jeweiligen FB mit zugehörigem DB zusätzliche HMI-Variablen anlegen, welche am Anfang der FB Bearbeitung gelesen (und in zusätzliche Variablen kopiert) und am Ende beschrieben werden. Also wie die Lösung von PN/DP nur pro Baustein...

Das kann je nachdem wie auf die Daten zugegriffen wird auch mal nicht funktionieren.
Ist mir bei einem Test mit einer S7-400 die ja auch im Zyklus kommuniziert heute noch aufgefallen. Um Befehle von der HMI an die SPS zu geben, habe ich ein Befehls-Dword. Wird von der HMI ein Befehl gesetzt, wird das entsprechende Bit in Dword gesetzt und komplett an die SPS gesendet. Die SPS setzt das Bit nach Abarbeitung zurück. Ich hatte das Dword als In-Out Parameter an einem FB (d.h. im FB einlesen, gucken ob die passenden Bits gesetzt sind, und dann das Dword wieder auf 0).
Nun ist es sporadisch aufgefallen, dass manche Befehle in der nicht SPS ankamen. Bei genauer Betrachung auch logisch, da alle Befehle die während der FB mit der Abarbeitung beschäftigt war in der SPS ankamen, beim Verlassen des FBs wieder plattgeschrieben wurden. Das ist mir nur aufgefallen, weil ich nur diesen einen Baustein im Programm hatte, und dadurch die Wahrscheinlichkeit dass die Kommunikation während der FB Bearbeitung eintraf sehr hoch war. In einem "normal" großen Programm ist die Wahrscheinlichkeit dass dieses eintritt eher gering, aber natürlich trotzdem ein Fehler.

Ich habe dann den Parameter in ein UDT mit 32 Bools geändert, und eine Instanz der UDT dem FB als In-Out (also als Zeiger) übergeben, d.h. im FB wird direkt auf den Daten und nicht auf einer Kopie gearbeitet. Dadurch funktioniert das auch bei Steuerungen bei denen die Kommunikation im Zyklus abläuft.

Man müsste bei der 1500er wissen, wann ein Parameter per Value, und wann per Referenz übergeben wird. Bei den neuen Steuerungen ist vieles nicht nachvollzieh- oder nachlesbar.

 

[ducati]

Ich hatte das Dword als In-Out Parameter an einem FB (d.h. im FB einlesen, gucken ob die passenden Bits gesetzt sind, und dann das Dword wieder auf 0).
Nun ist es sporadisch aufgefallen, dass manche Befehle in der nicht SPS ankamen. Bei genauer Betrachung auch logisch, da alle Befehle die während der FB mit der Abarbeitung beschäftigt war in der SPS ankamen, beim Verlassen des FBs wieder plattgeschrieben wurden. .

Hmm, im FB das DWORD in eine Variable kopieren und gleich danach 0 setzen, nicht erst am Bausteinende. Dann sollte doch eigentlich die Chance, dass was verloren geht, gering sein?

PS: Die Visu beschreibt bei mir direkt die INOUT Variable des IDB.

Ich habe dann den Parameter in ein UDT mit 32 Bools geändert, und eine Instanz der UDT dem FB als In-Out (also als Zeiger) übergeben, d.h. im FB wird direkt auf den Daten und nicht auf einer Kopie gearbeitet. Dadurch funktioniert das auch bei Steuerungen bei denen die Kommunikation im Zyklus abläuft.
.

Kostet dann aber 32 Powertags?

Gruß.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hmm, im FB das DWORD in eine Variable kopieren und gleich danach 0 setzen, nicht erst am Bausteinende. Dann sollte doch eigentlich die Chance, dass was verloren geht, gering sein?

PS: Die Visu beschreibt bei mir direkt die INOUT Variable des IDB.

Wenn du direkt in den Instanz-DB schreibst dann funktioniert das wohl.
Ich meinte es aber so, dass wenn man einen InOut-Parameter so benutzt wie er gedacht ist, also mit externer Beschaltung.

Kostet dann aber 32 Powertags?

Ich nutze ja kein OS-übersetzen, d.h. meine Variablen zu WinCC liegen in einem separaten Schnittstellen-DB und werden über ein eigenes Tool erzeugt. Da kann ich die anlegen wie ich will. Hat den Vorteil dass ich in der SPS kein "blindes" Dword liegen habe, sondern eine Struktur in der die Bits symbolisch beschrieben sind.

 

[HelleBarde]

Man müsste bei der 1500er wissen, wann ein Parameter per Value, und wann per Referenz übergeben wird. Bei den neuen Steuerungen ist vieles nicht nachvollzieh- oder nachlesbar.

Hi Thomas

doch das bekommt man schon raus. schau dir mal http://www.sps-forum.de/simatic/67084-e-adressen-zur-laufzeit-bestimmen.html#post46381 an.
Im folgenden kommen (http://www.sps-forum.de/simatic/67084-e-adressen-zur-laufzeit-bestimmen-2.html#post464334) dann noch ein paar Tricks, wie man das nachweisen kann.

'n schön' Tach auch
HB

 

[ducati]

Ich habe dann den Parameter in ein UDT mit 32 Bools geändert, und eine Instanz der UDT dem FB als In-Out (also als Zeiger) übergeben, d.h. im FB wird direkt auf den Daten und nicht auf einer Kopie gearbeitet. Dadurch funktioniert das auch bei Steuerungen bei denen die Kommunikation im Zyklus abläuft.

Hallo Thomas, hab Grand nen Blackout und krigs nicht hin

- hab nen GlobalDB mit den UDTs.
- Im FB (SCL) hab ich jetzt ne VAR_IN_OUT angelegt Signale : UDT170
- beim Aufruf des FB (in FUP) hänge ich an den Eingang ein Struct des GlobalDBs also z.B. GlobalDB.Motor1

wie frage ich in SCL jetzt die einzelnen BOOLs ab? ich dachte einfach mit Signale.Bool01 Signale.Bool2 usw...? aber irgendwie sind die alle 0

wo ist mein Denkfehler?

Danke.

 

[shutdown_TIA12]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie sieht dein PLC_Datentyp (heißt nicht mehr UDT) aus? Oder benutzt du einen STRUCT??

Wenn dein InOut den Namen VARRR von TYP "Mein_PLC_Typ" hat und dort hast du Signal_1 und Signal_2 von Typ Byte, dann sieht dein Code z.B. so aus:

#VARRR.Signal_1.X0 := #VARRR.Signal_2.X5

Oder wenn es direkt ein Bool sein sollte

#VARRR.Signal_ist_Bool_1:= #VARRR.Signal_ist_Bool_2

 

[ducati]

danke.

Funktioniert auch so wie gedacht.

Ich hab das grad wie Thomas in Step7 getestet, nicht TIA-Portal.

Ich hatte nen Programmierfehler drin und im falschen DB mit den Aktualparametern durcheinander gekommen

Gruß.