S7-Hantierungsbausteine für R355, R6000 und R2700

Transkript

1 S7-Hantierungsbausteine für R355, R6000 und R FB90, Zyklus_R/W Dieser Baustein dient zur zentralen Kommunikation zwischen Anwenderprogramm und dem Modul R355 sowie den Geräten R6000 und R2700 über Profibus DP. Achtung, der FB90 erfordert intern den FC90 Der Baustein ist im OB1 bzw. in der Aufrufebene des OB1 zyklisch aufzurufen. Aufruf für R355 oder R6000: CALL "ZYKLUS_R/W", "inst DB" // R355 oder R6000 Adr :=256 DB_channel1 :="DB Kanal 1" DB_channel2 :="DB Kanal 2" DB_channel3 :="DB Kanal 3" DB_channel4 :="DB Kanal 4" DB_channel5 :="DB Kanal 5" DB_channel6 :="DB Kanal 6" DB_channel7 :="DB Kanal 7" DB_channel8 :="DB Kanal 8" DB_Device :="DB FM355" DB_Parameters :="DB_Param_wld" DP_mode :=FALSE reset :=M10.0 // Anlaufmerker (OB100) param_autowrite:=true read_all_blocks:=false ready :=M10.1 Aufruf für den R2700: CALL "ZYKLUS_R/W", "inst DB" // R2700 Adr :=256 DB_channel1 :="DB R27 Ch1" // nur Kanal 1 DB_channel2 := DB_channel3 :="DB R27 Prog" // aktuelles Programm DB_channel4 := DB_channel5 := DB_channel6 := DB_channel7 := DB_channel8 := DB_Device :="DB R27 Dev" // kein Parameter-DB!!! DB_Parameters := DP_mode :=FALSE reset :=M10.0 // Anlaufmerker (OB100) param_autowrite:=false read_all_blocks:=true ready :=M10.1 // Zyklusbetrieb

2 Parameter: Adr DB_channel1...8 DB_Device DB_Parameters DP_mode reset param_autowrite Peripherieadresse des Moduls, Eingang wie Ausgang gleich! Kanal DBs: Für jeden Reglerkanal existiert ein eigener Datenbaustein. Dieser enthält kanalspezifische Daten, wie z.b. Soll-, Istwerte, Status, Reglerfunktion,... Beim R355 und R6000 sind es maximal 8 Kanäle, beim R2700 nur einer. Wird der R2700 als Programmregler genutzt, so ist auf Kanal 3 der DB für das aktuelle Programm zu parametrieren. Falls Kanäle nicht belegt sind, darf der entspr. DB unparametriert bleiben. Dann ist der entspr. DB in der Steuerung nicht erforderlich. Regler DB: Für jede Reglerbaugruppe bzw. Gerät existiert genau ein solcher DB. Dieser enthält gerätespezifische Daten, wie Fehlerstatus, Quitierbits,... DB_Param_wld: Dieser DB enthält die vollständige Modulparametrierung für R355 und R6000, die Sie mittels Parametriertool erzeugen und in die SPS übertragen. Hiermit erreichen Sie bei einem Bauggruppenwechsel eine voll automatische und vollständige Parametrierung der neuen Baugruppe. Beim R2700 existiert dieser DB nicht, da in den anderen DBs im Gegensatz zum R355 / R6000 die vollständige Parametrierung enthalten ist. false: Wenn Baugruppe lokal am Rückwandbus der CPU steckt. true: Wenn Baugruppe am Profibus hängt (VIPA IM 353). Anlaufbit: Dieses Bit muss beim Anlauf der CPU für einen Zyklus auf true sein, z.b. durch Setzen im OB100. Dies bewirkt die Initialisierung des Kommunikations-FBs und der zugehörigen Datenbausteine. Nach dem Aufruf von "ZYKLUS_R/W" ist es wieder zu löschen. true: Die Parametrierung aus dem DB_Param_wld wird bei Ungleichheit automatisch in das evtl. getauschte Modul geladen. Baugruppentausch ohne PG ist somit möglich. false: Parametrierung wird nicht automatisch übertragen. Diese Funktion wird abhängig von der Para_Satz_ID gesteuert. D.h. die Parametrierung enthält einen Zeitstempel, der zwischen Modul und SPS verglichen wird. Bei Ungleichheit wird die Parametrierung zum Modul übertragen. (Beim R2700 immer false, da kein DB_Param_wld vorhanden.) read_all_blocks ready (out) true: Beim Anlauf der Kommunikation zum Modul werden einmalig alle Datenblöcke aus dem Modul geladen. D.h. die Anlaufdaten kommen immer aus dem Modul. false: Anlaufdaten werden aus den DBs genommen. false: Initialisierung der Kommunikation läuft noch, dies kann mehrere Sekunden dauern. true: Kommunikation vollständig initialisiert, d.h. der Regler ist nun einsatzbereit.

