Step 7 OB122 Peripheriezugriffsfehler

hub

Level-1
Beiträge
251
Reaktionspunkte
17
Zuviel Werbung?
-> Hier kostenlos registrieren
Was kann passieren, wenn ich generell einen leeren OB122 in meine Programme einbinde?
Ich denke, dass es einen Grund gibt, warum die CPU standardmäßig in STOP geht und nicht andersrum.
 
Ich habe die (also auch die anderen OB's) standardmäßig drin im Code ... als im Grunde leere Bausteine.
Grund hierfür : Ein Antriebsregler ist z.B. nicht immer zeitgleich mit der CPU bereit (sondern etwas später)

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist einer der Fehler Organisations-Bausteine z.B. OB82, OB86, OB122 usw. nicht in der Steuerung enthalten und es kommt zu einem Ereignis wodurch das BS den enstprechenden Baustein (z.B. OB122 Peripheriezugriffsfehler) aufruft dieser aber nicht in der Steuerung vorhanden ist, geht die Steuerung in STOP (aufgerufener Baustein nicht vorhanden).


Kann die Steuerung (das BS) den Baustein aufrufen, wird einfach nur der Code abgearbeitet welcher dort enthalten ist!
Ist kein Code dort entahlten, ist es einfach wie ein BE, es passiert nix ...

Wenn z.B. eine Maschine oder ein Antrieb auf eine Position fahren möchte und z.B. die Endlage nicht erreichen kann, weil z.B. der falsche Peripheriebereich abgefragt wird, würde sich wohl die Maschine / der Antrieb weiter bewegen und es könnte ggf. ein mechanischer Schanden entstehen.
Die Wirkung welche aus der Ursache entstehen kann, kann sehr verschieden sein und sollte ggf. bei der Programmierung (z.B. Kabelbruch des Endschalters) berücksichtigt werden....
 
Zuletzt bearbeitet:
Wenn der Programmierer sich keine Gedanken macht, was passieren soll, wenn ein Sensorwert nicht (mehr) erfasst wird, dann sollte die Steuerung eine Reaktion "auf der sicheren Seite" zeigen. Zumindest sollte der unkontrollierte Blindflug der Steuerung irgendwie beendet werden. (Ein CPU-Stop ist zwar nicht unbedingt die "sichere" Reaktion, aber eine auffällige.)
Auf der anderen Seite gibt es aber einen oft nicht unerheblichen (Kosten-)Druck, einen Produktionsprozess nicht so brutal zu stoppen und trotzdem das Programm "billig" erstellen zu können ..., daher wird das in-Stop-gehen bei neueren SPS-Familien aufgeweicht, und es wird standardmäßig einfach mit Ersatzwerten (z.B. 0) weitergearbeitet - "das wird schon gutgehen" oder nicht so teuer werden. Wenn ein fähiger Programmierer über die beste Reaktion nachdenken soll, dann wird es auf jeden Fall teurer als der billigste Anbieter.

Harald
 
Die Funktion des OB122 ist mir bekannt.

Die Frage ist, was passieren kann, wenn ich bei fehlerfreien Programmen vorsorglich leere OB122 einbinde.
Damit meine ich nicht die Reaktion des Prozesses, sondern das Verhalten der Steuerungskomponenten.

z.B. was passiert
- bei einem defekten Ein-/Ausgang
- bei einer defekten Baugruppe
- obige Fehler bei dezentraler Peripherie
- bei Ausfall einer I/O-Station

Ohne OB122 würde die CPU in STOP gehen. Mit OB122 läuft die CPU weiter.
Welche Auswirkungen kann das haben?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Funktion des OB122 ist mir bekannt.

Die Frage ist, was passieren kann, wenn ich bei fehlerfreien Programmen vorsorglich leere OB122 einbinde.
Damit meine ich nicht die Reaktion des Prozesses, sondern das Verhalten der Steuerungskomponenten.

z.B. was passiert
- bei einem defekten Ein-/Ausgang
- bei einer defekten Baugruppe
- obige Fehler bei dezentraler Peripherie
- bei Ausfall einer I/O-Station

Ohne OB122 würde die CPU in STOP gehen. Mit OB122 läuft die CPU weiter.
Welche Auswirkungen kann das haben?

Habe gerade mein Glasskugel nicht hier bei mir :ROFLMAO:
Was passieren kann, habe ich doch etwas global umschrieben.
Das die Software 100% Fehlerfrei ist glaube ich fast nicht (oder das Programm ist so klein ...)

Was passiert ist ebenfalls abhängig der Programmierung und der Fehlerbehandlung!
Bei z.B. Ausfall einer Baugruppe kommt ja ggf. noch ein anderer OB ins Spiel, welcher dafür eine Reaktion beinhaltet!
Da Du solch eine Frage stellst, hast Du Dir keine Gedanken darüber gemacht und somit meine ich wieder das die Software nicht 100% Fehlerfrei ist 8)

Eigentlich müsstest Du innerhalb des jeweiligen OBs die Diag-Daten auswerten und entsprechend handeln!

