OB80 delivers 3 "inputs" that you can query to find the information you seek. You can write that to memory to enable you to extract the information.

.. but somehow I think you are on the wrong path.

Are you aware how the PLC cycle works? Coding a PLC is not the same as coding for a PC. All the code throughout the program needs to be scanned before some preset watchdog time. The PLC code already repeats itself.

So the unseen system in the background may look something like the following:

WHILE TRUE:
    WRITE OUTPUTS
    READ INPUTS
    WATCHDOG TIMER = 0

    EXECUTE USER PROGRAM

Hi mvdkamp,

Since the start information of the time error OB does not provide more information than that mentioned by qwazee, you will not be able to determine the FB causing the timeout by programming. You have to make the CPU stop because of the missing time error OB to find out the reason.

Kind regards
Stefan

Look in the PLC diag buffer for any entries preceding the PLC time error interrupt problem.  Often it can/will show if an interrupt OB has not finished before it was called again.  Handling of this situation is available in the OB properties / attributes and can be configured to add an entry to the diag buffer when 1 or more OB calls get queued up.

Look for any LOOP (SCL/STL) or JMP (LAD/FBD) where the bounds (conditions that ends a loop) are determined at runtime.

Look in cyclic interrupt OBs for excessive amounts of work for very short interval calls (less than 1ms for s7-1500, less than 3ms for s7-1200).

mvdkamp

 Yes,

I see in the test programm the fault identifier. But that "identifier" has no indication, in which FC/FB it goes wrong. That's what we want to know. Then we can look at that piece of code