Product: Mingcedar Scan SCAN

Search and Rule Matching | Mingcedar Scan

Search symbolic paths, comments, DB numbers, absolute addresses, or offsets with case-insensitive contains matching. Search changes the view only, not results or rules.

Published 2026-10-25T12:48:42.622585891Z Updated 2026-10-25T12:48:42.6225851Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="matching">Match: Search and Rule Matching</h2>

Result-table search and Rule Center use different matchers: the table supports plain contains search plus `%`; Rule Center name rules support plain terms, `*`, `%`, and `?`.

<h3 id="matching-item-1">Plain result-table search</h3>

<p>Search symbolic paths, comments, DB numbers, absolute addresses, or offsets with case-insensitive contains matching. Search changes the view only, not results or rules.</p>

</article>

<h3 id="matching-item-2">Result-table % wildcard search</h3>

<p>When the search text contains <code>%</code>, <code>%</code> means any number of characters. Expressions can match multiple ordered fragments or constrain both prefix and suffix. In real projects, use the site's standard area code, device code, function name, or signal suffix.</p>

</article>

<h3 id="matching-item-3">Rule Center wildcard support</h3>

<p>Keep, exclude, alarm, and trend rules share one matcher. Separate rules with new lines, commas <code>,</code>, or semicolons <code>;</code>. Plain terms use contains matching; <code>%</code>, <code>*</code>, or <code>?</code> preserve the written boundaries.</p>

</article>

<h3 id="matching-item-4">Wildcard examples</h3>

<p>Replace the example placeholders with verified project naming fragments.</p>

<div class="manual-code" data-code-language="text"><div class="manual-code-toolbar"><span>Text</span><span class="manual-code-tools"><small>Text</small><button type="button" data-copy-code data-copied="Copied" data-failed="Select and copy the code" aria-label="Copy code: Text">Copy code</button><span class="manual-code-status" role="status"></span></span></div><pre tabindex="0" class="docs-code-block shiki github-light" style="background-color:#fff;color:#24292e" tabindex="0"><code><span class="line"><span>NAME_TOKEN</span></span>

<span class="line"><span>%ALARM_TOKEN%</span></span>

<span class="line"><span>PREFIX%SUFFIX</span></span>

<span class="line"><span>*_VALUE_SUFFIX</span></span>

<span class="line"><span>?1_NAME_TOKEN</span></span></code></pre></div>

</article>

<h3 id="matching-item-5">Wildcard boundaries</h3>

<p><code>%</code> and <code>*</code> match any number of characters, including zero; <code>?</code> matches one. <code>NAME_TOKEN%</code> matches a prefix, <code>%NAME_TOKEN</code> a suffix, and <code>%NAME_TOKEN%</code> any text containing NAME_TOKEN.</p>

</article>

<h3 id="matching-item-6">What rules match</h3>

<p>Name rules match the display name and normalized code joined by a space, or the available field when one is empty. Wildcard start and end boundaries apply to that combined text. Comments and absolute-address columns are excluded; sample matching and nonmatching rows after applying rules.</p>

</article>

<h3 id="matching-item-7">Recommended rule style</h3>

<p>Start with a broad keep rule to define the main scope, then use exclude rules for backup, history, and temporary objects. Prefer stable naming fragments instead of short incidental text.</p>

</article>

<h3 id="matching-item-8">Separators and whitespace</h3>

<p>Rule Center splits name rules on new lines, commas, and semicolons, then ignores empty or surrounding whitespace. Keep one stable area, device, function, or signal-suffix concept in each rule.</p>

</article>

<h3 id="matching-item-9">Rule priority and classification</h3>

<p>Keep rules define the candidate set and exclude rules have the final say on whether a point remains. Alarm and trend name rules change only classification flags, not PLC data types; their exclude rules clear a previously assigned alarm or trend flag.</p>

</article>

</div>