# Problem QVZ Siemens S5



## JoKu (8 März 2010)

Wer hat eine Idee?
Habe sporalische Stopps der CPU S5 946/947. Im UStack steht dann QVZ
(Quittungsverzug) Adresse 13CB0
Die S5 kann nur per Neustart gestartet werden, wenn zuvor die Spannung weggenommen wurde.
Allerdings kommt es vor, daß der Fehler tagelang nicht auftritt- dann aber wieder alle paar Minuten. An Hardware ist schon einiges getauscht worden: Rack, CPU, Speichermodul und Speicherkartuschen (RAM) H1 Busmodul, CP525,
Spannungsversorgung, usw. >>keine Veränderung.
Kann dies auch ein Softwareproblem sein? Beschreiben einer Speicheradresse???

Wer kann helfen? Benötige dringend Hilfe!


----------



## marlob (8 März 2010)

Könnte auch ein Softwareproblem sein, wenn von einer falschen Adresse gelesen bzw. auf eine falsche Adresse geschrieben wwird. Was steht denn für ein code an der stelle? 
Mit F1(bzw. Shift-F1, weiss ich jetzt gerade nicht genau) kannst du die Adressen einschalten. Im USTACK sollte auch noch der Baustein stehen, wo der Fehler aufgetreten ist


----------



## eNDe (8 März 2010)

*Fehlersuche*

Hallo JoKu,
habe mal im Buch "Automatisieren mit S5-115U" nachgelesen. Daraus kann man schließen:
- Der OB23 wird aufgerufen, wenn der QV bei einem Direktzugriff auf die Peripheriebaugruppen auftritt. Die den QV auslösenden Anweisungen sind LPB/PY, LPW, TPB/PY, TPW, LIR, TIR und TNB.
- Der OB24 wird aufgerufen, wenn der QV beim Aktualisieren des Prozessabbildes oder der Koppelmerker auftritt.
- Sind OB23 und OB24 nicht programmiert, geht die CPU in Stopp. Soll trotz QV weitergearbeitet werden genügt es, die OB23 und OB24 nur mit der Anweisung BE zu programmieren.
- Die den QV verursachende Anweisung wird dann allerdings nicht ausgeführt (!!!), stattdessen der OB23 bzw. OB24 (und dort steht ja dann nur BE). Zusätzlich wird im BS103 die absolute Adresse hinterlegt, bei der der QV festgestellt wurde.
Beispiel:
Der auslösende Befehl laute TPY16 und es gibt den OB23. 
Dann geht die CPU nicht in Stop sondern im BS103 steht KH=F010, bedeutet: 16. Byte im Peripheriebereich macht Probleme.
Aus dem Gesagten ließe sich eine entsprechende Fehler-Suchstrategie entwickeln. 

MfG
eNDe


----------



## Tholu (9 März 2010)

Hallo Joku,

hatte so ein ähnliches Problem schonmal mit einer 135 U. Habe auch Ewigkeiten nach dem Fehler gesucht. Letztendlich hatte einer bei der Siemes Hotline die Idee, jeweils einen Jumper auf den Eingangs- und Ausgangskarten zu entfernen. Leider kann ich dir nicht mehr genau sagen welcher Jumper das war. Der Hintergrund war aber, dass die Spannungsversorgung der einzelnen Karten sporadisch zu Problemen führen kann. Vielleicht weiss einer bei der Hotline was genaueres, wenn man ihn gezielt auf diese Jumper anspricht. Bei mir ist der Fehler jedenfalls nicht mehr aufgetreten. Viel Erfolg!


----------



## sps-concept (9 März 2010)

*Freigabespannung*

Hallo,

das mit dem Jumper betrifft wohl die Freigabespannung F+ / F-. Das findet man im Handbuch.

André


----------



## Tholu (9 März 2010)

Ja genau das war es.
Steht im Systemhandbuch 135U/155U wie André schon richtig angemerkt hat.
Vielleicht hilft das ja weiter.


----------



## JoKu (9 März 2010)

marlob schrieb:


> Könnte auch ein Softwareproblem sein, wenn von einer falschen Adresse gelesen bzw. auf eine falsche Adresse geschrieben wwird. Was steht denn für ein code an der stelle?
> Mit F1(bzw. Shift-F1, weiss ich jetzt gerade nicht genau) kannst du die Adressen einschalten. Im USTACK sollte auch noch der Baustein stehen, wo der Fehler aufgetreten ist


 
Ist zwar meistens die gleiche Adresse (13BC0) aber in dem Baustein sind nur ein paar logische Verknüpfungen. Die können es nicht sein.


----------



## JoKu (9 März 2010)

eNDe schrieb:


> Hallo JoKu,
> habe mal im Buch "Automatisieren mit S5-115U" nachgelesen. Daraus kann man schließen:
> - Der OB23 wird aufgerufen, wenn der QV bei einem Direktzugriff auf die Peripheriebaugruppen auftritt. Die den QV auslösenden Anweisungen sind LPB/PY, LPW, TPB/PY, TPW, LIR, TIR und TNB.
> - Der OB24 wird aufgerufen, wenn der QV beim Aktualisieren des Prozessabbildes oder der Koppelmerker auftritt.
> ...


 

Habe im OB23 und 24 jeweils einen Merker programmiert, die würden gesetzt werden wenn diese Bausteine angespungen werden würden.
Ist aber nicht der Fall?!


----------



## JoKu (9 März 2010)

Tholu schrieb:


> Hallo Joku,
> 
> hatte so ein ähnliches Problem schonmal mit einer 135 U. Habe auch Ewigkeiten nach dem Fehler gesucht. Letztendlich hatte einer bei der Siemes Hotline die Idee, jeweils einen Jumper auf den Eingangs- und Ausgangskarten zu entfernen. Leider kann ich dir nicht mehr genau sagen welcher Jumper das war. Der Hintergrund war aber, dass die Spannungsversorgung der einzelnen Karten sporadisch zu Problemen führen kann. Vielleicht weiss einer bei der Hotline was genaueres, wenn man ihn gezielt auf diese Jumper anspricht. Bei mir ist der Fehler jedenfalls nicht mehr aufgetreten. Viel Erfolg!


 
Danke! Vielleicht ist es das, werde ich kontollieren.


----------



## JoKu (9 März 2010)

eNDe schrieb:


> Hallo JoKu,
> habe mal im Buch "Automatisieren mit S5-115U" nachgelesen. Daraus kann man schließen:
> - Der OB23 wird aufgerufen, wenn der QV bei einem Direktzugriff auf die Peripheriebaugruppen auftritt. Die den QV auslösenden Anweisungen sind LPB/PY, LPW, TPB/PY, TPW, LIR, TIR und TNB.
> - Der OB24 wird aufgerufen, wenn der QV beim Aktualisieren des Prozessabbildes oder der Koppelmerker auftritt.
> ...


 
OB23 und 24 werden nicht angespungen, muß noch was anders sein. Trotzdem Danke!


----------



## eNDe (10 März 2010)

*QVC-Meldung*

Hallo JoKu,
1. Es kann sein, dass deine Karte 946/947 keinen OB23/24 aufruft. Trotzdem würde ich mal im BS103 nachschauen, was dort steht (macht man über einen FB).
2. Was genau ist denn im UStack gekennzeichnet und was genau steht im BStack?
So wie du das Problem beschreibst, kann es nach meiner Meinung nur an einem Wackelkontakt liegen oder, was schwerer zu finden wäre, beißen sich irgendwelche Interrupt-Programme. Letzteres könnte man ausschließen, wenn es diesen Fehler früher noch nicht gab und er erst neuerdings (vielleicht sogar in steigender Häufigkeit) auftritt. 
MfG
eNDe


----------



## Valdi (10 März 2010)

JoKu schrieb:


> Ist zwar meistens die gleiche Adresse (13BC0) aber in dem Baustein sind nur ein paar logische Verknüpfungen. Die können es nicht sein.



Diese Adresse kann wohl schlecht eine Relativadresse sein, sondern wohl eine absolutadresse in Speicher.
Suche im U-Stack: 1. Nach Baustein
                          2. Relative Bausteinadresse
