Profibus Datensicherheit

BernhardHartl

Level-1
Beiträge
17
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bräuchte Unterlagen darüber, wie der Profibus seine gesendeten Daten kontrolliert?

Habe nämlich in letzter Zeit auf einer unserer Anlagen Störungen, die eigentlich nur von falsch übertragenen Daten kommen können. Wir übertragen in diesen Fall Daten von einer S7-317 auf einen ABB Roboter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmmm, wir setzen sehr häufig ABB-Roboter in Kombination mit S7 und Profibus ein.
Mit Datenverfälschung haben wir eigentlich noch nie Probleme gehabt!

Könntest Du bitte genauere Angaben machen?
- Profibus-Karte am Roboter (Slave oder Master/Slave)
- Baudrate am Bus
- Einstellungen im S7-Hardwareditor (evtl. Bildschirmausdruck)
 
@ th@mas: der link war sehr hilfreich. danke erstmal.

@ maxl

- die Profibuskarte ist im Slave Betrieb

- Baudrate: 1,5 Mbit/s

- habe mittlerweile auch mit ABB geprochen, die sagen ebenfalls, dass ein Datenverlust ausgeschlossen werden kann. Tatsache ist aber, dass der Roboter Programmteile ausgeführt hat, die er mit korrekten Daten nicht ausführen hättte dürfen. Außerdem ist dieser Fehler bei ca. 20.000 Teilen erst ca. 4-5 mal aufgetreten.
Er hat mir aber den Tipp gegeben, die Filter der Profibuseingänge zu aktivieren, habe aber leider noch keine Möglichkeit gehabt, dies durchzuführen.

- anbei noch die Busparameter

MfG
Bernhard
 

Anhänge

  • profibuseinstellungen.jpg
    profibuseinstellungen.jpg
    84,6 KB · Aufrufe: 257
Wird jede Unterbrechung des Feldbus für diesen Teilnehmer protokolliert ?

Bei der S5 muss man auch mit Dateninkonsistenz im Programm rechnen, wenn längere zusammenhängende Daten übertragen werden und der Feldbus zwischendrin aussteigt. Ich glaube bei S7 muss diese Betrachtung doch auch gemacht werden.

Als Erklärung: Wenn der FB 2 Byte pro Synchronen-Zyklus überträgt, und dann 64 Byte übertragen werden und er beim 8. Byte schon aussteigt.

BTW, was für Filter ? Netzabschluss ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also, die Profibusüberwachungen sind alle aktiviert.

Eine Überprüfung der Daten werde ich morgen - ich stehe auf die Samstag Einsätze :-( - einbauen (Prüfsumme).

Zur Erklärung der Filter: die Profibusschnittstelle des Roboters besteht aus 128 digitalen Eingängen und 128 Ausgängen, die auch als solche betrachtet werden. Jeder Eingang hat ein eigenes Filter, die Zeit kann von 100ms bis ?sek eingestellt werden. Ich werde mal einfach 100ms einstellen. Ich glaube zwar selbst nicht wirklich an einen Erfolg, aber irgendwo muss ich ja ansetzen.
 
Aus Deiner Antwort schließe ich, dass Du eine reine Slave-Karte (max 128 I/O) im Einsatz hast!

Ich hätte noch ein paar Fragen
- Was genau "passiert"
- Kommen digitale Signale an, obwohl sie von der Steuerung nicht gesetzt werden?
- Kommen Bytes oder Wörter inkonsistent an und der Roboter fäht dann eine falsche Offset-Position an?
- welche Firmware-Version hat die 317er?
- basiert die Kommunikation auf Start-Impulsen (Digitales Signal, das z.B. 1 sek. auf 1 ist) oder werden Handshakes eingesetzt?
- Kannst Du mir evetuell die EIO.cfg Datei zusenden, vielleicht hat sich ein Fehler eingeschlichen
- verwendest Du Multitasking am Roboter? (hier sind ein paar Kleinigkeiten zu beachten, sonst gibt es selbtsamste Phänomene)
- bricht die Profibus-Kommunikation hin und wieder ab? (Eintrag im Diagnosepuffer?)


Ein paar Tips:
- die reine Slave-Karte am ABB-Roboter ist sehr langsam, es kann schon mal vorkommen, dass beim einen mal ein Signal 50ms ansteht, bis es der Roboter erkennt, beim nächsten Mal erkennt der Roboter es erst nach 200 oder 300ms
Das fällt besonders bei Anlagen auf, bei denen z.B. 2 IRB140 direkt nebeneinander stehen, beide bekommen zum selben Zeitpunkt die Freigabe, sie fahren aber nicht genau gleich weg

- wird Multitasking eingesetzt, muss im zyklischen Task (Task1) am Ende des Programms eine Wartezeit eingebaut werden, da sonst das Programm hängen bleiben kann
Code:
    !Diese Zeit darf nicht gelöscht werden
    WaitTime 0.01;

- passt die EIO.cfg Datei nicht 100%ig, kann es ebenfalls Probleme geben (hab da auch noch nicht so tief hineingeforscht, hab aber 2 Kollegen, die sich da sehr gut auskennen)
 
1) Was genau "passiert"

