ProTool S7-300 Recipe Synchronization: Sequence-Safe Tag Writes

1. Problem Statement: Sequence-Safe Tag Writes from ProTool to S7-300

Engineers commissioning OP/TP panels with Siemens ProTool (ProTool/Pro RT and ProTool CS) frequently need to push a small set of related parameters — typically 3 or 4 values such as a setpoint, a ramp time, a tolerance band and an enable bit — from the HMI to an S7-300 CPU in a single logical operation. The operator presses one key, and the entire parameter set must land in the PLC as a coherent block.

The naive approach is to write the values one after another inside a ProTool script:

\' VB-style ProTool script
SmartTags("Setpoint") = 275
SmartTags("RampTime") = 12.5
SmartTags("Tolerance") = 3.0
SmartTags("Enable")   = 1

Although the script executes in source order on the HMI runtime, the four assignments do not necessarily arrive at the S7-300 in the same communication cycle. Depending on the tag's update class, the underlying MPI/PROFIBUS/Industrial Ethernet bus cycle and the size of each tag (2 bytes INT vs 4 bytes REAL), the S7-300 may see the values land in a different order, or worse, the PLC may act on a partially updated set during the first scan that reads them.

The goal of this reference is to give an engineer three field-proven ways to make these writes deterministic:

1. Use the built-in Recipe object (recommended for static parameter sets).
2. Implement a handshake between the script and an S7-300 function block.
3. Use read-back verification of the previous value before the next write.

All three techniques are valid; the choice depends on the operator workflow, the number of values and the desired engineering effort.

2. Why ProTool Script Tag Writes Are Not Sequence-Safe

ProTool communicates with the S7-300 through one of three channels — MPI, PROFIBUS DP, or Industrial Ethernet (ISO-on-TCP / RFC1006). On each configured acquisition cycle (typical 250 ms, 500 ms or 1 s depending on the update class assigned in ProTool), the runtime engine reads and writes tags in the order it considers efficient: it batches by data area (process image, data block, bit memory) and by data type width.

Concretely, the following non-determinism sources exist:

• Type width mismatch. A 2-byte INT tag and a 4-byte REAL tag are written in separate PDU slots; if the runtime chooses to split them across two adjacent bus cycles, the PLC will see the REAL land in cycle N and the INT land in cycle N+1.
• Update class. Tags with the "On change" class are only sent when their value changes. A subsequent write of the same value is not retransmitted, so the PLC keeps its old copy.
• Operator input race. A script triggered by a key event executes synchronously in the HMI task, but the bus write happens asynchronously; if the operator releases the key while the bus is busy, the runtime can suspend the second value transfer until the next cycle.
• Confirmable writes. ProTool supports both acyclical and cyclical S7 write services. Acyclical (S7 function 5) writes are confirmed by the CPU but introduce a round-trip latency; cyclical writes (S7 function 1) are not confirmed and can be silently lost on a transient bus error.

The Siemens Online Support entry on S7 communication services documents the differences between write data (S7-0x05) and write data with acknowledgment. ProTool uses the unconfirmed variant by default for performance; for guaranteed delivery the engineer must switch to the confirmed service or use a higher-level handshake.

3. ProTool Recipes: The Synchronous Transfer Mechanism

The recipe object in ProTool was designed precisely for this use case. From the ProTool integrated help (Recipes chapter):

"The purpose of recipes is to be able to transfer collectively and synchronously multiple items of data that belong together from the operating unit to the PLC and vice versa."

A recipe groups a fixed list of variables (recipe elements) into a data record. The whole data record is read from, or written to, the PLC in a single confirmed transaction. Inside the record, the variables are transferred in a deterministic order — the order of the recipe element list — and the S7-300 sees them arrive as one indivisible block.

Key characteristics:

• Synchronous. All elements of a data record move in the same cycle; partial updates are impossible.
• Confirmed. ProTool uses the acknowledged S7 write service; if the CPU returns a busy or error response, the HMI surfaces a transfer alarm to the operator.
• Storage location independent. Recipe data records can be stored on the HMI panel (flash / PC hard drive), on a CF card, or on a network share; the storage layer does not affect the order of transfer to the PLC.
• PLC handshake optional. For most recipe transfers, no additional handshake bit is required because the S7 write is already acknowledged. For critical paths, ProTool can also raise a "Transfer complete" bit in the PLC to indicate that the operator may now release the relevant machinery.

