Step 7 Ereignis-ID:16#39B1 Peripherie Zugriffsfehler bei Prozeßabbildaktualisierung der Eing

azza

Level-1
Beiträge
25
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,


ich habe seit dem Umbau einer Steuerung folgendes Problem:

Ab und an kommt folgende Fehlermeldung :

Ereignis-id:16#39b1
(siehe screenshot Fehler)

Dieser Fehler kommt sporadisch. Er war am Anfang permanent und ich habe auf eine defekte Baugruppe getippt. Doch das austauschen brachte nur sehr kurz Erfolg. Nachdem ich alles getestet habe...erneuern der Komponenten, tauschen des Rack, Cpu, I/O Karten usw.habe ich mal andere Ursachen in betracht gezogen.
Ich habe 3 Movidrives B neu verbaut welche ich "eigentlich" direkt über Ein und Ausgänge ansprechen wollte( siehe Hradw.). Dies hat nicht geklappt da die CPU das wohl irgendwie nicht verpackt. Kurzer Hand ging es dann mit z.b. L PEW122 und T EW122. So konnte ich die FUs direkt ansprechen und anders herum auslesen. Anfangs war alles ok nur dann trat immer häufiger der Fehler Ereignis-id:16#39b1 auf. Ich habe was gelesen das es mit der Zykluszeit zu tun haben könnte und deswegen, weil mir nicht besseres Einfiel anstelle der L und T-Variante die SFC14 und 15 zum kommunizieren der FUs genommen. Siehe da es schien zu funktionieren 24 Std keinen Fehler. Das war Samstag. Heute morgen war wieder das Problem kurzzeitig da und hat sich wie von selbst behoben.Aber irgendwas scheint nicht zu stimmen und ich weiss nicht weiter. Ahso, es äußert sich so das die Komplette Eingangskarte mit der Adresse 30 im Status alle Bits eine 0 haben obwohl die 24V an den Eingängen anliegen.

Ich habe auch gelesen das die Mndest-OB1-Zykluszeit erhöht werden sollte, dieses brachte auch keinen Erfolg. Fakt ist es wurde durch meine Aktionen besser und der Fehler trat seltener auf aber weg ist er nicht.
Alle weiteren Daten wie CPU und Komponenten bitte aus den Screenshots entnehmen...danke
 

Anhänge

  • Hardw.JPG
    Hardw.JPG
    183,3 KB · Aufrufe: 110
  • Fhler.JPG
    Fhler.JPG
    81,5 KB · Aufrufe: 101
Zuletzt bearbeitet:
Ich mag mich irren. Aber ist es nicht so dass wenn ein Remote Teilnehmer ausfällt und du auf die Peripherie schreibst, diese auch einen Zugriffsfehler verursachen wie wenn sie nicht projektiert wären? Dann würde ich auf der Profibusseite suchen.

Vermutlich Teilnehmerausfall, der direkt von den Zugriffsfehlern aus der Historik rausgekickt wird (weil Fehlerobs vorhanden aber nicht ausgewertet).

L PEW 122 T EW 122 ist böse.

Erweitere die Peripherie der CPU einfach dann ist direkter Peripheriezugriff möglich (Standard wäre aber schon 256, trotzdem überprüfen).

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nach Deinen Bildern von heute kommt der Zugriffsfehler bei Zugriff des Betriebssystems auf (P)EW30
Das ist kein Profibusteilnehmer, sondern die Eingangsbaugruppe DI32.. auf Steckplatz 14 des zentralen Racks.
Prüfe da mal auf Steckerprobleme/Wackelkontakt der Baugruppe auf dem Rack und des Frontsteckers auf der Baugruppe.

Viel interessanter als die Zugriffsfehler ist der Diagnosepuffereintrag 1 am Ende der Zugriffsfehler - wie lautet der?

Harald
 
hallo...

steckerprobleme ausgeschlossen. habe ich geprüft. desweiteren habe ich heute mal die karte auf steckplatz 14 mit der von 13 getauscht. siehe da, der fehler ist auch gewandert und jetzt ist es das eingangswort 24 welches probleme macht. danach noch ne ersatzkarte woanders ausgebaut und die von 13 ersetzt. mal schauen.....was die karre morgen frueh zu melden hat. kann mir eigentlich nicht vorstellen das es die karte ist da ich die ja schon mal getascht hatte. abwarten......
 
