Erkennen wenn Parametrierung von Profibus Slave notwendig ist?

Muphin

Level-1
Beiträge
51
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo ihr!
In dem SCL Programm, um das es sich hier dreht, können während der Laufzeit des Programms sich die Parametrierdaten eines Profibus Slaves ändern. Diese geänderten Daten sollten dann z.B. beim Neustart der SPS oder beim ziehen/stecken des Slaves auch wieder an den Slave übertragen werden und nicht die ursprünglich im Master hinterlegten Parameterdaten.

Ich sehe momentan somit 2 Lösungswege, einmal das überspeichern der hinterlegten Daten im Master, oder das erkennen wenn eine Neuparametrierung des Slaves erforderlich ist.
Bei ersterem (Parameterdaten im Master aktualisieren) sehe ich bisher keine Möglichkeit das umzusetzen, liege ich da evtl falsch und das geht doch irgendwie?
Die 2. Möglichkeit (Neuparametrierung erkennen) sollte ja auf jeden Fall umsetzbar sein, nur wie geht das am Besten? Gibt es da eine zentrale Anlaufstelle die mir sagt "jetzt braucht ein Slave neue Parameterdaten" z.B. einen OB oder ein Flag? Oder muss ich da dann mehrere Zustände beachten z.B. OBs für Neustart, ziehen/stecken, Anlauf usw.? Und welches sind dann die OBs oder Flags die mir das anzeigen?

Wäre super wenn ihr mich auch hier wieder den entsprechenden Schritt weiterbringen könnt!

Grüße
Muphin
 
Ich sehe momentan somit 2 Lösungswege, einmal das überspeichern der hinterlegten Daten im Master, oder das erkennen wenn eine Neuparametrierung des Slaves erforderlich ist.
Bei ersterem (Parameterdaten im Master aktualisieren) sehe ich bisher keine Möglichkeit das umzusetzen, liege ich da evtl falsch und das geht doch irgendwie?
Die 2. Möglichkeit (Neuparametrierung erkennen) sollte ja auf jeden Fall umsetzbar sein, nur wie geht das am Besten? Gibt es da eine zentrale Anlaufstelle die mir sagt "jetzt braucht ein Slave neue Parameterdaten" z.B. einen OB oder ein Flag? Oder muss ich da dann mehrere Zustände beachten z.B. OBs für Neustart, ziehen/stecken, Anlauf usw.? Und welches sind dann die OBs oder Flags die mir das anzeigen?

Mich darf jetzt gerne einer berichtigen, aber ich wüsste nicht wie man das bei den S7 Steuerungen lösen könnte, bei anderen Herstellern geht dies wohl.
Die Parameter des Slaves sind in der Hardwarekonfig fest vergeben, die kannst du via Programm nicht ändern.
zu Punkt 2:
Fordert ein Slave eine Neuparametrierung an meldet dir die CPU das über die entsprechenden OB´s (82,86,122), allerdings sagt sie dir nur das der Slave ausgefallen, gestört oder einen Diagnosealarm hat und nicht das er neu Parametriert werden will. Je nach Slave(schön dass du geschrieben hast um welchen es hier geht ;-) ) kann es sein das du aus den Diagnosedaten diese Info rausbekommst, dafür könntest du den FB126 bzw. den alten FB125 von Siemens verwenden oder direkt die SFC´s für die Diagnose verwenden (siehe dazu Handbuch "System- und Standartfunktionen")
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dabei geht es um einen Temperaturregler von Ropex bei dem man über azyklische Schreibzugriffe (WRREC, SFB53) die Parameter verändern kann.

Das hört sich jetzt schwer danach an das ich wirklich alle Ereignisse nach denen eine Neuparametrierung erforderlich ist einzeln auswerten muss. Ich würde in den Fällen dann einfach direkt die während der Laufzeit per WRREC veränderten Parameter wieder zum Slave übertragen. Dann brauch ich erst gar nich über die Diagnosedaten zu prüfen ob er neu parametriert werden muss. Das erfolgt ja im großen und ganzen sowieso automatisch von der SPS, ich hatte nur gehofft das die SPS dem programmierer da eine Info weitergibt wann das der Fall ist.
Außerdem kann ich auch über RDREC die Parameter auslesen und ggf. vergleichen, wenn eine Überprüfung der Parameter notwendig ist, so brauch ich nicht über die Diagnosedaten zu gehen.

Die Meldung von einem Diagnosealarm (OB 82) oder einem Peripheriezugriffsfehler (OB 122) brauch ich dafür denke ich allerdings nicht, eher z.B. die Ziehen/Stecken (OB 83) erkennung.
Den OB 86 kenn ich jetzt noch gar nicht, könnte nützlich sein, werd ich mir mal anschauen!

