Product: Mingcedar CONTROL

Deploy across multiple PCs: from local operation to remote reads | Mingcedar

Scroll horizontally to view the full table

Published 2026-10-25T12:48:42.629741241Z Updated 2026-10-26T19:56:55.638256038Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="distributed-deployment">Deployment tutorial: Deploy across multiple PCs: from local operation to remote reads</h2>

Use two independent Sites to configure local acquisition, connection, Device scope and a first remote read. Browser terminals need no separate Site.

<h3 id="deployment-models">1. Decide each machine’s role</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">Deployment</th><th scope="col">Configuration</th><th scope="col">Runtime relationship</th></tr></thead><tbody>

<tr><th scope="row">Multiple terminals viewing one Site</th><td>Install the complete runtime on a server; other computers, tablets and phones access it through a browser.</td><td>They use the same Site’s runtime content and account permissions.</td></tr>

<tr><th scope="row">Independent Sites collaborating</th><td>Install each server independently, then connect sources and choose capabilities and Device scopes at the consumer.</td><td>Each Site retains its own identity, configuration and data.</td></tr>

<tr><th scope="row">Dedicated IO node</th><td>Use dedicated-node with prepared same-machine data services on loopback addresses and a prepared database schema.</td><td>It provides only IO; the released installer does not support another PC’s database.</td></tr>

<tr><th scope="row">Acquisition standby takeover</th><td>Cross-PC standby requires a verified plan matching the delivered version.</td><td>Joining a remote Site or selecting its IO capability does not create collection standby.</td></tr>

</tbody></table></div>

</article>

<h3 id="deployment-plan">2. Example: A reads pressure from B</h3>

<p>A reads a pressure value collected by B; both Sites run independently. A and B are example names. Use project addresses and Tags.</p>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<tr><th scope="row">Role</th><td>Use B’s pressure value while also running its own Devices if needed.</td><td>Maintain the target Device and Tag and provide collected values.</td></tr>

<tr><th scope="row">Installation and data</th><td>Independent identity, persistent data and runtime services.</td><td>Independent identity, persistent data and runtime services.</td></tr>

<tr><th scope="row">Connection direction</th><td>Join B and select B’s IO on A.</td><td>No reverse join to A is needed for this read.</td></tr>

<tr><th scope="row">PLC connection</th><td>Read by source reference without creating an acquisition copy of B’s Device.</td><td>Maintained by B’s active IO Owner.</td></tr>

</tbody></table></div>

<p class="doc-step-result"><strong>Expected result</strong> Configure B’s acquisition, A’s IO scope and script execution separately.</p>

</article>

<h3 id="deployment-install">3. Install each server</h3>

<ol>

<li>Follow the Windows, Linux or Linux container installation guide. Use compatible versions and packages for each server’s architecture.</li>

<li>Complete database, Redis, runtime service, initial account and license configuration separately, preserving each installation’s data and Node identity.</li>

<li>Use an independent installation identity for an independent Site. Cloning another server’s entire database and Node private key also clones its identity.</li>

<li>Record each published HTTPS address and check runtime services and infrastructure on its System Status page.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Confirm both servers support independent login and operation before connecting them.</p>

<li><a href="/en/hqserver/manual/windows-install/">Windows installation</a></li>

<li><a href="/en/hqserver/manual/linux-install/">Linux and container deployment</a></li>

<li><a href="/en/hqserver/manual/foundation/">Initial configuration</a></li>

</ul>

</article>

<h3 id="deployment-network">4. Prepare access paths</h3>

<ol>

<li>Ensure A’s server can reach B’s Portal HTTPS root address. Verify B → A as well if both directions are needed. Use the actual listening ports.</li>

<li>On browser terminals, verify Portal access and the Screen addresses, ports and HTTPS trust required by the installation.</li>

<li>Ordinary LAN mode uses discovery or Add by Address directly. Explicit project-certificate installations need their project connection configuration first.</li>

<li>For containers, check published addresses, port mappings and persistent directories. Do not give another server an address reachable only inside the container network.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Both browser access paths and the server-to-server connection path are reachable.</p>

<li><a href="/en/hqserver/manual/site-connection-setup/">Connection preparation and troubleshooting</a></li>

</ul>

</article>

<h3 id="deployment-source">5. Prepare a valid collected value on B</h3>

<ol>

<li>Sign in to B. Configure the PLC and pressure Tag in Devices and Tag Management using the actual protocol, address, data type and collection settings.</li>

