You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
S7: item code for a write to a write-protected DB on real CPUs (0x03 ACCESS_DENIED vs 0x0A NOT_FOUND)?
#2850
Hi PLC4X team. Your recent change recognising the S7-300 form of an access-denied response (header class/code 0x83/0x04, next to 0x81/0x04 and 0x85) shows you have real-device experience with S7 refusals, so we'd like to ask a related question.
The case: a Write Var to a standard (non-optimised) DB that exists and is readable, but is write-protected in the device (S7-1200 data block), with PUT/GET enabled, so the job itself is accepted.
Question: have you seen what the CPU sends for that item? The item byte 0x03 (DataTransportErrorCode.ACCESS_DENIED in your S7 model), 0x0A (NOT_FOUND), or a header-level error for the whole job? Which CPU families and firmware, if you know?
Background: Siemens documents 03H "Object access is not allowed" and 0AH "The object does not exist, or the range limit was exceeded" (STEP 7 V20, Use of FETCH/WRITE). Snap7 and python-snap7 emulate a read-only DB with 0x0A, as a side effect of how a refused write callback is reported. Our own test server sends 0x03. Before we treat 0x03 as correct, we'd like real-device evidence. Comparison and capture plan: otfabric/snap7-interop#19.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hi PLC4X team. Your recent change recognising the S7-300 form of an access-denied response (header class/code
0x83/0x04, next to0x81/0x04and0x85) shows you have real-device experience with S7 refusals, so we'd like to ask a related question.The case: a Write Var to a standard (non-optimised) DB that exists and is readable, but is write-protected in the device (S7-1200 data block), with PUT/GET enabled, so the job itself is accepted.
Question: have you seen what the CPU sends for that item? The item byte
0x03(DataTransportErrorCode.ACCESS_DENIEDin your S7 model),0x0A(NOT_FOUND), or a header-level error for the whole job? Which CPU families and firmware, if you know?Background: Siemens documents 03H "Object access is not allowed" and 0AH "The object does not exist, or the range limit was exceeded" (STEP 7 V20, Use of FETCH/WRITE). Snap7 and python-snap7 emulate a read-only DB with
0x0A, as a side effect of how a refused write callback is reported. Our own test server sends0x03. Before we treat0x03as correct, we'd like real-device evidence. Comparison and capture plan: otfabric/snap7-interop#19.Thanks for any pointers!
All reactions