Wird das jetzt evtl etwas klarer für dich was ich da vorhab? Ich find das etwas schwierig das ordentlich zu beschreiben!

Kennt sich da sonst noch jemand etwas mit aus, ob und wie das Möglich ist?

Grüße
 
Geht denn deine CPU auf Stopp wenn der Slave falsch parametriert ist und die OB 8x und OB 12x nicht geladen sind?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein, der Slave erhält auf jeden Fall gültige Parameter, allerdings eben die Standardparameter die in HW-Konfig vorgegeben sind, und nicht die, die das letzte mal über WRREC an den Slave übertragen wurden.
 
Hallo,
ich habe dein Problem noch immer nicht so ganz verstanden - fasse den Teil, wie ich ihn verstanden habe aber mal zusammen :
Du hast einen PB-Slave an deiner SPS, den du zur Laufzeit mit von der Grund-Konfiguration abweichenden Daten versorgst. Der PB-Slave fällt zeitweilig aus, was dann bewirkt, dass er nach einem "ich bin wieder da" mit der Default-Konfiguration aus dem Master weiter läuft.

Wenn ich da richtig liege dann folgender Ansatz :
Über den schon genannten Siemens-FB kannst du den Ausfall des Slave erkennen. Das speicherst du dir (ggf. in deinem FB) weg. Kommt der Slave wieder so schreibst du ihm die in deinem FB hinterlegte Konfiguration wieder rein.

Wenn ich da falsch liege ... bitte mehr Info ...!

Gruß
Larry
 
Das stimmt soweit, wobei er normal nicht einfach so mal ausfällt, sondern die Daten eben wieder übertragen werden müssen, falls er mal ausfallen sollte, oder eben die Maschine ab- und wieder angeschaltet wird!

Du meinst denke ich mal den FB126!?
Wenn ich das jetzt wiederum richtig verstanden habe, wäre das ein zyklisches Aufrufen des FB126, um dann, falls die Parameter nicht den aktuellen entsprechen oder der Slave mal "abwesend" war, die aktuellen Parameterdaten zu übertragen?

Dafür kommt es jetzt noch stark darauf an, wie der FB auf den Slave zugreift, ich könnte mir gut vorstellen, dass das ganze bei einem Slave eines Fremdherstellers nich so ganz funktioniert, eben je nachdem wie die Daten aus dem Slave gelesen werden.

Grüße Muphin
 
Würde ich als nich ausreichend bezeichnen, da dann innerhalb der einen Minute die Parameter nicht stimmen!
Wenn dann würde die Methode auf eine sozusagen zyklische Dauerübertragung hinauslaufen, was eben wieder recht suboptimal ist, ähnlich wie das zyklische auslesen und vergleichen der Daten! :sm1:
 
Hallo Muphin,
ich nutze (nach wie vor) den FC125 mit einem von mir dranhängenden Baustein. Die FB-Daten benötige ich (für mich) gar nicht.
Wie auch immer - dieser Baustein steht vom Aufruf im zyklischen Programm (OB1) und wird getriggert durch ein Bit, das ich im OB86,OB82,OB122 setze. Dadurch erhalte ich dann in der Konsequenz das Bit "PB-Slave 11 hat einen Fehler" (z.B.). So eine Information würde ich in deinem Fall auswerten und entsprechend verarbeiten.

Bei dem genannten FC/FB kommt es nicht auf den Slave an - solange der sich an die PB-Konventionen hält (und anders kann er am PB gar nicht bestehen) wird er antworten.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann könnte ich in dem Fall auch in den OBs direkt ein Bit setzen, mit dem ich das schreiben durch WRREC auslöse. Oder sehe ich da jetzt einen Vorteil den ich durch den FC125 oder FB126 habe nicht?
 
Dann könnte ich in dem Fall auch in den OBs direkt ein Bit setzen, mit dem ich das schreiben durch WRREC auslöse. Oder sehe ich da jetzt einen Vorteil den ich durch den FC125 oder FB126 habe nicht?

Der Vorteil in deinem Fall wäre bei der Verwendung des FC125(FB126) das du etwas Programmierarbeit sparst, da du nicht erst selbst herausfinden musst:
1. Ob die Meldung von deinem Slave kommt
2. welche Meldung vorliegt (zb. Diagnose-, Gestört- oder Ausfallmeldung)
3. ob es eine kommende oder gehende Meldung ist
 
Stimmt, an die Sachen mit dem erkennen was genau vorgefallen ist, wenn die einzelnen OBs aufgerufen werden habe ich noch gar nicht gedacht! Danke!

Grüße
Muphin
 
Zurück
Oben