Die Robotersteuerung springt manchmal in Programmschritte, in die sie mit korrekten Daten nicht springen dürfte. Da dies aber nur ca. alle 500 Teile einmal geschieht, vermute ich, dass es bei der seriellen Übertragung der Daten zu Fehlern kommt.

2) Kommen digitale Signale an, obwohl sie von der Steuerung nicht gesetzt werden?

3) Kommen Bytes oder Wörter inkonsistent an und der Roboter fäht dann eine falsche Offset-Position an?

zu 2 und 3: es sind schon Störungen aufgetreten, die ich mir eigentlich nur durch Fehler, wie in 2 und 3 beschrieben, erklären kann. Leider war ich aber nie vor Ort, dadurch würde ich auch nicht meine Hand dafür ins Feuer legen.

4) welche Firmware-Version hat die 317er? die aktuellste (wurde vor einem Monat aktualisiert)

5) basiert die Kommunikation auf Start-Impulsen (Digitales Signal, das z.B. 1 sek. auf 1 ist) oder werden Handshakes eingesetzt?

Da ist mir mit Sicherheit ein Fehler passiert. Ich habe hier mit Start-Impulsen gearbeitet, habe aber diese nicht nach einer Zeit abgefragt. Dürfte aber auch keine Fehler verursachen, wenn die Signale korrekt übertragen werden. Wichtige Arbeitsschritte basieren auf einen Handshake, wobei auch hier schon Fehler passiert sind (siehe 2)

6) verwendest Du Multitasking am Roboter? Nein

7) bricht die Profibus-Kommunikation hin und wieder ab? Nein

8 ) Die aktuelle EIO.cfg ist jetzt leider beim Kunden, bekomme sie aber noch diese Woche. Wenn ich sie habe, maile ich sie dir.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur mal so ein Tip:
Ich hatte vor kurzem ein Profibusproblem, das ich durch das Abschalten der Option "Zyklisches Verteilen der Busparameter" beheben konnte. Scheinbar halten nicht alle Slaves diese Option aus.
Vielleicht waere es einen Versuch wert.... :wink:
Gruesse
Ben
 
Ein ABB-Robi hält diese Funktion in der Regel aus!

Mit der Profibus-Anschaltung haben wir bisher nur 2 Probleme gehabt:
- oben beschriebenes Zeitverhalten
- vereinzelte Abstürze bei Baudrate 12 MBaud, verwenden daher bei ABB-Roboter immer 1,5 MBaud
 
ja, also: ich war am vorigen samstag beim kunden und habe die prüfsumme eingebaut sowie die filter aktiviert.
bis jetzt ist "leider" kein fehler mehr aufgetreten. ich glaube, mir bleibt eigentlich nichts anderes übrig, als zu warten. ich hoffe nur, dass es keine äußeren einflüsse waren, die jetzt wieder weg sind.

danke erstmals für eure hilfe