Oh Mann, welcher Jongleur hat denn diese EA-Adressen festgelegt? :ROFLMAO:
Hat wohl gedacht, bei 'ner 400er kann man aus dem Vollen aasen?!

Harald
 
Und ihr habt bezahlt?
Klasse ich liefere auch so was, nur fehlt die Adresse.

Wer in Gottes Namen liefert so etwas unduchdachtes?


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nicht wirklich. :ROFLMAO:
Das Aufregen bezahlt mir niemand.
Aber die Hochsprachenprogrammierer sollten zulassen, dass nicht jeder in parent und child prozessen denkt.

Ein Programm sollte so sein, dass es der Kunde und dessen Instandhalter es verstehen und auch warten können.
Und wird immer öfter vergessen, leider


bike
 
Nicht wirklich. :ROFLMAO:
Das Aufregen bezahlt mir niemand.
Aber die Hochsprachenprogrammierer sollten zulassen, dass nicht jeder in parent und child prozessen denkt.

Ein Programm sollte so sein, dass es der Kunde und dessen Instandhalter es verstehen und auch warten können.
Und wird immer öfter vergessen, leider


bike

....so sollte es sein! aber vor 9 Jahren hatte keiner drauf geachtet was sich hinter dem Mix aus SCL,KOP,AWL und FUP versteckt hat. Bausteine,Ein- und Ausgänge, Merker und Kommentare falsch deklariert da man, so wie es aussah einfach aus einer bestehenden Anlage, Teile des Porgs per Kopie and Paste zusammengesetzt hatte!
Naja, heute ist man schlauer und jemand von uns würde sich das Prog mal anschauen bevor man es abnimmt. Bzw Vertraglich vereinbaren das, dass Programm die besagten Mängel nicht aufweißen darf. Sofern alles läuft ....super! Nur wenn man anfängt Fehler zu suchen und man landet in einem SCL Baustein in dem Beschleunigungs-Bremsrampen berechnet werden wobei jeder dahinterhängender Umrichter diese Funktion mit sich bringt hört der Spass auf! Aber naja,........


Status meines Problems: Nachdem ich gestern erneut die Karte gewechselt habe ist alles stabil gelaufen. Seltsam ist nur das sich dann innerhalb von 10 Tagen 3 Eingagnskarten verabschiedet haben denn zu Anfang habe ich schon 2 ersetzt und es lief kurzzeitig ja auch. Mal abwarten......
 
Nicht wirklich. :ROFLMAO:
Das Aufregen bezahlt mir niemand.
Aber die Hochsprachenprogrammierer sollten zulassen, dass nicht jeder in parent und child prozessen denkt.

Das hat doch damit nix zu tun. Wen interessiert denn heute noch die Absolutadresse eines Datenpunkts? Die haben vernünftige Symbole zu kriegen und zwar im DB wo die Hardware hingemappt wird.

Bei mir fängt z.B. die Schrankinterne und Blindschaltbildinterne Verdrahtung alles in den ersten Bytes der HW an. Wenn noch was frei ist bleibt dass so. andere Schaltschränke oder Meldungen werden gefälligst über Bit/Byte 100.0 abgelegt, falls für Interne Zwecke mehr Datenpunkte benötigt werden können 8DE Karten, schnell gegen 16er oder 32 oder 64er getauscht werden ohne alles schieben zu müssen.

Schlussendlich kommt dass aber alles in einen DB und im Programm wird außer die Kopiererei auf den DB von überhaupt nirgends auf Peripherieadressen zugegriffen.

Wozu sollte man also alles irgendwie der Reihe nach aufgleisen und Gaps vermeiden? Ich sehe da überhaupt keinen Vorteil.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das hat doch damit nix zu tun. Wen interessiert denn heute noch die Absolutadresse eines Datenpunkts? Die haben vernünftige Symbole zu kriegen und zwar im DB wo die Hardware hingemappt wird.

Bei mir fängt z.B. die Schrankinterne und Blindschaltbildinterne Verdrahtung alles in den ersten Bytes der HW an. Wenn noch was frei ist bleibt dass so. andere Schaltschränke oder Meldungen werden gefälligst über Bit/Byte 100.0 abgelegt, falls für Interne Zwecke mehr Datenpunkte benötigt werden können 8DE Karten, schnell gegen 16er oder 32 oder 64er getauscht werden ohne alles schieben zu müssen.