<li>Save the Device and Tag. Normal saves automatically enter the configuration-application workflow; there is no separate publishing page.</li>

<li>Check PLC Connection and Current Collection on the Device page, then inspect the value, quality and update time in Tag Test.</li>

<li>For the first read, choose a read-only process value that is already being collected continuously. Record its Device and Tag names.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Confirm B has a current value with good quality; a successful save does not prove PLC connectivity.</p>

<li><a href="/en/hqserver/manual/master-data/">Device and Tag configuration</a></li>

<li><a href="/en/hqserver/manual/configuration-release/">Configuration saving and runtime application</a></li>

</ul>

</article>

<h3 id="deployment-consumer">6. Configure remote reads on A</h3>

<ol>

<li>Sign in to A and join B through discovery or B’s Portal HTTPS address on the Sites page.</li>

<li>Open Local Capabilities, add B’s execution node under IO and check that it is selected and available.</li>

<li>Select Browse Devices, choose the target PLC for this Site, preview the change and confirm the saved scope.</li>

<li>In Tag Management → Site Tags, follow the remote-data tutorial below to obtain the Tag’s Source Reference. If you already have its complete TagRef, use it directly.</li>

<li>Save the tutorial’s read-only Python script on A, then select the same remote Tag as a Point Change event source and bind the script. Enable and save the event as described in the tutorial, wait for a valid new change, and inspect the execution record.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> The runtime action executes on A and reads B within the event’s authorized scope. Code-page Run Test resolves local Tags only and cannot validate this cross-Site read path.</p>

<li><a href="/en/hqserver/manual/io-sharing/">PLC scope, source references and Python reads</a></li>

</ul>

</article>

<h3 id="deployment-expansion">7. Add Sites or reverse the direction</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">New use</th><th scope="col">Where and how to configure it</th></tr></thead><tbody>

<tr><th scope="row">C only views existing runtime screens</th><td>Open the existing Portal in C’s browser with the appropriate account; no new Site is required.</td></tr>

<tr><th scope="row">C connects its own Devices</th><td>Install C independently and verify local acquisition, then join C from the Sites that need it.</td></tr>

<tr><th scope="row">A reads both B and C</th><td>Select each source’s IO and PLC scope on A, retaining the full source identity in every reference.</td></tr>

<tr><th scope="row">B also reads A</th><td>Join A on B, select A’s IO and PLC scope, then configure the individual consumer.</td></tr>

</tbody></table></div>

</article>

<h3 id="deployment-advanced">8. Dedicated nodes and cross-PC standby limits</h3>

<p>Windows/Linux dedicated-node requires a prepared schema and same-machine PostgreSQL/Redis managed outside the installer. It does not support remote data services or standby deployment through a database shared by multiple PCs.</p>

<ul>

<li>Collection ownership is coordinated per PLC definition within one Runtime Unit. Independent Sites do not automatically exclude each other when configured for the same physical PLC; collect at the source and share its values.</li>

<li>Same-domain takeover requires valid leases, configuration and eligible candidates. These runtime mechanisms do not mean the released installer provides cross-PC standby.</li>

<li>Joining Sites with separate databases does not create whole-server primary/standby operation or automatic browser-entry failover.</li>

</ul>

<li><a href="/en/hqserver/manual/federation-redundancy/">Acquisition redundancy and takeover conditions</a></li>

<li><a href="/en/hqserver/manual/linux-install/">Linux deployment configuration</a></li>

</ul>

</article>

<h3 id="deployment-acceptance">9. Check the deployment result</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">Check</th><th scope="col">Completion</th></tr></thead><tbody>

<tr><th scope="row">Local acquisition on B</th><td>The Tag has a current valid value; connection, collection and Tag quality can be checked separately.</td></tr>

<tr><th scope="row">Source selection on A</th><td>B’s IO is selected and available, and the target PLC scope is saved and effective.</td></tr>

<tr><th scope="row">Business read on A</th><td>The source reference identifies B, and the Python result can be compared with B’s value and quality.</td></tr>

<tr><th scope="row">Interruption and recovery</th><td>Check interruption behavior in a planned validation environment. After recovery, wait for valid new values and verify the consumers.</td></tr>

<tr><th scope="row">Runtime dependencies</th><td>Record which functions depend on remote sources, along with identities, addresses, versions and Device scopes.</td></tr>

</tbody></table></div>

<p class="doc-step-result"><strong>Expected result</strong> B acquires the target PLC, and A uses its data within the selected scope. Both Sites continue to manage their own configuration and runtime services.</p>

</article>

</div>