Product: Mingcedar Scan SCAN

Supported Export Types, Categories, and Rules | Mingcedar Scan

Export Current Result saves one selected file: an Excel .xlsx workbook, UTF-8 .csv, or UTF-8 .json. A non-preview CLI scan separately creates normalized points, Mingcedar-compatible data, generic files, and reports in its output folder.

Published 2026-10-25T12:48:42.622102327Z Updated 2026-10-25T12:48:42.622101616Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="export-support">Rules: Supported Export Types, Categories, and Rules</h2>

Check point sources, symbolic addresses, types, and rules, then prepare files for the target system.

<h3 id="export-support-item-1">Supported export file types</h3>

<p>Export Current Result saves one selected file: an Excel .xlsx workbook, UTF-8 .csv, or UTF-8 .json. A non-preview CLI scan separately creates normalized points, Mingcedar-compatible data, generic files, and reports in its output folder.</p>

</article>

<h3 id="export-support-item-2">Supported point source categories</h3>

<p>Review lists contain resolvable scalar members of standard-layout global and instance DBs, including unverified addresses. Optimized or unknown layouts, out-of-scope or unreadable objects, filtered rows, containers, and non-tag objects are excluded. Communication-import files contain only rows that pass additional verification.</p>

</article>

<h3 id="export-support-item-3">Address scope</h3>

<p>Scans and exports cover DB points. Review rows retain symbolic paths, absolute addresses, and verification status. I, Q, M, optimized or unknown layouts, and members without a constructed address are excluded.</p>

</article>

<h3 id="export-support-item-4">Supported absolute address formats</h3>

<p>DB addresses use bit, byte, word, or double-word notation, such as <code>DB12.DBX4.1</code> for BOOL, <code>DB12.DBB8</code> for BYTE, <code>DB12.DBW10</code> for WORD, and <code>DB12.DBD12</code> for REAL. Valid notation alone does not establish verification; check status, source, type, and length before import.</p>

</article>

<h3 id="export-support-item-5">Supported data types</h3>

<p>Review lists support these scalar types: BOOL; BYTE, SINT, USINT, CHAR; WORD, UINT, WCHAR; DWORD, UDINT; LWORD, ULINT; INT, DINT, LINT; REAL, FLOAT, LREAL; TIME, DATE, TIME_OF_DAY/TOD, DATE_AND_TIME/DT, LTIME, LDATE, LTIME_OF_DAY/LTOD, LDT, DTL; STRING, STRING[n], WSTRING, and WSTRING[n]. CHAR normalizes to BYTE and WCHAR to WORD; the remaining types map to their corresponding common type.</p>

</article>

<h3 id="export-support-item-6">Communication-import eligibility</h3>

<p>Communication imports accept only BOOL, BYTE, USINT, SINT, WORD, UINT, DWORD, UDINT, INT, DINT, REAL, and TIME (including FLOAT normalized to REAL), subject to address-evidence and length checks. CHAR, WCHAR, 64-bit values, strings, and other date/time types remain review-only. Unverified addresses and normalized-code collisions within a device are also excluded, so communication-import counts may be smaller than review-list counts.</p>

</article>

<h3 id="export-support-item-7">Structured object handling</h3>

<p>UDTs, structs, arrays, nested objects, FB/FC objects, DB containers, and complex object references describe engineering structure. When they expand to supported scalar children, those children are exported. Values required for independent collection should be organized as explicit scalar members in the PLC project.</p>

</article>

<h3 id="export-support-item-8">Exported field rules</h3>

<p>GUI export rows contain plcName, symbolicAddress, absoluteAddress, dbNo, ioOffset, bitOffset, dataType, scanRateMs, alarm, trend, addressState, addressSource, addressConfidence, and comment. <code>ioOffset</code> is the byte offset. <code>bitOffset</code> is a separate column populated only for BOOL; bit zero exports as <code>0</code>, while non-BOOL rows leave it empty. JSON also includes export metadata and counts.</p>

</article>

<h3 id="export-support-item-9">Naming and import rules</h3>

<p>Keep symbolic paths unique within a device. Mingcedar Scan Excel, CSV, and JSON are neutral results, not official import templates for arbitrary third-party SCADA/HMI products. Map and validate fields, address mode, and data types against the target product's own specification.</p>

</article>

<h3 id="export-support-item-10">Alarm and trend categories</h3>

<p>Alarm and trend are point-classification flags, not PLC data types. Rule Center name rules set or clear them from display-name and normalized-code fragments. Exports represent them as T/F in the alarm and trend fields.</p>

</article>

<h3 id="export-support-item-11">Purpose of each output</h3>

<p>The GUI creates only the selected .xlsx, .csv, or .json file. In a non-preview CLI output, normalized-tags.json retains the complete normalized fields; tag-import.json, alarm-import.json, trend-import.json, and hqserver-create-tags.json are Mingcedar-compatible data; generic-tags.csv/json support further transformation; report.json records counts, timing, type distribution, and filter reasons; export-manifest.json describes the files. Communication-import files include only eligible addresses and types; normalized and generic files can retain unverified review rows.</p>

</article>

<h3 id="export-support-item-12">Map fields for the target system</h3>

<p>CLI normalized and Mingcedar-compatible data includes deviceCode, areaCode, objectIdentifier, groupCode, symbolicPath, dbNo, byteOffset, bitOffset, absoluteAddress, type, and classification fields. Map and validate these Mingcedar Scan/Mingcedar fields against the target platform's specification.</p>

</article>

<h3 id="export-support-item-13">Symbolic versus absolute addressing</h3>

<p>Symbolic paths identify project members; absolute addresses and verification status support review. Mingcedar communication-import files contain only points that pass address-evidence and type checks. Validate symbolic or absolute access separately against any third-party protocol and import format.</p>

</article>

</div>