Step 7 Datenverfälschung im Sicherheitsprogramm bei CPU 317-TF

Eraser

Level-2
Beiträge
171
Reaktionspunkte
10
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Bei unserer Maschine ist eine CPU 317TF-3 PN/DP eingebaut. Zusätzlich kommen noch Sianmics S120 zum Einsatz, aber das nur am Rande.
Sicherheitsprogramm ist alles angelegt und Maschine funktioniert auch einwandfrei.

Das einzige Problem ist, dass ab und zu (so 1-2x pro Woche), die CPU ohne erkenntlichen Grund und während die Maschine stillstand, auf einmal auf STOP geht.
Daraufhin CPU-Fehler ausgelesen (siehe Bild im Anhang) -> Datenverfälschung im Sicherheitsprogramm.

Die angegebene Adresse in der Störung (A730.1) ist die Quittierlampe. Diese blinkt wenn die Energie noch nicht freigegeben wurde oder eine Sicherheitstür offen ist. Also rein nur eine Lampe zur Anzeige.
Adresse wird auch sonst nirgends im Programm verwendet, sondern rein nur im Safety-FC als "=" - Funktion.

Die anderen Baugruppenfehler sind dann rein nur das Ergebnis, weil die Energieversorgung der Ausgangsmodule weg ist, also nicht das eigentliche Problem (sind ja auch erst nach der Datenverfälschung).

Hatte jemand schon einmal so ein Problem?
Wie kann dieser Fehler entstehen? Wie kann ich diesem auf den Grund gehen?

mfg
Wolfgang
 

Anhänge

  • Datenverfälschung.JPG
    Datenverfälschung.JPG
    135,9 KB · Aufrufe: 65
Ist dein A730.1 ein sicherer Ausgang oder ein normaler Ausgang?
Wenn es ein sicherer Ausgang ist, dann mal die Verdrahtung und die Parametrierung kontrollieren.
Was hängt noch alles auf der entsprechenden Baugruppe?

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja ist ein fehlersicherer Ausgang (siehe Bilder).
Verdrahtung ist OK, Lampe funktioniert auch auf diesem Ausgang (haben das schon öfter so gemacht).
Nur das mit der Datenverfälschung ist neu...


Hardware.jpgF-DO.jpg
 
Greifst du vom Standardprogramm schreibend auf das F-Programm zu? Das könnte den Fehler verursachen
 
Wie findet dein Datenaustausch zwischen F und ST Programm überhaupt statt. Benutzt du Merker? Das wäre ok. Über DBs nicht
 
Nur so nebenbei, bei dieser Maschine hab ich auch noch mit einem anderen Problem zu kämpfen:


Wenn ich bei dieser Station Hardware 2.jpg nach der F-DI-Karte eine normale 4-DI dazuhänge, dann geht die ganze Außenstation auf Störung, obwohl normalerweise das ja gehen sollte (haben wir auch schon öfter gemacht bei anderen Maschinen).
Mein Arbeitskollege hatte dieses Phänomen auch schon bei einer anderen Maschine. Ausweich-Lösung ist, dass man keine Karte nach den F-Karten mehr verbaut, sondern davor einbaut (hier z.B. das PM-E und DO).

Haben auch schon Kontakt zu Siemens deswegen aufgenommen, meinen nur das können sie sich nicht vorstellen und müsste normalerweise gehen. In der nächsten Zeit wird wahrscheinlich wer von Siemens bei uns deswegen vorbeischauen.

mfg
 
Wenn die Verdrahtung und die Parametrierung i.O. sind, dann würde ich auch auf den Datenaustausch tippen.
Beim Austausch über DBs meckert der Compiler beim Erzeugen des F-Programms nicht, aber du bekommst irgendwann den Fehler mit der Datenverfälschung.
Mach mal einen Querverweis über deine F-DBs und schau ob ein Zugriff im Standardprogramm Ärger macht.

Gruß
Dieter
 
Nur so nebenbei, bei dieser Maschine hab ich auch noch mit einem anderen Problem zu kämpfen:


Wenn ich bei dieser Station Anhang anzeigen 28023 nach der F-DI-Karte eine normale 4-DI dazuhänge, dann geht die ganze Außenstation auf Störung, obwohl normalerweise das ja gehen sollte (haben wir auch schon öfter gemacht bei anderen Maschinen).
Mein Arbeitskollege hatte dieses Phänomen auch schon bei einer anderen Maschine. Ausweich-Lösung ist, dass man keine Karte nach den F-Karten mehr verbaut, sondern davor einbaut (hier z.B. das PM-E und DO).

Haben auch schon Kontakt zu Siemens deswegen aufgenommen, meinen nur das können sie sich nicht vorstellen und müsste normalerweise gehen. In der nächsten Zeit wird wahrscheinlich wer von Siemens bei uns deswegen vorbeischauen.

mfg

Ich hatte ein ähnliches Problem, als ich das Prozessabbild einer 317-CPU nachträglich vergrößert habe.
Das Löschen der automatisch erzeugten F-DBs hat geholfen.

