A DB must have proven standard layout, be inside the selected scope, and be readable through Openness. Members must resolve to supported scalar types and absolute addresses. Results may include unverified rows; communication-import generation additionally checks address evidence, type support, and code uniqueness.
A DB must have proven standard layout, be inside the selected scope, and be readable through Openness. Members must resolve to supported scalar types and absolute addresses. Results may include unverified rows; communication-import generation additionally checks address evidence, type support, and code uniqueness.
When a DB is missing, first confirm standard layout, then check project-tree, PLC and DB-number scope, Openness read status, the HMI/OPC-access option, and exclusion rules. Optimized and unknown-layout DBs are skipped as whole blocks.
Optimized layouts, unknown layouts, and members without a constructed absolute address are skipped with a recorded reason. Members with an address but insufficient evidence can remain as absolute_unverified review rows; they are excluded from communication imports.
UDTs, structs, arrays, and nested objects in standard DBs are organized as resolvable scalar children. Arrays expand by index. Addresses derived from layout or array strides may remain unverified; successful expansion does not make them eligible for communication import.
Arrays expand by index; duplicate members returned by the engineering interface are removed.
A DB or member needs engineering attributes readable through TIA Openness. The HMI/OPC-accessible option further filters those attributes; it is project-metadata filtering and does not validate a live connection or third-party import.
If an expected point is missing, check the scan report, DB layout, selected scope, read status, access attributes, data type, address resolution, rules, and manual deletions.
