Siemens s5 Failure

  • Thread starter DeFreitas, Nelson
  • Start date

Thread Starter

DeFreitas, Nelson

Hi everyone, I am hoping someone out there can help me out with a problem I have with a 135U CPU928B; Problem: This cpu has gone into STOP mode about 3 times in the past 12 months. Here is the Istack info. that was gathered. STP STP-BEF NEUZU MWA-ZU OBIGEL 16KWRAM KM-AUS KM-EIN DIG-EIN DIA-AUS QVZ From the information above, what I can gather is that QVZ (Timeout during data exchange with I/Os) is what caused the CPU to go into stop mode. If this assumption is correct how can I narrow down exactly which I/O module is the problem? Thank you for your help. Nelson Defreitas
Nelson, the next time that the processor goes into stop check the BSTACK also. This will give you more information, including the HEX address where the error happened in the program. Please save all this information and send it to me with a copy of your program. Are you using and distributed I/O (profibus etc)? Steve [email protected]

Hakan Ozevin

Dear Nelson, Add the followings to OB24's first lines to detect which I/O has a fault: T FW100 TAK T FW102 After the failure, you will have the following hex numbers in FW100 and FW102: FW100 FW102 1E25 Address byte of faulty output module 1E26 Address byte of faulty input module If problem occurs because of an IP/CP, then you must use OB23 instead. Then you will have 1E23 in FW100. Note that if there was no OB24/23 yet, after you program it as above, the CPU will not stop following the failure. If you want the CPU to stop, you must add STP command to the OB. I hope this helps. Hakan Ozevin

Paulo Picolo

Dear Nelson If you're in Brazil, you can contact Siemens technical support technician (SP) at Phone 11 3833 4919/4921 - - - Caro Nelson Pelo seu nome acredito que seja brasileiro. Portanto sugiro a você entrar em contato com o suporte técnico da Siemens no Brasil (SP). Fone 11 3833 4919/4921 OK Paulo

Eduardo Pelegrin Rodriguez

Hi Nelson, There should be a System Data Word for that CPU where you can check the absolute address of the module on time-out (QVZ)

Helmut Meissner

Hello Mister De Freitas, I checked the S5-Docs, but I found in the SD-Area no hint, where you can read out the missing peripheral adress. You are right, the QVZ (Quittungsverzug) shows you, that there was a timeout, when the plc was reading or writing to an I/O adress. The I have this problems, I check the last module (mostly an IM305 or IM306) - check the dip-switches. If there are additional PLC-racks, check the plugs and wires between them. Sometimes the screws of the plugs are not fixed correct. Check the modules, if they are screwed correct. In one case I had a bad backplane with a missing connection in one of the connectors. It is one the terrible things to find this bug, when the problem is only 3 times a year. Are you sure, that your program has no bug and tries sometimes to read or write to a missing I/O adress. (Monthly reporting, etc.) For checking this make a Xref Greetings Helmut Meissner

Hakan Ozevin

Dear list, I have received the following message in my mail box about my posting above. "From: Pat!!! A whole lot of bullsh** Hakan. Please learne some more of the SS processors and don't put someone one the wrong path. Have a nice day." For anyone who believes that he has the right to send such a message to me, I want to note the followings: 1. For such specific problems, noone can be an expert and everyone should look at the documents, as I did. On pages 5-45 and 5-46 of CPU928B manual, volume 2, it is written that in case of a hardware failure QVZ, system calls Ob23 or Ob24 and writes the address of the module causing QVZ fault into ACCU1 and ACCU2. The code I offered takes these values from the accumulators and writes to the FWs in order to be analysed. 2. Bstack and Istack functions give the location of *software* errors, provided that a succesful cold or warm restart had happened before. In this case, the problem is hardly a software one, because it happens within months. It could be a faulty module which reacts to voltage or EMC changes, a loose terminal, a loose IM cable, an incorrectly plugged module, which I have all seen examples before. But it is 99% a hardware fault. The rest 1% is bugs combined with the user software. Yes, there are bugs in S5 still. 3. We are all trying to help each other without any expectation. Everyone tells his technical opinion and everyone is free to agree or disagree. However, noone has the right to discourage someone to place his technical opinion here. 4. If you have a disagreement to the solution offered, just write it in details and post it here. Do not send private messages accusing about bullsh**, and thus everyone can argue about it. Dare it, then you will be honoured. You cannot promote by putting exclamation marks after your name!!! Best regards, Hakan Ozevin

