S5TIME in Siemens STEP 7 FB: Multi-Instance Timer Declarations

1. Problem Statement: S5TIME Variables Rejected in Multi-Instance FB STAT

When engineering a multi-instance Function Block (FB) in STEP 7 for S7-300/S7-400 CPUs, an engineer may declare an S5TIME variable in the STAT section of a higher-level FB and observe that the editor or compiler refuses the declaration. The typical symptom is one of the following:

• Editor flags the line tim : S5TIME; with a syntax error.
• Program saves but the OB/FB call references report an Invalid data type online.
• Loading to the PLC fails with a CPU diagnostic buffer entry that names the offending instance DB and offset.

The root cause is almost never a missing S5TIME capability in STEP 7. S5TIME is a fully supported elementary data type (16-bit BCD-encoded duration) on S7-300/400 CPUs and is documented by Siemens in the TIA Portal help system. The real failure modes are usually one of three: a syntax mistake in the declaration, a misuse of the TIMER word type (which is not storable in FB instance memory), or a multi-instance offset conflict when the parent FB is itself instantiated multiple times.

This reference documents each failure path, the correct declaration form, the multi-instance rules that govern S5TIME storage, and a robust workaround using an INT timer index and indirect timer call (SP T[#num]) that scales to any number of timers inside a multi-instance FB.

2. How S5TIME Is Stored on S7-300/S7-400

Per the Siemens TIA Portal v20 documentation for the S5TIME (duration) data type for S7-300/S7-400, the S5TIME value is a 16-bit word encoded in BCD. The duration is computed as the product of a time value (0 to 999) and a time basis.

Bits 11..0 hold the time value in BCD (0 to 999). Because the value is BCD, the maximum representable duration is 2 h 46 m 30 s. Step 7 automatically selects the smallest time basis that still represents the entered duration without truncation.

This BCD representation is the key reason the S5 timer instructions (SP, SE, SD, SS, SF, SA, FR) expect their time input as S5TIME or as a constant with the form S5T#1m30s. When the timer is started, the S5TIME word is loaded into the corresponding timer word of the system memory area (T 0 to T 255 on most S7-300 CPUs; T 0 to T 2047 on S7-400 and S7-300 with extended timer count).

3. Why a TIMER Word Cannot Be Stored in FB Instance Memory

A common source of confusion is the difference between:

• S5TIME – an elementary 16-bit data type that holds a duration in BCD. Storable in VAR_INPUT, STAT, TEMP.
• TIMER – a complex data type that refers to a timer word in the system memory area (T 0 .. T 255 / T 2047). It behaves as a pointer to a hardware resource, not as data.

Per the STEP 7 programming reference, the TIMER data type may only be used as a function (FC) parameter and as a local variable in an FB's TEMP section. It must not be declared in the STAT section of an FB, because instance data is persisted in the instance DB and the CPU cannot bind a hardware timer word to a static offset that may be multiplied across multi-instances.

If a programmer writes:

VAR
  t1 : TIMER;   // ILLEGAL in FB STAT
END_VAR

STEP 7 will either flag the line as Data type not allowed in this section or accept the declaration but the online view will show an undefined pointer. The correct approach is to store an INT or WORD representing the timer number and call the timer indirectly.

4. S5TIME in the STAT Section: Correct Declaration

An S5TIME duration can be declared in STAT and is routinely used to parameterize timer instructions from outside. Example for a multi-instance FB called FB_MotorCtrl:

FUNCTION_BLOCK FB 100
TITLE = Motor Control with S5 Timer
VERSION : 1.0
VAR_INPUT
  iStart      : BOOL;
  iStop       : BOOL;
  iOnDelay    : S5TIME;     // S5TIME is legal in VAR_INPUT
  iTimerNum   : INT;        // 0..255, passed from caller
END_VAR
VAR
  sRuntime    : S5TIME;     // S5TIME is legal in STAT
  sTimerNum   : INT;        // persistent timer number
END_VAR
VAR_TEMP
  tRet        : BOOL;
END_VAR
BEGIN
  NETWORK 1  // Persist the timer number on first scan
  TITLE = Latch timer index into instance data
        L  #iTimerNum;
        T  #sTimerNum;

  NETWORK 2  // Start the S5 ON-delay timer
  TITLE = S_ODT with indirect timer call
        A  #iStart;
        AN #iStop;
        L  #iOnDelay;
        SP T [#sTimerNum];     // indirect S5 timer call
        AN #iStart;
        O  #iStop;
        R  T [#sTimerNum];     // indirect reset

  NETWORK 3  // Capture timer status
  TITLE = Read Q output
        U  T [#sTimerNum];
        =  #tRet;

END_FUNCTION_BLOCK

Note the use of SP T [#sTimerNum] – this is the indirect timer call syntax accepted in STL/FBD for S7-300 and S7-400. The bracketed operand is a 16-bit INT or WORD holding the timer number. This form is the cleanest answer to the original question: do not try to store a TIMER; store the timer number as INT, and call the timer indirectly.

5. Multi-Instance FB Rules Affecting Timer Storage

When an FB is used as a multi-instance inside a parent FB, the parent FB's instance DB stores the data for all child FB instances in a single contiguous block. The order of multi-instance declarations determines the offset, and any data type declared in the child's VAR/STAT section must have a well-defined, addressable size.

6. Indirect Timer Calls: SP T[#var], SE T[#var], and the Full Family

All S5 timer instructions support an indirect operand in the timer slot when the CPU is S7-300 or S7-400. S7-400 also supports indirect specification for S7-400-specific extended timers.

The variable in the brackets is a 16-bit integer. Values 0..255 are valid for S7-313/314/315/316; 0..2047 on S7-317/319 and S7-400. Out-of-range values are accepted at compile time but rejected at runtime with CPU diagnostic entry Area length error or Addressing error.

The same indirect-call mechanism lets a single FB host any number of timers, each with a unique number, and the FB can be multi-instanced without conflicts as long as the caller assigns a disjoint timer number range to each instance. A common engineering pattern is to compute the timer number from the instance's DBNO or from a base offset passed at instance creation:

// In caller OB1
CALL FB 100, DB20        // Motor 1, timer base = 0
   iTimerNum := 0

CALL FB 100, DB21        // Motor 2, timer base = 1
   iTimerNum := 1

CALL FB 100, DB22        // Motor 3, timer base = 2
   iTimerNum := 2

This pattern is documented in the Siemens SiePortal knowledge base article Writing & Reading to & from an S5 timer via a FB, which describes an FB that controls three motors with two S5 ON-delay timers each.

7. Why S5TIME in STAT and TIMER in STAT Are Not the Same Question

• S5TIME in STAT – Allowed. Stores a 16-bit BCD duration; useful as a runtime-modifiable time value.
• TIMER in STAT – Rejected. The TIMER type is a 16-bit handle to a hardware timer word in the system area and has no meaning in instance-DB memory.
• INT in STAT – Allowed. Standard for storing a timer number that will be used in an indirect T [#var] call.
• WORD in STAT – Allowed. Equivalent to INT for timer-number storage if you do not need signed interpretation.

If the editor displays Data type TIMER not allowed in this section, the fix is to switch the declaration to INT (or WORD) and use the value as the indirect operand. If the editor displays Unknown identifier S5TIME, the source file is in a non-Latin code page and the keyword is corrupted; the fix is to re-save in ASCII/UTF-8 and re-import.

8. S5TIME vs IEC Timer on Modern S7-1500 CPUs

On S7-1200 and S7-1500, the S5TIME data type and the S5 timer instructions are not available. Siemens replaced them with the IEC 61131-3 timer FBs IEC_TIMER, IEC_LTIMER, TP, TON, TOF, and the TIME / LTIME data types. Multi-instance FBs on S7-1500 are still supported, and an IEC_TIMER instance can be stored in a child FB's STAT section because the new timer type is a system-side data block reference managed by the firmware.

If you must migrate a STEP 7 V5.x project that uses S5TIME inside a multi-instance FB to TIA Portal for S7-1500, perform these steps:

1. Replace every S5TIME declaration with TIME. TIME uses a 32-bit DINT in milliseconds, not BCD.
2. Replace every SP / SE / SD / SS / SF / SA / R / FR T[n] instruction with the corresponding IEC timer call: TP, TON, TOF, etc.
3. Where you used INT to store the timer number, replace with an IEC_TIMER instance variable and call the FB method .TP() or wire it to the IEC block input.
4. Update time constants from S5T#1m30s form to T#1m30s form. Note that S5T# literal syntax is rejected by the S7-1500 compiler.

The Siemens TIA Portal v20 documentation on S5TIME is the authoritative source for confirming that S5TIME remains supported on S7-300/S7-400 but not on S7-1500.

9. Verification: Online View and Monitor/Modify

After loading the corrected FB to the CPU, verify the timer behavior in three passes:

1. Static view – Open the instance DB in STEP 7, switch to Data View, and confirm the S5TIME field shows the loaded duration in BCD. The display format is w#16#wwww when in HEX view; switch to decimal to read the duration directly. The system will show the time basis in the high nibble and the value in the low 12 bits.
2. Online monitor – In Monitor / Modify, set the S5TIME field to a known value such as S5T#5s, set the iStart input to 1, then observe the timer's Q output transition after the correct delay. Repeat for each timer in each multi-instance.
3. Diagnostic buffer – If a timer call fails at runtime, open the CPU diagnostic buffer in STEP 7 (Online > Module Information > Diagnostic Buffer). The entry will name the FB number, the instance DB, and the BCD value of the timer word at the time of the error. Common entries are Area length error reading (out-of-range timer number), Addressing error (timer number negative or > 2047), and Stop due to programming error OB not loaded (no OB121/OB122 in the project to handle the fault gracefully).

10. Common Fault Matrix

11. Best-Practice Pattern for Multi-Instance FB with Timers

Adopt the following conventions whenever a multi-instance FB uses S5 timers on S7-300/400:

1. Decouple the timer number from the instance. Pass it as iTimerNum : INT at each call site, and clamp it inside the FB to the CPU's allowed range.
2. Persist the number in STAT on the first scan. The first scan is detected by the implicit init flag; copy iTimerNum into sTimerNum only when the parent is initializing.
3. Always call FR before SP/SE/SD/SS/SF to avoid the cold-start race on the timer word.
4. Reserve a base offset per multi-instance DB to avoid timer collisions. For three motors each needing two timers, the caller can pass offsets 0, 2, 4, etc.
5. Document the maximum S5TIME in the FB header. The 2 h 46 m 30 s BCD ceiling catches engineers off-guard in long-cycle process applications.
6. Plan for migration to S7-1500 by wrapping the S5 timer call in a method on a wrapper FB. When the target changes, only the wrapper needs replacing.

12. FAQ