Schlussendlich kommt dass aber alles in einen DB und im Programm wird außer die Kopiererei auf den DB von überhaupt nirgends auf Peripherieadressen zugegriffen.

Wozu sollte man also alles irgendwie der Reihe nach aufgleisen und Gaps vermeiden? Ich sehe da überhaupt keinen Vorteil.

mfG René

Da beginnt das Verständnisproblem.
Für dich ist dieses und für Andere das andere Symbol logisch und zu zuordnen.
Was macht ein Kunde bzw dessen Instandhalter, wenn sie die ach so logischen klaren Symbole nicht verstehen?
Eine Zahl ist immer und überall eindeutig und wem tut es weh, einfach auch bei den absolut Adressen eine nachvollziehbare Logik zu verwenden?
Mir ist es völlig Wurst, was und wie parametriert bzw programmiert wird, denn Programmieren ist mein Beruf.
Doch ich sehe es bei den Kunden mit welchen Problemen die sich abmühen müssen.

Schön wäre es, wenn ich jeden Müll bauen und, das Wichtigste, verkaufen kann.
Aber wir haben vermutlich die falschen Kunden. :ROFLMAO:


bike
 
Wen interessiert denn heute noch die Absolutadresse eines Datenpunkts?
[...]
Wozu sollte man also alles irgendwie der Reihe nach aufgleisen und Gaps vermeiden? Ich sehe da überhaupt keinen Vorteil.
Den Elektriker/Instandhalter, der bei unterbrochener Produktion schnell Fehler finden soll, den interessieren die absoluten EA-Adressen. Und wenn die Baugruppen-Beschriftungen nicht (mehr) vorhanden sind, dann muß er die Adressen baugruppenübergreifend abzählen können. Was bei der fantasievollen Adressvergabe im Bild #1 nur sehr schwer und zeitaufwendig möglich ist.

Was sollen denn z.B. diese 2-Byte-Lücken und Adresssprünge im zentralen Rack:
Code:
Steckplatz  E-Adresse  A-Adresse

12   DI32     20..23
13   DI32     24..27
[COLOR="#FF0000"]--- Lücke --- 28..29[/COLOR]
14   DI32     30..33
15   DO32              [COLOR="#FF0000"]20..23[/COLOR]
Das war wohl ein Projektant, der nur 8 Finger hat?

Das hat übrigens nichts mit "alten S5 Absolutadressierern" zu tun, sondern mit vermeidbaren Verzögerungen bei der Störungssuche. Eine EA-Adresse E12.3 ist nunmal viel einfacher zu merken und zu finden als Rack + Steckplatz + Klemmennummer.

PS: Schreibt Ihr nur noch Symbole in den Schaltplan statt EA-Adressen und Klemmennummern?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PS: Schreibt Ihr nur noch Symbole in den Schaltplan statt EA-Adressen und Klemmennummern?

Die zwei Byte Lücken sind zwar unschön. Aber stören würden sie mich nicht.

Im Schaltplan tauchen keine EA Adressen auf, da sind nur Baugruppe.Klemmennummer. Die EA Adressen ergeben sich dann durch die Stelle im DB wo die hingemappt werden. und die Symbole sollen sich durch das Objekt ergeben.

Mein Endziel ist dann eigentlich, dass der Programmierer die Absolutadresse garnicht mehr mitkriegt. Der Weg vom HW Eingang bis zum Datenpunkt im DB soll komplett aus der aus Excel exportierten Quelle ergeben.

mfG René
 
Mein Endziel ist dann eigentlich, dass der Programmierer die Absolutadresse garnicht mehr mitkriegt. Der Weg vom HW Eingang bis zum Datenpunkt im DB soll komplett aus der aus Excel exportierten Quelle ergeben.

Das hatten wir doch schon. :rolleyes:
Es gibt inzwischen so viele "Tools" die das machen.
Wir waren schon so weit, dass das PLC Programm aus einer Excel Tabelle, in der die Abläufe definiert waren, geniert wurde.
Doch wir haben es wieder verworfen, das Programm war leider nicht les- und auch nicht wartbar.

Der Hardwareplan und das Programm ist für den Kunden und muss klar und verständlich sein.
Ein Eingang heißt bei uns z.B. :
E 0.0 E_NOT_AUS_IO Rückmeldung Notaus quittiert.
So wie du es schilderst ist das Programmieren nur noch Selbstzweck, wie soll ein Instandhalter einen Fehler finden?


bike