Dann: Ausgabe -> Baustein-> Adresse (z.B. F0) und ohne blank einen Buchstaben h (wie Hex). Also in Etwa F0h. Dann bist du am Baustein an der Unterbrechungsadresse. D.h. der Befehl , der die Unterbrechung verursacht hatte.
Gruss,

Valdi


----------



## Question_mark (10 März 2010)

*Da irrt sich aber einer ganz gewaltig*

Hallo,

[QUOTE="eNDe]habe mal im Buch "Automatisieren mit S5-115U" nachgelesen. Daraus kann man schließen:  [/QUOTE]

Daraus kann man in diesem Falle gar nichts schliessen ....
Aber von Dir auf den Holzweg geführt werden  :sc7:

In der Threaderöffnung ist ausdrücklich von einer 946/947 CPU die Rede. Diese hat eine völlig andere Speicherbelegung und Adressierung als die S5-115U aus dem von Dir erwähnten Berger-Buch. Ist also alles Quatsch ...

Bei der CPU 946/947 befinden sich die Informationen über die letzte Fehlerursache in den Bereichen zwischen BS 75 bis BS 78. Die Aufschlüsselung der Informationen kann man dann im Handbuch selber finden. Ich werde es mir ersparen, diese hier noch detailliert aufzulisten.

Gruß

Question_mark


----------



## Question_mark (10 März 2010)

*Noch ein Irrtum*

Hallo,



			
				Valdi schrieb:
			
		

> Dann bist du am Baustein an der Unterbrechungsadresse. D.h. der Befehl , der die Unterbrechung verursacht hatte.



[Klugscheissermodus an]

Nein, dann ist man an der Adresse, an der die CPU in den Stop Zustand gegangen ist !

Der Befehl, der zum Stop geführt hat, ist *immer* an der Adresse - 1 zu finden, hier also 13BBF. Ein kleiner, aber wichtiger Unterschied.

[/Klugscheissermodus aus]

Gruß

Question_mark


----------



## Der Pfälzer (10 März 2010)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...




:s12:  Richtig !!

Die angegebene Adresse ist diejenige Operation,
die als nächstes ausgeführt werden sollte.


----------



## eNDe (10 März 2010)

*Qvz s5*

Hallo Qm,
prima, von dir zu hören, aber es wäre besser dem Hilfe suchenden konkreten Rat zu geben als sinnlos rumzumotzen. 
Mir stehen zur Verfügung:
- Das Systemhandbuch S5 135U/155U. Dort kommt die Bezeichnung 946 bzw. 947 kein einziges mal drin vor !
- Das von mir zitierte Buch von Berger. Dort wird wenigstens auf den QVZ eigegangen und damit wollte ich helfen.
Wäre supi, wenn in wenigen Minuten ein von dir verfasster, konkreter Hilfehinweis hier erscheinen würde.
Schönen Abend noch!
eNDe


----------



## Question_mark (10 März 2010)

*Sonst noch Fragen ???*

Hallo,



			
				eNDe schrieb:
			
		

> Mir stehen zur Verfügung:
> - Das Systemhandbuch S5 135U/155U. Dort kommt die Bezeichnung 946 bzw. 947 kein einziges mal drin vor !



Das ist aber jetzt eher Dein Problem, und bestimmt nicht meines.



			
				eNDe schrieb:
			
		

> Wäre supi, wenn in wenigen Minuten ein von dir verfasster, konkreter Hilfehinweis hier erscheinen würde.



Dann schau mal hier, was das kleine Fragezeichen vor einer halben Stunde geschrieben hat :



			
				Question_mark schrieb:
			
		

> Bei der CPU 946/947 befinden sich die Informationen über die letzte Fehlerursache in den Bereichen zwischen BS 75 bis BS 78. Die Aufschlüsselung der Informationen kann man dann im Handbuch selber finden.



Das sollte ausreichen, oder hätte ich jetzt noch die 20 Seiten zur Fehlersuche aus dem Handbuch hier reinkopieren sollen ??? Naja, ich habe wenigstens das richtige Handbuch *ROFL*

Gruß

Question_mark


----------