Die Abhängigkeit was passieren kann ist somit Abhängig der Anlage, Programmierung und der Software ...
Es kann also von garnix über bischen etwas bis zu :confused::confused::confused: passieren 8)
 
Das die Software 100% Fehlerfrei ist glaube ich fast nicht (oder das Programm ist so klein ...)
Ab welcher Größe ist dann ein Programm nicht mehr fehlerfrei? :p


Da Du solch eine Frage stellst, hast Du Dir keine Gedanken darüber gemacht ...
Da ich diese Frage stelle, zeigt doch, dass ich mir sehr wohl Gedanken darüber mache. Oder?


Eigentlich müsstest Du innerhalb des jeweiligen OBs die Diag-Daten auswerten und entsprechend handeln!
Ist mir bewusst und da bin ich auch ganz deiner Meinung.


Die Abhängigkeit was passieren kann ist somit Abhängig der Anlage, Programmierung und der Software ...
Wie gesagt, meine ich nicht die Auswirkungen auf den Prozesses, sondern das Verhalten der Steuerungskomponenten.

z. B.:
Kann es sein, dass ein Peripheriezugriffsfehler bedingt durch ein Problem in der dezentralen Peripherie
- andere Signale dieser Peripherie beeinflusst?
- Ausgänge ungewollt ein- oder ausschaltet, bzw. nicht mehr abschaltbar sind?

Oder was passiert mit einem Schreibvorgang bei einem Peripheriezugriffsfehler, wenn die CPU weiterläuft?
Kann der Schreibvorgang in einen undefinierten Bereich erfolgen?
 
Ab welcher Größe ist dann ein Programm nicht mehr fehlerfrei?

Kann man diese Aussage an einer Größe fest machen? Ich denke nicht …
Ist ein Programm überhaupt einmal Fehlerfrei oder findet man nicht immer etwas was man besser machen kann?
Hier ne Bedienhandlung besser abfangen, dort eine weitere Verriegelung im Falle x, usw. …
Bei der Größe wie z.B. bei unseren Anlagen und der Menge an Funktionen (PLC und NC), könnte man Jahrelang testen und verbessern.
Da mache ich mir selbst nix vor und sage selbst, meine/unsere SW ist nicht 100% Fehlerfrei ;)


Aber hierrüber brauchen wir eigentlich nicht zu philosophieren ;) du verstehst ja was ich meine!


Wie gesagt, meine ich nicht die Auswirkungen auf den Prozesses, sondern das Verhalten der Steuerungskomponenten.

z. B.:
Kann es sein, dass ein Peripheriezugriffsfehler bedingt durch ein Problem in der dezentralen Peripherie
1) - andere Signale dieser Peripherie beeinflusst?
2) - Ausgänge ungewollt ein- oder ausschaltet, bzw. nicht mehr abschaltbar sind?

Oder was passiert mit einem Schreibvorgang bei einem Peripheriezugriffsfehler, wenn die CPU weiterläuft?
3) Kann der Schreibvorgang in einen undefinierten Bereich erfolgen?


Zu 1)
Möglich, könnte ja ein Problem z.B. am Profibus vorliegen welcher Einfluss auf andere Teilnehmer hat!
Der Peripheriezugriffsfehler kann ja bedingt durch eine Bus- oder Baugruppenausfall herrühren.
Ein Peripheriezugriffsfehler kann laut Siemens ja z.B. durch Programmierfehler oder Baugruppenfehler usw. kommen.

Zu 2)
Wenn ein Fehler in der dez. Peripherie vorliegt, kann natürlich sein das dort die Ausgänge auf „0“ geschrieben werden (z.B. Ausfall des Bus à Firmware der Baugruppe schreibt „0“).
Bei älteren ET200x z.B. war es mal der Fall, das wenn dort ein Teilnehmer ausgefallen ist die Ausgänge durch die Firmware teils nicht auf „0“ geschalten wurden.
Da wurde der letzte Zustand eingefroren. Sollte aber heute nicht mehr vorkommen und diese werden auf 0 geschalten!
Bei manchen Modulen kann man das Verhalten sogar einstellen was man möchte!

Zu 3)
Der Schreibvorgang wird wohl nicht direkt in einen undefinierten Bereich erfolgen, außer du holst dir z.B. eine Adresse aus genau diesem Peripherie Bereich und adressiert aus diesem Lesevorgang einen Schreibvorgang indirekt.
Aber solch etwas fängt man eh ab … Denke also darüber braucht man sich weniger Gedanken machen, das im Normalfall so etwas vorkommt.

Aber 100% kann ich auch nicht sagen was genaue Auswirkungen solch ein Fehler auf die Steuerung hat, da dieser ja wie beschrieben von Seiten der Hardware als auch von der Software (z.B. Bereichslängenfehler beim schreiben) herrühren kann.

Ich hatte auch schon mal einen Programmierfehler und da hat sich die NCU kpl. aufgehängt :ROFLMAO:!
 
Zurück
Oben