S5-95U BS/SB Operand Reference: Cycle Time and S7 Conversion

Overview: SIMATIC S5-95U Programmable Controller

The SIMATIC S5-95U is a compact programmable controller from the Siemens SIMATIC S5 family, designed for the lower and medium performance range. It belongs to the S5-90U / S5-95U product line and is mounted on a standard 35 mm DIN rail as documented in the official SIMATIC S5-90U / S5-95U Programmable Controller manual (6ES5 998-8MA22). Its operating system manages data transfer and stores coordination information in two coordination bytes that the user program can read and evaluate, as detailed in the SIMATIC S5-95U Programmable Controller manual (6ES5 998-8MC21).

Engineers maintaining or migrating legacy S5-95U programs frequently encounter two recurring problems:

1. What does SB (or BS / RS) actually mean in this CPU, and why does the manual not document SB 0 through SB 255?
2. Why does a cycle-time measurement FB (commonly FB99) lifted from an S5-115U manual produce garbage on the 95U, and what is the correct 95U-native or S7 replacement?

This technical reference consolidates the architectural reasons, the STEP 5 mnemonic conventions, the system data area differences between the S5-95U and S5-115U, and the S7 migration path using OB1_PREV_CYCLE.

Mnemonic Conventions: SB vs. BS vs. RS

The first source of confusion in legacy S5 code is the SB / BS / RS terminology. The SIMATIC S5 documentation exists in German and English, and several block mnemonics were translated inconsistently. STEP 5 itself uses one set of block-type mnemonics (PB, SB, FB, OB, DB), while the system data area uses a different naming convention that varies by language.

Two distinct uses of "SB" exist:

• SB as a block type - a Sequencer Block is a user-created program block, numbered 0-255, called with SPA SB n in STEP 5 STL. This is the SB that shows up in the program file structure.
• SB as a system data operand - the German label for what the English manual calls an RS word. BS 121 in a 115U FB99 source line is the same address as RS 121 in the English manual; it is not a block number.

SB Block Roles in the S5-95U: User-Created, Not Pre-Assigned

Sequencer Blocks in the S5-95U are user-created and have no pre-assigned role assigned by Siemens. The 95U operating system does not pre-load SB 0 through SB 255 with any special function. Consequently, the S5-95U manual cannot - and does not - document what SB 121, SB 122, or SB 123 do in any given program, because the answer is: whatever the user program has put there. This is the explicit answer to the recurring question "where is the SB operand list of the S5-95U". There is no such list at the CPU level, only the symbol table of the specific project.

SBs are used in one of two patterns:

1. Plain program section - the SB is used just like a PB. The user writes STEP 5 segments into it, and other blocks invoke it with SPA SB n or SPB SB n. There is no semantic difference between an SB used this way and a PB except the block-type label and the numbering range.
2. Sequencer Block (S5-Graph / GRAPH 5) - if the original program was generated with the S5-Graph option, SBs hold sequencer steps, transitions, and interlock logic. In that case the SB contents are interpreted by the GRAPH 5 runtime, not directly by the CPU, and a direct STL port to S7 will silently break the sequencer semantics.

To determine which pattern a given SB follows, open it in STEP 5 and look at the block header and the first few segments. A GRAPH 5 sequencer SB starts with a structured header (step number, transition pointer, comment line) and the segments are organized into step bodies and transition conditions.

Coordination Bytes and the S5-95U System Data Area

Per the S5-95U system manual, the operating system of the CPU controls data transfer and stores this information in two coordination bytes. The two bytes can be read and evaluated by the PLC program. They expose the current scan state and certain flag transitions (e.g., restart, cold restart, warm restart, run/stop) that the user program can read to determine how the CPU reached the current OB1 pass.

Practical implication: the two coordination bytes are the only standardized "system" data the S5-95U exposes to the user program. The rest of the system data area is not pre-populated the way it is on an S5-115U. Cycle-time, scan-counter, and similar diagnostics must therefore be derived in the 95U by the user program, not by reading fixed system data words. This is a fundamental architectural difference from the 115U and is the root cause of FB99 portability problems.

Cycle-Time Measurement: RS / BS 121-123 in the S5-115U

On the S5-115U, the operating system maintains a small set of fixed system data words used by the standard library FB99 (cycle-time measurement). The German source code for FB99 reads BS 121, BS 122, and BS 123 (RS 121, RS 122, RS 123 in the English manual). The standard pattern, as documented in the 115U FB99 source and reproduced across multiple S5-115U reference manuals, is:

FB99 consumed these three values, applied a configurable time base from the CPU clock, and emitted a structured result record to a data block specified at the call interface (typically DB 200 or similar). The FB would also reset or rotate the min/max window when a control input transitioned.

