Manual

Deploy across multiple PCs: from local operation to remote reads

Scroll horizontally to view the full table

Deployment tutorial

Deployment tutorial: Deploy across multiple PCs: from local operation to remote reads

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

1. Decide each machine’s role

Scroll horizontally to view the full table

Deployment	Configuration	Runtime relationship
Multiple terminals viewing one Site	Install the complete runtime on a server; other computers, tablets and phones access it through a browser.	They use the same Site’s runtime content and account permissions.
Independent Sites collaborating	Install each server independently, then connect sources and choose capabilities and Device scopes at the consumer.	Each Site retains its own identity, configuration and data.
Dedicated IO node	Use dedicated-node with prepared same-machine data services on loopback addresses and a prepared database schema.	It provides only IO; the released installer does not support another PC’s database.
Acquisition standby takeover	Cross-PC standby requires a verified plan matching the delivered version.	Joining a remote Site or selecting its IO capability does not create collection standby.

2. Example: A reads pressure from B

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

Scroll horizontally to view the full table

Item	Site A	Site B
Role	Use B’s pressure value while also running its own Devices if needed.	Maintain the target Device and Tag and provide collected values.
Installation and data	Independent identity, persistent data and runtime services.	Independent identity, persistent data and runtime services.
Connection direction	Join B and select B’s IO on A.	No reverse join to A is needed for this read.
PLC connection	Read by source reference without creating an acquisition copy of B’s Device.	Maintained by B’s active IO Owner.

Expected result Configure B’s acquisition, A’s IO scope and script execution separately.

3. Install each server

Follow the Windows, Linux or Linux container installation guide. Use compatible versions and packages for each server’s architecture.
Complete database, Redis, runtime service, initial account and license configuration separately, preserving each installation’s data and Node identity.
Use an independent installation identity for an independent Site. Cloning another server’s entire database and Node private key also clones its identity.
Record each published HTTPS address and check runtime services and infrastructure on its System Status page.

Expected result Confirm both servers support independent login and operation before connecting them.

4. Prepare access paths

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.
On browser terminals, verify Portal access and the Screen addresses, ports and HTTPS trust required by the installation.
Ordinary LAN mode uses discovery or Add by Address directly. Explicit project-certificate installations need their project connection configuration first.
For containers, check published addresses, port mappings and persistent directories. Do not give another server an address reachable only inside the container network.

Expected result Both browser access paths and the server-to-server connection path are reachable.

5. Prepare a valid collected value on B

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.
Save the Device and Tag. Normal saves automatically enter the configuration-application workflow; there is no separate publishing page.
Check PLC Connection and Current Collection on the Device page, then inspect the value, quality and update time in Tag Test.
For the first read, choose a read-only process value that is already being collected continuously. Record its Device and Tag names.

Expected result Confirm B has a current value with good quality; a successful save does not prove PLC connectivity.

6. Configure remote reads on A

Sign in to A and join B through discovery or B’s Portal HTTPS address on the Sites page.
Open Local Capabilities, add B’s execution node under IO and check that it is selected and available.
Select Browse Devices, choose the target PLC for this Site, preview the change and confirm the saved scope.
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.
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.

Expected result 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.

7. Add Sites or reverse the direction

Scroll horizontally to view the full table

New use	Where and how to configure it
C only views existing runtime screens	Open the existing Portal in C’s browser with the appropriate account; no new Site is required.
C connects its own Devices	Install C independently and verify local acquisition, then join C from the Sites that need it.
A reads both B and C	Select each source’s IO and PLC scope on A, retaining the full source identity in every reference.
B also reads A	Join A on B, select A’s IO and PLC scope, then configure the individual consumer.

8. Dedicated nodes and cross-PC standby limits

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.

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.
Same-domain takeover requires valid leases, configuration and eligible candidates. These runtime mechanisms do not mean the released installer provides cross-PC standby.
Joining Sites with separate databases does not create whole-server primary/standby operation or automatic browser-entry failover.

9. Check the deployment result

Scroll horizontally to view the full table

Check	Completion
Local acquisition on B	The Tag has a current valid value; connection, collection and Tag quality can be checked separately.
Source selection on A	B’s IO is selected and available, and the target PLC scope is saved and effective.
Business read on A	The source reference identifies B, and the Python result can be compared with B’s value and quality.
Interruption and recovery	Check interruption behavior in a planned validation environment. After recovery, wait for valid new values and verify the consumers.
Runtime dependencies	Record which functions depend on remote sources, along with identities, addresses, versions and Device scopes.

Expected result 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.