Check Windows x64, .NET Framework 4.8, TIA Portal, and Automation License Manager Service.
Manual
Mingcedar Scan Troubleshooting
Check the TIA environment, Openness access, scan scope, rules, and export fields in order.
Confirm the engineering environment first
Mingcedar Scan prepares standard DB points from offline TIA projects. Check the environment and permissions before scanning.
Open the target project in the local TIA Portal first. The current Windows user must have Openness access.
Start with one PLC or standard DB; verify addresses and counts before expanding.
TIA Portal, project, or Openness permission is abnormal
A bad environment can produce empty scans, missing fields, or hard failures.
Confirm that the Scan build supports the selected TIA/Openness API. Projects must be V14 or later and no newer than the selected TIA. Older projects are opened with an upgrade attempt; success depends on the TIA API. V21 requires its dedicated build.
Confirm Windows x64 has .NET Framework 4.8 and Automation License Manager Service is running.
Confirm the user belongs to the Siemens TIA Openness group. Permission repair requests administrator elevation and usually requires a Windows sign-out/sign-in.
Avoid read-only, temporary, unstable network, very long, or unusual-character paths. Copy the project to a short local path when in doubt.
Reading still fails after repairing permissions
Openness permission changes usually require a Windows sign-out or a TIA/Mingcedar Scan restart before they fully apply.
After adding the user to the Openness group, sign out and back in, then reopen TIA Portal and Mingcedar Scan.
If the project came from a ZIP file, shared folder, or read-only path, copy it to a writable local path first.
Check project-version and Scan-build compatibility. If migration fails, open and upgrade the project in the matching TIA Portal, then rescan.
Scan result is empty, too slow, or unexpectedly large
Narrow the scan scope first, then check the project tree, PLC, and DB selection.
Confirm the target DB uses standard layout, a real PLC/DB is selected, and the HMI/OPC-access option or rules are not overly restrictive.
Confirm standard layout first; optimized and unknown-layout DBs are skipped as whole blocks. Then check project-tree/PLC/DB scope, Openness reads, access attributes, and rules. Members marked absolute_unverified remain available for review but are excluded from communication import files.
Narrow by PLC, DB range, or tree branch. Scan DBs containing large arrays, UDTs, or deep structures separately.
Use keep rules to define the main set, then exclude diagnostics, temporary variables, and intermediate values.
Large projects scan or export slowly
Validate rules on a small PLC or DB scope, then expand the scan scope after confirming the results.
Scan by PLC or DB; verify layout, addresses, and rules before expanding scope.
Validate scope, fields, and rules on business DBs first, then review backup, history, load-memory, and complex array or UDT DBs.
Use keep rules to reduce the main set, then exclude diagnostics, temporary variables, and intermediates before export.
Before export, sample symbolic addresses, absolute addresses, and data types. Adjust scope or rules before importing into Mingcedar.
Symbolic address, absolute address, or data type looks wrong
Before importing into Mingcedar, confirm field meanings and the intended address mode.
The symbolic path identifies the engineering member, but Rule Center name rules match only display name and normalized code; they do not automatically match the full path or comments.
Standard-layout DB results can include absolute_unverified members for review. Only members with trusted address evidence that also pass type and other checks enter communication import files. Optimized and unknown-layout DBs are skipped as whole blocks.
In GUI exports, `ioOffset` is the byte offset and `bitOffset` is separate. Only BOOL has a bit value; bit zero exports as `0`, while non-BOOL rows leave it empty.
Communication import supports BOOL, BYTE, USINT, SINT, WORD, UINT, DWORD, UDINT, INT, DINT, REAL, and TIME; FLOAT is treated as REAL. CHAR, WCHAR, strings, 64-bit types, and other date/time types can appear for review but are not eligible for communication import.
Names contain unusual characters, duplicates, or invalid Mingcedar identifiers
Check names, code uniqueness, and field formats before import.
Symbolic addresses and import codes should avoid control characters, invisible characters, suspicious punctuation, or path symbols. Clean them through rules or the engineering project before import.
Tag codes must be unique within one device. Generate stable codes by rule, then confirm manually.
UDTs, arrays, and structs should be organized by reviewable scalar members. Values required for independent collection should be represented as explicit scalar members in the PLC project.
The export cannot be imported or fields do not match
Separate neutral GUI exports from CLI Mingcedar-compatible files, then map fields according to the target system's official specification.
Export Current Result saves one .xlsx, .csv, or .json file. Mingcedar tag/alarm/trend compatibility JSON is created only by a non-preview CLI scan.
GUI review files may contain unverified addresses or unsupported communication types. CLI communication imports include only rows that pass address-evidence and type checks.
GUI exports do not contain a `deviceCode` column. Inspect the actual plcName, symbolicAddress, absoluteAddress, dbNo, ioOffset, bitOffset, and dataType fields before designing a conversion.
Excel, CSV, and JSON are neutral results, not official templates for arbitrary SCADA/HMI products. Map and test fields, address mode, and types against the target product's documentation.
DBs or members excluded by optimized/unknown layout, scope, read failure, or rules do not appear in the result. Restored sessions can produce review files, but their address evidence is downgraded. Run a fresh scan before generating communication import files.