D.C. Pittendrigh

Hi Helmut and others The 135U manual part no. 6ES5998-1UL22 deals in depth in section 5, chapter 5, with these problems, the diagnosis of Quittungsverzug faults is detailed and easy to understand. The storage of the Istack info is also available in the RS area, this is described in chapter 8 of section 5 and the functions which someone else has described here, (sorry I cannot recall who it was), on how to use the interrupt OB's on processor fault detection, is also described in section 2 of chapter 5, and is in fact the correct approach to diagnosing the problem using PLC software. I couldn't agree with you more on your comment regarding the plugs and screws and IM30x modules, my experience of these faults is the same as your own. There is however one other possibility here, it is also possible to get a QVZ for a card other than an input or output module. This is even more difficult to detect and the establishment of which module becomes extremely difficult as all the ISTACK shows is a memory address where the PLC failed, and this is in the operating system area, there is in this case no other information in the ISTACK at all. I suggest that if this prooves to be the case it will be extremely difficult to find the fault, by any other means than swapping out all the "non-I/O" cards until the fault goes away. We found a problem with an H1 card like this recently, the problem we eventually rectified by changing the SSNR of the card, the real explanation for the problem was never found, but the problem was associated with a change to a 945 CPU on a PLC that had previously been running fault free with a 944B CPU and the same hardware configuration. Regards Donald Pittendrigh
Dear List and Hakan, I also received the same message. This person can only be a very sad individual or a school child. As you state we are all here to help each other and hopefully the likes of him will not stop us from doing this?
Dear Steve, Thank you for your support. Of course our efforts to help each other will not be stopped by such nonsense attacks by people like Pat. Best regards, Hakan Ozevin

D. C. Pittendrigh

Hi All There are odd balls in any community. especially on the Internet. The advice about OB23 and 24 was sound in fact so was the rest of the message. If Pat has a problem with this he can contact me for tuition I have 20 years of experience on Simatic PLCs. Cheers Donald Pittendrigh


Hakan, Please do not feel discouraged. I have received similar messages from people concerning some of my postings. Occasionally they would point out what my error was, but usually, they are just frustrated by their own lack of understanding and although they make accusations regarding your general intelligence and/or the species of your parents, they are typically just plain wrong in their statements regarding the facts. Sadly, these people are like bulk email advertisers. They cannot be helped, as they do not realize the counter-productivity of what they do. The wronger they are, the more vehemently they will declare their rightness, all the while refusing to supply any supporting evidence, just relying on their ability to yell loudly to 'convince' everyone. The best method of dealing with these people is found just to the right and up from your Enter key, and is marked 'Delete'. The sooner the message goes away, the sooner you can forget this individual who obviously does not have any facts to back up his statements. Otherwise, they would have posted what they consider the 'correct' answer. Since all they are doing is shouting, it is easy to ignore them... Meanwhile, continue to offer your advice and share your knowledge. That is what this list is all about!!! --Joe Jansen
When you use the correct diagnostics recomended by Hakan Ozevin, beware, some time ago there was a bad batch of DIP switches used on the I/O cards which resulted in a change of address on a card in run time, (especially with a rapid change in ambient temperature) causing a PLC crash with QVZ. the diagnostics can point you to the wrong address. *IF* this is your problem, a crude but very effective cure is to hard code the address, on the back of the cards, by soldering a link across the correct address DIP switches. In the UK most of these causes have been eliminated.
Your frequency of error made me recall this.