Gruß
Dieter
 
Der einzige Zugriff auf Safety-DB's erfolgt um den Status des Not-Aus-Eingangs abzufragen FC1002 - Not-Aus.jpg

Dabei wird DB1000.DBX6.0 im Standard-Programm für den MC_Power-Baustein der Sinamics verwendet FB500.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du benutzt im F-Programm Taktmerker
Beachte dazu auch folgendes:
...

  • Wenn Sie im Sicherheitsprogramm Daten aus dem Standard-Anwenderprogramm (Merker oder PAE von Standard-Peripherie) lesen möchten, die während der Laufzeit einer F-Ablaufgruppe durch das Standard-Anwenderprogramm oder ein Bedien- und Beobachtungssystem verändert werden können - z. B. weil Ihr Standard-Anwenderprogramm durch einen höherprioren Weckalarm bearbeitet wird -, müssen Sie dafür eigene Merker verwenden. Diese Merker müssen Sie unmittelbar vor dem Aufruf der F-Ablaufgruppe mit den Daten aus dem Standard-Anwenderprogramm beschreiben. Im Sicherheitsprogramm dürfen Sie dann nur auf diese Merker zugreifen.
    Beachten Sie bitte auch, dass sich Taktmerker, die Sie bei der Projektierung Ihrer F-CPU definiert haben (in HW Konfig im Objekteigenschaftsdialog der F-CPU), während der Laufzeit der F-Ablaufgruppe verändern können, da Taktmerker asynchron zum F-CPU-Zyklus laufen.
  • ..
 
Ich hatte ein ähnliches Problem, als ich das Prozessabbild einer 317-CPU nachträglich vergrößert habe.
Das Löschen der automatisch erzeugten F-DBs hat geholfen.

Hab ich auch schon probiert, Safety-Programm in der CPU (Hardware) komplett deaktiviert und Bausteine gelöscht und dann neu erstellen lassen. Auch keine Änderung.

Mir fällt auf, dass auch die Schnittstelle Sinamics zu Safety nicht gerade ideal ist. Wenn man ein vorhandenes Projekt unter einem anderen Namen abspeichert und dann eine Servo-Achse (mit Extended Safety) rauslöscht, kann man eine Riesen-Prozedur machen, um das ganze Projekt in der Hardware und Safety wieder konsistent zu machen (Hardware und Antriebe exportieren, Neues Projekt, Hardware importieren, Interne Verbindung reparieren, Safety-Programm aktivieren, Antriebe wieder einfügen, usw.).
Keine Ahnung was dabei das Problem ist, aber laut Siemens wissen sie das und das Beste ist immer ein neues Projekt und alles über Ex- und Importieren machen.

mfg
 
Du benutzt im F-Programm Taktmerker
Beachte dazu auch folgendes:

Kann das eine Verfälschung hervorrufen? Die Taktmerker sind bei mir rein nur für das Blinken der Quittier-Lampe.
Hat bis jetzt bei den anderen Maschinen funktioniert... Aber wenn es ein Problem damit geben kann, wie soll ich das abändern? Sind ja schon Merker.. Auf andere Merker wieder umkopieren?

mfg


Edit: Ah versteh glaub ich schon, vor dem Aufruf des Safety-FC im OB35 die eigenen Takt-Merker für das Safety-Programm überschreiben mit den richtigen Taktmerkern...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...


Edit: Ah versteh glaub ich schon, vor dem Aufruf des Safety-FC im OB35 die eigenen Takt-Merker für das Safety-Programm überschreiben mit den richtigen Taktmerkern...
Genau, das Taktmerkerbyte vor dem Aufruf des FC-CALL in ein anderes Byte umladen und das entsprechende Takt-Bit aus dem umgeladenen Byte verwenden

Ist das eine Muting Lampe oder warum steuerst du diese Lampe überhaupt in einem F-Programm an?
 
Diese Lampe ist in einem beleuchteten Taster eingebaut, der wiederrum der Quittiereingang der Safety ist.
Wenn jetzt z.B. eine Schutztür geöffnet wurde, muss man nach dem Schliessen der Schutztür ja mit dem Quittiereingang der Safety mitteilen, dass jetzt quittiert wurde (F_SFDOOR-Baustein).
Und so blinkt jetzt automatisch der Knopf, wenn irgendwas geöffnet oder etwas noch nicht quittiert wurde. Ist leichter zum Bedienen, da man gleich erkennt, wenn der Taster blinkt, draufdrücken bis er ausgeht.
 
Werde das mal mit den Taktmerkern ausprobieren.

Wie siehts jetzt mit dem Zugriff auf den DB1000.DBX6.0 aus? Ist der erlaubt vom Standardprogramm aus? (Post #14)


Edit: Interessant ist aber trotzdem, dass das nur bei dieser Maschine auftritt und bei allen anderen Maschinen (ca. 5-10 in der letzten Zeit) nicht.
 
Zuletzt bearbeitet:
Zurück
Oben