GitHub user boeboe created a discussion: S7: item code for a write to a write-protected DB on real CPUs (0x03 ACCESS_DENIED vs 0x0A NOT_FOUND)?
Hi PLC4X team. Your recent change [recognising the S7-300 form of an access-denied response](https://www.mail-archive.com/[email protected]/msg24099.html) (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](https://docs.tia.siemens.cloud/r/simatic_s7_1200_manual_collection_enus_20/programming-concepts/using-blocks-to-structure-your-program/data-block-db)), 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](https://docs.tia.siemens.cloud/r/en-us/v20/editing-devices-and-networks/configure-networks/communication-via-connections/connection-types-s7-300-s7-400-s7-1500/fetch/write-mode-s7-300-s7-400/use-of-fetch/write-s7-300-s7-400)). 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](https://github.com/otfabric/snap7-interop/issues/19). Thanks for any pointers! GitHub link: https://github.com/apache/plc4x/discussions/2850 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
