Switch the GET transfer only at transaction boundaries. Select the requested ANY pointer before starting communication, keep that selection stable until completion, and route received data through a fixed buffer when the counter may change during an active transfer.
Separate connection parameters from data pointers
On an S7-400, the GET block evaluates the addressing parameters ID and R ID only during the first block call. That first call fixes the communication relation with the remote partner until the next warm or cold restart. Changing ADDR_1 or RD_1 does not replace that connection-selection mechanism; keep ID and R ID consistent with the intended partner.
The available evidence does not establish whether every S7-400 version handles an in-progress change to ADDR_1 or RD_1 identically. Treat either pointer as transaction data: select it before initiating the transfer and do not change it while that transfer is active.
Define the counter-to-pointer mapping
| Counter | ADDR_1 selection | RD_1 selection | Transfer length |
|---|---|---|---|
| 1 | P#DB5.DBX0.0 BYTE 64 | P#DB5.DBX0.0 BYTE 64 | 64 bytes |
| 2 | P#DB6.DBX0.0 BYTE 72 | P#DB6.DBX0.0 BYTE 72 | 72 bytes |
A case structure can generate these dynamic ANY pointer values. Reject or inhibit the GET request for counter values outside the two defined cases so that a previous pointer cannot be reused unintentionally.
Use a fixed receive buffer for deterministic routing
- Capture the counter selection when starting the GET operation and hold that selection for the transaction.
- Select the corresponding ADDR_1 pointer from the table.
- Receive the data into one fixed buffer instead of changing RD_1 during communication. To accommodate either specified transfer, the buffer must hold at least 72 bytes, derived from the larger requested length.
- When GET reports DONE, use the captured selection to execute the appropriate SFB20 block-move call: copy 64 bytes for selection 1 or 72 bytes for selection 2.
- Allow the next counter selection only after the completed data has been routed.
This arrangement prevents a counter change during communication from directing completed data to a destination different from the one selected when the transaction began.
Verify pointer switching and data routing
Test each counter state independently. For counter 1, confirm that DONE causes the 64-byte result to be copied to the first selected destination. For counter 2, confirm that DONE causes the 72-byte result to be copied to the second destination. Then change the live counter during a transfer and verify that the captured selection—not the changed value—controls the SFB20 copy.
After a warm or cold restart, also confirm that the first GET call uses the intended ID and R ID, because that call establishes the S7-400 communication relation.
FAQ
Can I change an S7-400 GET ANY pointer with a counter?
Yes. Use a case structure to select P#DB5.DBX0.0 BYTE 64 for counter 1 or P#DB6.DBX0.0 BYTE 72 for counter 2, and hold the chosen selection until the transfer completes.
What happens if the counter changes before GET reports DONE?
The destination decision can become inconsistent with the transaction that was started. Capture the counter at the start, receive into a fixed buffer, and use the captured value to select the SFB20 copy after DONE.
When does S7-400 GET evaluate ID and R ID?
It evaluates ID and R ID at the first block call. Those values define the remote communication relation until the next warm or cold restart.