3 Interne Parameter: param_db_write_req param_db_read_req true: damit kann die Übertragung der vollständigen Reglerparametrierung aus dem DB_Param_wld in das Modul angefordert werden. false: Übertragung wurde nicht angefordert, oder ist beendet. true: Damit kann die Übertragung der vollständigen Regler- Parametrierung aus dem Modul, in den DB_Param_wld angefordert werden. false: Übertragung wurde nicht angefordert, oder ist beendet. Diese Funktionen können zu einem beliebigen Zeitpunkt angefordert werden. Dies ist aber nur sinnvoll zur Inbetriebnahmezeit. Die Übertragung der Parametrierung kann auch aus dem Inbetriebnahmetool angestoßen werden. Dann wird der DB_Param_wld automatisch mit der aktuellen Reglerparametrierung überschrieben. 2. Kanal DBs, bzw. Regler DB Struktur shadow mode : DBB interne Verwaltungsdaten DBW *n Datenbereich, hier liegen die n Datenblöcke, n 16 DBW *n *n Shadowbereich, hier liegt eine Kopie der Daten Die internen Verwaltungsdaten werden von der Funktionalität des Scanners benötigt und dürfen vom Anwender nicht verändert werden. Nur der Datenbereich ist für den Benutzer bestimmt. Dort sind z.b. die Soll- und Istwerte zu finden. Die Istwerte werden automatisch vom Regler bei Änderung zur Steuerung übertragen und sind im Datenbereich immer aktuell. Sollwerte werden einfach vom Anwender in den Datenbereich geschrieben, diese werden dann vom Scanner automatisch als geändert erkannt und zur Übertragung zum Regler bereitgestellt. Struktur dirty mode : DBB interne Verwaltungsdaten DBW *n Datenbereich, hier liegen die n Datenblöcke, n 16 Im dirty mode entfällt der Shadowbereich, dadurch wird der DB-kürzer. Dieser Mode ist sinnvoll, wenn der Speicherplatz in der CPU knapp ist. Vor- und Nachteile von shadow- bzw. dirty mode shadow: dirty: pos. Bei Änderung eines Sollertes" wird dieser automatisch übertragen neg. Erhöhter Speicherbedarf, Datenbereich wird zweimal benötigt neg. Erhöhte Zyklusbelastung, da das Scannen (Vergleichen) der Daten auf Änderung Zeit benötigt (irrelevant bei schnellen CPUs). pos. geringerer Speicherbedarf der DBs pos. geringere Zyklusbelastung neg. Bei Änderung eines SollWertes" ist das zugehörige Shadow-Bit zu setzen, dies ist vom Anwenderprogramm zu erledigen.

4 3. FC90, DB_Scanner Dieser Baustein wird vom FB90 intern benötigt, er dient zur Initialisierung der Kanal- und des Regler- DBs. Beim Anlauf (Initialisierung) werden in allen DBs (außer DB_Param_wld) alle dirty-bits gesetzt und die shadow-daten auf ungültig gesetzt. Dies dient dazu, um die Datenblöcke als dirty, d.h. zu übertragen zu markieren. Im Normalbetrieb prüft der Scanner ob Blöcke zu übertragen sind und veranlasst dies falls nötig. Die Datenblöcke werden dadurch nur bei Bedarf an den Regler gesendet. Dies geschieht nur bei Änderung der Daten, oder im dirty_mode beim Setzen des entspr. dirty-bits. 4. FC91, FM355_write_Outputs Dieser Baustein dient zur direkten Ausgabe zum Modul R355 sowie zu den Geräten R6000 und R2700 über Profibus DP. Beim R355 und R6000 sind damit die freien binären Ausgänge direkt zu steuern, beim R2700 kann der Sollwert gesetzt werden. Die Funktion wird bei Bedarf oder zyklisch vor "ZYKLUS_R/W" aufgerufen. Beispiel für R355 oder R6000: L W#16#36C9 // einfach nur Bitmuster T #W0 // Out , L W#16#36C9 T #W2 // Out ( ), CALL "FM355_write_Outputs" // freie binäre // Ausgänge schreiben Set_W0 :=#W0 Set_W2 :=#W2 Beispiel für den R2700: L 49 // Sollwert = 49 bzw. 4,9 T #SP // Int => Word T #W0 CALL "FM355_write_Outputs" // Sollwert direkt setzen Set_W0 :=#W0 Set_W2 :=W#16#AA54 // Schreibcode = W#16#AA55

5 5. FC92, FM355_read_Inputs Dieser Baustein dient zum direkten Einlesen vom Modul R355 sowie von den Geräten R6000 und R2700 über Profibus DP. Beim R355 und R6000 werden damit die Zustände der binären Eingänge gelesen, beim R2700 die aktuelle Regel- und Stellgröße. Die Funktion wird bei Bedarf oder zyklisch nach "ZYKLUS_R/W" aufgerufen. Beispiel für R355 oder R6000: CALL "FM355_read_Inputs" // binäre Eingänge holen Get_W0 :=#W0 // In , Get_W2 :=#W2 // In ( ), Beispiel für den R2700: CALL "FM355_read_Inputs" // Werte holen Get_W0 :=#W0 Get_W2 :=#W2 L #W0 // Regelgröße T #PV L #W2 // Stellgröße T #ED