P.S: deshalb habe ich das auch in meiner Signatur so stehen
 
Wo ist bei so einem Code die Fehlersuche schwer?
Code:
      UN    "R1S6P3"      =     "DB MMI USV".bSA_UB1
      U     "R1S6P4"
      =     "DB MMI USV".bSA_BAT
      UN    "R1S6P5"
      =     "DB MMI USV".bSA_AUT
      UN    "R1S6P6"
      =     "DB MMI USV".bSA_RED_BAK

Und wer nennt das oben Programmieren? 2000 Solcher Zeilen kann Excel viel übersichtlicher verwalten und exportieren. Da findet das Programmieren halt erstmal im Excel statt, indem man die Objekte generiert, die NC/NO Invertierungen einträgt etc.

Wo soll man denn da Fehler suchen? Wenn ein Sicherungsautomat auslöst weiss man ja auf welchem Modul (Hier Rack 1 Slot 6 Pin 3) das Signal ankommen sollte. Also schaut man erstmal aufs Modul nach Schema. Programmieren tut man dann die Funktionen. Aber da muss auch keiner die Hardwareadresse wissen, wozu auch den Hardwarepin dem richtigen DB mit dem Richtigen Symbol hat Excel bestimmt richtig zugewiesen.

Diese Zeilen zu tippen sind für einen Programmierer doch keine Herausforderung welche die Bezeichnung Programmieren verdient, die sind einfach nur Zeitaufwendig.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Diese Zeilen zu tippen sind für einen Programmierer doch keine Herausforderung welche die Bezeichnung Programmieren verdient, die sind einfach nur Zeitaufwendig.

Programmierer ist das eine.
Doch scheinbar verstehst du nicht, dass ich aus Sicht der Instandhaltung das anschaue.

Jeder "Programmierer" findet seine Symbolik und sein Programmierstil als toll und einfach und für jeden verständlich.
Doch ist das wirklich so?
Wenn 10 verschiedene Lieferanten seine tollen? Programme abliefert, wer denkt an die Leute, die damit leben müssen?

Nix für ungut.


bike
 
Ich muss da bike schon in vielem recht geben. Aber den Wunsch von vollmi, die EA-Jongliererei zu automatisieren kann man aber auch verstehen. Viele große Firmen haben sich solch ein Tool gebaut, und erzeugen aus der schaltplan-IO-Liste schonmal ein Grundprogramm für die SPS in unterschiedlichem Umfang. Nur ist es wirklich so, dass bei späteren Änderungen alle wies Schwein ins Uhrwerk schauen, weil sie mit dem Tool nicht umgehen können, oder es nicht haben. Dann wird doch wieder von Hand Änderungen ins Programm geschrieben, die dann aber in der "Original-Excel-Tabelle" fehlen...

Interessant ist, dass genau diese Funktionalität in PCS7 enthalten ist. Da gibt's sogar verschiedenen Ausbaustufen IE-Assistent - Advanced Engineering - COMOS. Trotzdem nutzen das auch dort nur die wenigsten, in aller Regel werden die EAs händisch im CFC-Plan eingefügt, evtl. vielleicht noch in der Prozessobjektsicht... Der Grund: es ist für die meisten zu kompliziert und spätestens wenn der erste Instandhalter dran war, ist's vorbei mit den Tools... leider, wie ich finde.

Zum Thema Symbolik: auch sehr interessant in der Praxis ist es manchmal garnicht so einfach, die Symbolik ordentlich zu vergeben, da für den Programmierer am Anfang die Bedeutung aller EAs garnicht so klar ist. Das ergibt sich im Läufe der Programmierung durch Rückfragen, Schaltplan lesen, Feldgerätedoku lesen etc...

Also ich find die Tools gut nur die Anwendung setzt viel Disziplin bei allen Beteiligten voraus.

Gruß.
 
Hallo zusammen,

ich habe nun ein Ähnliches Problem.

Die ETs habe ich untereinander schon getauscht, DI Karte getauscht, Stecker getauscht, Busklotz getauscht.
IP Adresse geändert, Name neu zugewiesen.

Was kann es noch sein?
Alle anderen Baugruppen laufen.

Unbenannt_1.png
Unbenannt_2.jpg
Unbenannt_3.jpg

Unbenannt_5.png



Und bei mir war es am Ende der Port auf dem Switch.
 
Zuletzt bearbeitet:
Zurück
Oben