S7 - what's wrong with this code which could cause an endless loop?

Trying to identify the cause of cycle time overruns causing the CPU to go into STOP (see SFC12 Thread here I eventually tracked the problem down to this apparently harmless looking bit of code.

If there has been a fault, it should cause a jump to the appropriate screen according to whether the fault was from a 2.88 MJ or 1.44 MJ module using Job 51. On the occasion when I checked the Stack Local Byte zero had a value of 2, implying (if I'm interpreting things correctly), a fault with a 1.44 MJ module. If everything was working correctly, there should not have been any faults, however, if something somewhere was not working as planned, then there is a good reason why a 1.44 MJ module fault could occur - but that's another question and possibly another Thread.

The question this time is simply, in the case where there is a fault, what in this code could cause the cycle time to hit 2000 ms (normal cycle time without a fault is 4 ms). I can't see anything obvious, which could cause an endless loop, or is there something about Job 51 which I don't know, or don't understand?

PS, don't worry about the BEA at the start, that was just put in to check out whether this code was the source of the problem or not, with the BEA in - no crash. This is also the last Thread in the program, or to be more accurate, the next one just holds a BEA.

The third SPB OK28 is a jump back that could cause an endless loop.(NB German mnemonics don't trip off the tongue, I notice your comments are in english though!)

Oops, got it in one, that's what happens when you repeat bits of a program using cut and paste, then forget to modify all the relevant bits.

It should of course be SPB exit!

I must have looked at that at least a dozen times without spotting it.

BTW, SPB stands for Sprung Bedingt, i.e. Jump Conditional.

As far as my comments are concerned, when I started on this project I was religious about commenting everything in German for the benefit of the poor guy in who's lap this lot will fall after I depart. However, somewhere along the line it became obvious that he hasn't a snowball's chance in Hell of coping with this, so I stopped bothering. Any competent German PLC programmer will have more than enough English to understand my comments (which are sometimes half English - half German anyway!).

I do try to keep the Network Titles and comments as well as the Symbol names in German though.

Just a note, but your SET instructions following the BEB's (this is BEC is presume) are redundant as the RLO is set to 1 after a BEC that is not executed.

Thanks, I'm still not quite sure of exactly when I can rely on the RLO being set and when not, so when in doubt I play safe!

By all means do play it safe.
This is a typical source of bugs. I just spent some time hunting down an elusive bug that came from assuming the RLO (aka VKE) being set.
If I manipulate bits within jumps I allways (well now I do !) set the RLO directly before assigning the bit.

Like this:
SET
= "Bit_to_be_set"

or:
CLR
= "Bit_to_be_reset".

If you assume that the RLO is allready set or reset, then the bug can appear at a later time where you change the program and jump to the same location.
In that case the RLO may not be the same, and it is very easy to miss.

Thanks for confirming my impressions Jesper. I got into the habit of playing safe after a few problems that I couldn't explain. Then I found an FAQ on the Siemens website which pointed out that because of the different processors in the 300 and 400 CPUs, they handle Jumps differently. In particular in the 300 the RLO may not be retained under some circumstances. Their recommendation was always to explicitly Set or Reset the RLO in those circumstances.

Funny coincidence

Just in the process of implementing all my error checking and enabled the FB to check the motor driven switches. Initially everything was fine until I drove the the first switch and suddenly it started spurious errors. I did a complete system reset (S/W - not CPU) and everything settled down again - until I drove the next switch! Then off things went again.

Viewing the FB I could see some of the values flickering on and off, even though nothing was changing in the inputs to the FB.

Probably as result of having the last couple of posts in the back of my mind, it didn't take long to find the culprits - two uninitialised Temps!