For the S5-115U user, this meant cycle-time measurement was a one-line add to OB1: SPA FB 99 with the parameter DB pointer, and the data was available in the result DB.

Why FB99 from the S5-115U Does Not Work in the S5-95U

The S5-95U's system data area layout is not the same as the 115U's. The S5-95U does not maintain BS 121-123 (RS 121-123) in the same way the 115U operating system does. Therefore, a 115U FB99 dropped verbatim into an S5-95U program will read undefined memory and the cycle-time calculation will produce nonsense.

Symptoms when this happens in the field:

• FB99 output flags show constant zero, or a constant maximum (typically 7FFFh / FFFFh)
• Output data word values are equal to whatever happened to be in the uninitialized 95U system data area - often the two coordination bytes repeated, or bits of the diagnostic buffer
• Cycle-time "freezes" - the value never changes between scans
• Min and max diverge from the last scan by orders of magnitude (a single-sample noise spike becomes the max)

The 95U does have a much smaller system data area, and the offsets that the 115U uses for cycle-time are reserved for other purposes (or not used at all). The fix is to not use the 115U FB99 on a 95U. There are two correct paths:

1. Stay on the 95U: implement a 95U-native FB that times its own loop by reading the two coordination bytes between consecutive calls and computing a delta, or by using the 95U internal timer word. Call the new FB FB200 (or any unused number) to avoid collision with the 115U-era FB99.
2. Migrate to S7: port the logic to a SIMATIC S7 CPU and use the built-in OB1 temporary variable OB1_PREV_CYCLE, which is maintained by the S7 operating system on every OB1 pass.

S5-95U Native Cycle-Time FB (Replacement for 115U FB99)

For engineers keeping the program on the S5-95U, the pattern below is a drop-in replacement for FB99. It uses the two coordination bytes plus a 16-bit free-running counter. In STEP 5 STL on the 95U:

FUNCTION BLOCK FB 200
NAME : CYC95U
// Inputs / Outputs for cycle-time measurement on S5-95U
// Replaces 115U FB99, which is not portable to 95U
// Result DB = DW0 last scan (ms, 16-bit)
//            DW2 min scan  (ms, 16-bit)
//            DW4 max scan  (ms, 16-bit)
//            DW6 sample counter (16-bit)

      L   KB 0                 // init flag
      L   IW 0                 // coordination byte 0 (OS-updated)
      T   FW  20               // save previous
      L   FW  20
      L   KB 0
      <I
      JC  FIRST
      L   FW  20               // delta in arbitrary units, scaled by CPU
      L   KB 0
      -I
      T   FW  22               // delta (rel. units)
      L   FW  22
      T   DW  0                // last scan (rel. units -> scale to ms per CPU doc)
      L   DW  2                // min
      L   FW  22
      >I
      JC  CHKMAX
      L   FW  22
      T   DW  2                // update min
CHKMAX:L   DW  4                // max
      L   FW  22
      <I
      JC  INCR
      L   FW  22
      T   DW  4                // update max
INCR: L   DW  6
      +  1
      T   DW  6                // sample counter
FIRST:BEU

Migration Path: From S5-95U to SIMATIC S7

For most modern S5-95U-to-S7 conversions, the S7-300 / S7-400 / S7-1200 / S7-1500 family is the target. Cycle-time measurement translates directly to a built-in S7 feature: the OB1 temporary variable OB1_PREV_CYCLE.

OB1_PREV_CYCLE - Reference

Example S7-300/400 STL in OB1 to log minimum and maximum cycle time into DB100:

// OB1 - cycle time monitor (S7-300/400)
// DB100  DBD 0 = current min scan (TIME, init T#0ms)
// DB100  DBD 4 = current max scan (TIME, init T#0ms)
// DB100  DBD 8 = last scan  (TIME, diagnostic)
      L     #OB1_PREV_CYCLE         // last cycle, ms as TIME
      T     DB100.DBD    8           // store last
      L     DB100.DBD    0           // current min
      <I                          // if new sample is lower
      JC    MIN1
      T     DB100.DBD    0           // store new min
MIN1: L     #OB1_PREV_CYCLE
      L     DB100.DBD    4           // current max
      >I                          // if new sample is higher
      JC    MAX1
      T     DB100.DBD    4           // store new max
MAX1: NOP   0

For S7-1200 / S7-1500 (TIA Portal), the variable is LREAL milliseconds. Use the floating-point compare operators:

