S7 - Strange system crash

Now that I've basically got everything functioning as I want it to, I started modifying OB1 to include the various supervision blocks. After doing this and tidying up a few other odds and ends, which included a renewing a few Instance DBs, I saved the project under another name (as I always do whenever I've made more than a very few trivial changes) and took the archive down to the test hall and loaded it into the CPU. On starting up it immediately went into STOP, with the usual problem of overstepping the time limit due to hundreds of I/O errors.

I wasn't too surprised, so bit by bit I commented out all the changes - still no joy. So I went back to the previous version which ran OK, so I started copying all the new or modified files one by one - no problems, continued running fine. Eventually I copied all the Blocks from the new version, but not the System Data - still OK. Then copied the System Data and sure enough, on Restart, straight into STOP.

Now I'm pretty sure I haven't changed anything in OB100 (forgot to check the date before leaving work, unfortunately), but I don't think the problem lies there, since in the Diagnostic window the longest cycle is given as 12 ms (before the 1s cycle that sent it into STOP) which is about right for the first cycle during which all the missing DP-Stations are disabled.

I've tried going into HW-Config and recompiling the FM352-5 S/W and then recompiling and saving HW-Config, however it didn't help.

Anybody got any ideas what the problem might be and more particularly how I can go about tracking it down - the Diagnostic window is not a lot of help this time, although it occurs to me that that I haven't checked the stacks yet.

PS The good news is that I finally got the Trigger S/W in the FM352-5s all working as planned yesterday - most impressive seeing strings of 10 micro-second pulses at ms intervals of your choice coming out of a PLC on the scope! The FM may have been hard work, but now I've got it cracked I'm looking forward to the next opportunity to use it!

But there must be a message in the diagnostics buffer with a description of the stop cause.
It is possible that there are several messages, and the most important one isnt the last one.

From my understanding of the original post, the stop is due to cycle time exceeded. Is this correct ?

I think that the long cycle time may be caused by attempts to access unavailable i/o. This causes calls to OB85.
If so, then there will be entries in the diagnostics buffer with details about the i/o address and the code location where the call to the address is made.

If it is not so, then there must be other reasons for the long cycle time. The diagnosics buffer and the fault stack should help in finding the problem.

Morning all!

This problem is solved, as I suspected the Stack gave me the answer by showing that a block I thought was only being called from OB1 was also being called from somewhere else.

As you suspected Jesper, it is calls to non-existant I/O. The diagnostic buffer is full with 98 calls to I/O followed by the message that the cycle time has been exceeded and the message saying that the CPU is going into STOP.

However, this is just a symptom of the real problem, which, for the benefit of any others having the same problem, I'll post in a new Thread.