bernhard
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Die Prüfsumme hat mir jetzt den Verdacht bestätigt, dass irgendwo zwischen SPS und Roboter Daten verloren gehen bzw. verfälscht werden. Die Daten kommen in jeden Fall anders an, als gesendet.

@Maxl

Wie würdest du bei dieser Art der Schnittstelle Daten übertragen. In unseren Fall geht es um ca. 30 Parametern in Integerwerten, also 16bit.
Bin mir nämlich nicht mehr sicher, ob meine Variante die Richtige ist, da ich mich da voll auf die Übertragungssicherheit verlasse.
Ich bräuchte einfach einen anderen Denkansatz.

MfG
Bernhard
 
Hast Du in der Zwischenzeit noch neue Erkenntnisse gewinnen können?

Die einzige Erkenntnis, die ich gewonnen habe, ist, dass ABB zugegeben hat, dass im letzten Kahr ca. 6000 fehlerhafte Robotersteuerungen ausgeliefert wurden.
Mit der Datensicherheit hatten wir allerdings trotzdem keine Probleme - das Hauptproblem ist, dass die Steuerung nach Hauptschalter aus nicht mehr ordentlich hochgelaufen ist und der Roboter neu aufgesetzt werden musste.


Es wäre trotzdem noch einmal interessant, wie bei diesem Programm die EIO.cfg aussieht.

Außerdem wäre noch interessant, ob die 32 Integer-Werte dynamisch verändert werden, oder ob über eine längere Zeit immer die gleichen Werte übertragen werden.

Ach ja, noch was: werden die 32 Wörter alle parallel übertragen oder werden diese multiplexed?


mfg
Max
 
PROFIBUS Fehler

bei der Übertragung von PROFIBUS telegrammen können Fehler ja festgestellt werden. Mit der Fehlererkennung bleibt eine kleine Restwahrscheinlichkeit, dass ein Fehler nicht erkannt wird. Die sicherste Methode ist es, auf dem Bus die erkannten Fehler zu zählen. Wenn keine Fehler erkannt werden ist die Wahrscheinlichkeit einen Fehler nicht gesehen zu haben gleich null. Ein Werkzeug das dies kann ist z.B. der ProfiTrace vom http://www.profibuscenter.nl.

Das Fehlerbild deutet auf einen Konsistenzfehler hin: Irgendwo werden die Daten Byteweise verarbeitet und die Werte von zwei verschiedenen Telegrammen falsch zusammengesetzt. Dies ist mir von der S7 nicht bekannt, wenn die Konsistenz der Module auf dem profibus richtig definiert ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

das mit der Konsistenz ist aber so`ne Sache. Da die ABB-Slave-Karte nicht mit SFC 14/15-Kommunikation arbeitet, kann das ja nicht so ohne weiteres eingestellt werden, oder?!

Falls doch, wäre eine Rückmeldung sehr schön.

Gruss
 
Konsistente Daten

Ich kenne leider die ABB Karte nicht. Wenn die Konsistenz in der GSD nicht vorgesehen ist wird es schwierig...

Grundsätzlich haben die SFC14/15 nichts mit dem Slave zu tun. Der Profibus ist immer konsistent. Der Slave mit ASICs hat einen Doppelbuffer, der somit auch immer konsistent ist. Der Master ist da freier. Ohne SFC14/15 können bei Zugriffen grösser als ein Byte Inkonsitenten auftreten. Ein Trick ist auch wenn es nur um 2 oder 4 byte Werte geht diese in STEP7 immer mit Word oder DWord zuzugreifen. Dies entspricht einem SFC14/15 mit 2 resp. 4 byte.
 
Bei Profibus-Teilnehmern, bei denen keine Datenkonsístenz vorgesehen ist, kann man sich mit einem Trick behelfen:
Man legt den E/A Bereich innerhalb des Prozessabbildes, und spricht die Schnittstelle direkt mit E/A bzw. EB/AB an. Somit kümmert sich das Betriebssystem der CPU um die konsistente Übertragung zum Slave.

mfg
Max
 
Zurück
Oben