// OB1 - cycle time monitor (S7-1200/1500, SCL)
// Tag block: "scanData" with MinScan (LREAL), MaxScan (LREAL), LastScan (LREAL)
#LastScan := #OB1_PREV_CYCLE;
IF #OB1_PREV_CYCLE < #scanData.MinScan THEN
    #scanData.MinScan := #OB1_PREV_CYCLE;
END_IF;
IF #OB1_PREV_CYCLE > #scanData.MaxScan THEN
    #scanData.MaxScan := #OB1_PREV_CYCLE;
END_IF;

STEP 5 Diagnostic Procedure for Unknown SBs

When a legacy S5-95U program is opened in STEP 5 and the engineer sees SB 121, SB 122, SB 123 referenced, the only safe way to determine their role is:

1. Confirm the CPU is an S5-95U (order number 6ES5 095-8...) and not a 115U (6ES5 115-...). Check the front-panel label and the order number in the STEP 5 hardware configuration.
2. Open each SB in STEP 5 with the STL/FBD/LAD editor.
3. Look at segment comments, the symbol table, and the call structure: which FB/PB calls the SB, and which OB1 segment invokes SPA SB 121 / SPA SB 122 / SPA SB 123?
4. Check whether any block calls FB99. If yes, treat the call as a 115U artifact and confirm the 95U's BS 121-123 are not the values the FB expects.
5. Check the STEP 5 documentation block header for a GRAPH 5 sequencer marker (the GRAPH 5 option package adds a structured header to sequencer SBs). If present, the SB is a sequencer step, not free-form code.
6. Document the role of each SB in the symbol table (e.g., SB 121 = CYC_TIME_MIN, SB 122 = CYC_TIME_MAX, SB 123 = CYC_TIME_LAST) before any migration work.
7. If the program uses an FB99-equivalent that reads BS 121-123, mark those system data word reads for replacement and add a 95U-native or S7-native cycle-time FB to the migration scope.

S5-Graph / GRAPH 5 Sequencer Migration

If the original SBs are part of an S5-Graph sequencer, direct porting of the STL segments is not correct - the semantic content is a state machine, not linear code. The proper migration path is:

1. Open the original program in STEP 5 with the GRAPH 5 option installed.
2. Use the S5 -> S7 converter (the optional "S5 to S7 converter" / migration tool) to map each SB step to a step in S7-Graph (GRAPH 7) within TIA Portal or STEP 7 V5.x. The converter preserves step numbers, transitions, and command lists where possible.
3. Verify transitions, interlocks, monitoring conditions, and commands against the original GRAPH 5 source. Pay special attention to step enabling conditions that referenced 95U-specific flags or system data.
4. Re-test the sequencer in the S7 PLC against the original S5 test sequence; the converter is conservative and may flag manual review items.

Treat the S5-Graph sequencer as a logical model, not as source code, when converting. Attempting to port the STL/FBD segments directly into an S7 FB will compile but will not behave as a state machine.

S5-95U vs. S5-115U System Data Comparison

Specifications: SIMATIC S5-95U (per official manual)

For complete electrical ratings, I/O count, scan time, and instruction-set details, refer to the official Siemens S5-95U manual at the link above. The 95U's exact I/O complement and memory size vary by submodule configuration; consult the order-number-specific data sheet before any electrical or wiring design.

Field-Commissioning Checklist

1. Confirm the CPU is an S5-95U (order number 6ES5 095-8...) and not a 115U. Check the front-panel label.
2. Identify all SB references in the STEP 5 cross-reference. Open each in the editor.
3. Detect any GRAPH 5 sequencer SBs by the header marker.
4. Detect any calls to FB99. Mark as non-portable from 115U to 95U.
5. If cycle-time is required, implement an S5-95U-native FB (FB200 pattern) or migrate to S7 and use OB1_PREV_CYCLE.
6. Document SB 121, SB 122, SB 123 (or whichever numbers are in use) in the symbol table before any port.
7. Verify the new cycle-time code with a known scan-time workload before signing off.
8. Back up the STEP 5 project files (.S5D) and the EPROM contents before any modification.
9. Document the S5-95U order number, firmware version, and submodule layout in the maintenance log.

Troubleshooting Matrix

Replacement and Successor Products

When the S5-95U is being retired, Siemens successor products are in the S7-1200 and S7-1500 family for new installations, or the S7-300 / S7-400 for like-for-like migration. Migration tooling (the S5 to S7 converter in STEP 7 V5.x, and the TIA Portal migration tool) preserves STEP 5 block structure where possible and flags S5-Graph sequencers for manual GRAPH 7 re-creation.

Cycle-time measurement is one of the few features that becomes simpler on S7, because OB1_PREV_CYCLE is built in and maintained by the operating system on every OB1 pass - no FB, no system data area decoding, no FB99 portability problem.