For the 3-4 value parameter set described in the problem statement, the recipe is by far the simplest and most robust solution.

4. Configuring a Recipe in ProTool: Step-by-Step

1. Open the project in ProTool CS and select the target panel (e.g., OP270, TP277 — OP/TP families that supported ProTool/Pro RT).
2. In the project tree, right-click Recipes and choose New Recipe. Name it, for example, PARAM_SET.
3. Open the new recipe and add the four elements. For each element, specify the PLC address, data type and display name:

   Element	S7-300 address	ProTool type	Display
   Setpoint	DB100.DBD0 (REAL)	REAL (32-bit float)	"SP [°C]"
   RampTime	DB100.DBD4 (REAL)	REAL	"Ramp [s]"
   Tolerance	DB100.DBD8 (REAL)	REAL	"Tol [K]"
   Enable	DB100.DBX12.0 (BOOL)	BOOL	"Enable"

4. On the Properties dialog of the recipe, enable Transfer with acknowledgment. This forces ProTool to use the confirmed S7 write service and to wait for the CPU ACK before reporting success to the operator.
5. Define a Data Record (e.g., record #1) and enter the default values. The default record is what the operator sees when the recipe view opens.
6. Place a recipe view on a process screen and configure two function keys:
   • F1: Save Record to PLC (system function 39 in ProTool — WriteRecipeDataRecord with tag = 1).
   • F2: Read Record from PLC (system function 40 — ReadRecipeDataRecord).
7. Compile and download to the panel. Test the transfer while monitoring the S7-300 with STEP 7 watch table on DB100.

With this configuration, the four values always arrive at the S7-300 together, in the order Setpoint → RampTime → Tolerance → Enable, and the PLC receives a single acknowledged write request.

5. Handshake-Based Sequential Script Writes

If the operator workflow requires incremental edits (the operator changes Setpoint, presses Enter, then changes RampTime, presses Enter, etc.), a recipe view is awkward. In that case, the script-based approach can be made sequence-safe with a handshake on the PLC side.

The handshake uses three bits in a shared data area (typically a bit in the same data block as the parameters, or in the bit memory area):

The ProTool script then becomes:

\' ProTool script — write 4 values with handshake
Dim sp : sp = 275.0
Dim rt : rt = 12.5
Dim tol : tol = 3.0
Dim en  : en  = 1

\' Wait for previous transfer to complete
Do While SmartTags("PLC_Ack") = 1 Or SmartTags("PLC_Error") = 1
    \' optional timeout handling
Loop

SmartTags("Setpoint") = sp
SmartTags("HMI_Trigger") = 1

Do While SmartTags("PLC_Ack") = 0
    If SmartTags("PLC_Error") = 1 Then Exit Sub
Loop
SmartTags("HMI_Trigger") = 0
SmartTags("PLC_Ack")     = 0

\' ... repeat for RampTime, Tolerance, Enable ...

This pattern is verbose but it is the only script-based method that survives fast operator input and bus latency. A 250 ms timeout on the inner loop is recommended so that the HMI does not freeze if the PLC goes to STOP.

6. S7-300 PLC-Side Handshake Logic

On the S7-300 side, the handshake is implemented in STL inside FB / FC 100 (or in a function block dedicated to parameter loading). The logic is straightforward: on a rising edge of HMI_Trigger, read the parameter slot, validate it, copy it to the process image, and raise PLC_Ack.

\' STL — FB100, network 1: setpoint handshake
A     DB100.DBX13.0      \' HMI_Trigger
FP    M    100.0          \' edge flag
JC    LOAD_SETPOINT

L     DB100.DBD0         \' Setpoint raw
L     0.0
>R                       \' reject negative setpoints
JC    REJECT
T     DB100.DBD20         \' process image — Setpoint
SET                       \' raise ACK
S     DB100.DBX13.1
SPA   DONE

REJECT: SET
S     DB100.DBX13.2       \' raise Error
SPA   DONE

DONE:  NOP 0

FB100 is called once per OB1 cycle. The ACK and Error bits are cleared by the HMI script after consumption, as shown in Section 5. For multi-value transfers, the FB is called four times in sequence (one per parameter) or it is parameterised with a channel index that the HMI script sets before each HMI_Trigger edge.

An alternative pattern — preferred when the number of parameters is large or when the parameter set itself can change at runtime — is to expose a 32-byte parameter buffer in DB100 and let the HMI fill the whole buffer in one confirmed write (the equivalent of a recipe, but driven by the script). The PLC then performs a CRC32 or simple XOR checksum on the buffer and applies all values only if the checksum is correct.

7. Read-Back Verification Method

The read-back method is the simplest script-only sequence guarantee, at the cost of doubling the bus load. After every value write, the HMI script reads the same tag back and compares it to the value it intended to write:

\' ProTool script — write-then-verify
Sub WriteAndVerify(tagName, value, maxRetries)
    Dim i
    For i = 1 To maxRetries
        SmartTags(tagName) = value
        SmartTags("Readback_" & tagName) = SmartTags(tagName) \' trigger readback
        If Abs(SmartTags("Readback_" & tagName) - value) < 0.001 Then
            Exit Sub
        End If
    Next
    SmartTags("Transfer_Error") = 1
End Sub

Read-back protects against the silent loss of cyclical writes but does not, by itself, guarantee that the PLC applied the values in the order the operator intended. To get both properties, the read-back must be combined with the handshake pattern from Section 5, or replaced by the recipe approach from Section 3.

8. Decision Matrix: Recipe vs Script Handshake vs Read-Back

For the original problem — 3 or 4 values that belong together and must arrive as one block — the recipe is the correct answer. The handshake script is the right choice when the operator must edit values one at a time. The read-back is appropriate only for the simplest cases where the engineer accepts the small risk of a sequence fault.

9. Commissioning and Verification Procedure

Regardless of the chosen method, a deterministic commissioning test is required to prove the transfer is sequence-safe under load.

1. Open a STEP 7 watch table on DB100. Add all four target addresses and the three handshake bits. Force the watch table to update every 100 ms.
2. Set the OP/TP update class for the four tags to the fastest supported value (typically 250 ms). Restart the runtime to ensure the new class is active.
3. Disconnect the panel from the PLC and pull a live bus trace using a PROFIBUS / PROFINET analyser. Confirm the write PDU sequence at idle.
4. Run a stress test: an operator presses the write key 50 times in 30 seconds while a second operator varies the values. The watch table must show the four values transitioning in lockstep on every transfer; a partial update indicates a bus or update-class problem, not a script bug.
5. Force a PLC STOP during a transfer. The HMI must report a transfer error and must not freeze. Recover by clearing the error bit and re-issuing the transfer.
6. Document the as-built: the recipe name, data record names, PLC addresses, update class and the step-7 watch table layout. Save this as part of the project documentation so that future service engineers can reproduce the test.

The S7-300 product page on the Siemens global site lists the supported communication modules (CP 343-1 Lean, CP 343-1, CP 342-5) and the maximum PDU size per channel. The PDU size directly affects how many parameters can be packed into a single recipe transfer before the runtime must split the record across multiple bus cycles.

10. Migration Path to WinCC flexible / TIA Portal

ProTool reached end of life with the release of WinCC flexible 2008 SP5. Existing projects are migrated with the ProTool → WinCC flexible converter, which preserves the recipe object and all update classes. The recipe object in WinCC flexible behaves identically to ProTool's; the only practical change is the addition of a Tag synchronized transfer option, which can be enabled to make the recipe transfer wait for an explicit handshake bit on the PLC before the data is considered applied — useful for safety-relevant parameter sets.

The migration is documented in the Siemens Support entry 18839612 ("Migrating from ProTool to WinCC flexible"), and the recipe object is described in detail in the WinCC flexible manual. Engineers planning a migration should validate the recipe's "Transfer with acknowledgment" setting in ProTool first; the converter sometimes loses this checkbox and the symptom is silent partial updates after migration.

FAQ