PR200 Shared Variable for IPP120 and PE210 Start Control

Use one variable in the PR200 for the ventilation start command. Map it once in the network variable table, and have the IPP120 and the PE210 gateway both read and write that same address. The PR200 shares its register memory across its interface slots, so a value written through slot 1 is the value that slot 2 reads. No second variable list is needed for the PE210 slot. In the confirmed setup, the command path through the PE210 worked without adding the second interface to the PR200 project at all.

Why do separate per-port variables break the start command?

The usual first attempt looks like this:

• Configure the PR200 as a slave on both slots, with the IPP120 as master on slot 1 and the PE210 as master on slot 2.
• Build a separate variable set for each slot, such as Pusk_Vent_IPP for the panel and Pusk_Vent_OwenCloud for the gateway.
• Try to join the two variables in logic, then pick one to show on the PR200 display.

Every way of joining them adds a failure mode:

• OR the two bits into the fan output. Start works from either side. Stop does not. If the cloud set its bit, clearing the panel bit leaves the fan running. Each source can only cancel its own command, and the operator at the IPP120 cannot see why the fan refuses to stop.
• Copy one variable into the other every scan. The direction of the copy decides who wins. A write from the "slave" side gets overwritten on the next PR200 cycle and looks like a dropped command.
• Edge-detect each variable and toggle a common latch. This can be made to work. It adds state that the HMI and cloud never see directly, and a missed edge desynchronises the display from the output.
• Choose which variable to show on the PR200 display. Neither is right. Each one reflects only its own source, not the actual commanded state.

All four patterns try to fix a problem the controller does not have.

Why does one variable serve both PR200 slave ports?

The PR200 has one memory image for its network variables. The interface slots are only access paths into that image. They are not separate data areas.

When the IPP120 writes the start bit through slot 1, it changes the same memory cell that the PE210 polls through slot 2. The PE210's next read returns the new value, and OwenCloud shows it after the gateway's poll cycle.

The reverse path also holds. A cloud write lands in that cell, and the IPP120 sees it on its next read.

Each slot has exactly one master, the IPP120 on slot 1 and the PE210 on slot 2. So there is no bus arbitration problem. The only contention is at the data level, and "last writer wins" is exactly the behaviour a start/stop command from three places needs.

In the confirmed setup, the PE210 path worked without a variable list for slot 2 and without adding the second interface in the PR200 settings. Before relying on the same result, read the actual serial parameters for slot 2 from the device and confirm they match what the PE210 expects: baud rate, framing and slave address.

What does each device write and read in the signal chain?

Trace the start command as a single signal with three writers and three readers. When the displayed state and the fan disagree, compare the symptom against this table before touching the program.

A value that is wrong on only one path is a wiring or communication fault on that port. A value that flips back after a correct write is a write-strategy problem in one of the masters. Tuning the PR200 logic fixes neither.

How do I map one start variable to both slave ports?

1. Delete the duplicated per-slot variables, such as Pusk_Vent_IPP and Pusk_Vent_OwenCloud. Create a single start variable in the PR200 project.
2. Assign it a network address in the slave variable table on the interface used by the IPP120. Record the register address and data type exactly as the project assigns them.
3. Do not create a second variable list for the PE210 slot. The shared memory image already exposes the variable on slot 2.
4. Verify the slot 2 serial settings and slave address against the PE210 configuration. If they differ from the defaults, set them explicitly in the project.
5. In the IPP120 project, bind the start button and the status indicator to that one address on the PR200 slave address for slot 1.
6. In the PE210/OwenCloud device configuration, add the same register address, with the same data type, as a read/write parameter.
7. In the PR200 program, route local start/stop logic so that it writes the shared variable, not the fan output directly. Drive the fan output only from the shared variable. Use the same variable on the PR200 display.
8. Configure the IPP120 and cloud controls to write only on operator action. Continuous polling reads are fine; continuous writes are not.

How do I prove every source can start and stop the fan?

Measure the actual state at each point before you adjust anything. Watch the variable in the PR200 online view, the IPP120 indicator, and the OwenCloud parameter value side by side.

1. Start from the IPP120. Confirm the PR200 variable, the fan output and the cloud value all change. Allow one PE210 poll cycle for the cloud.
2. Stop from OwenCloud. Confirm the fan stops and the IPP120 indicator clears on its next read.
3. Start from the PR200 locally. Stop from the IPP120.
4. Start from the cloud. Stop from the PR200 locally.
5. Leave the fan running from one source for several minutes and watch for unprompted reversals. A reversal points to a master that writes cyclically.
6. Pull the slot 1 cable. Confirm cloud and local control still work.
7. Pull the PE210 link. Confirm the panel and local control still work.

Cross-source stop tests are the ones that catch the OR-logic mistake. Same-source start/stop tests will pass even with the broken design.

Which configuration habits bring the conflict back?

• Cyclic writes from a master. An HMI element or gateway parameter set to write continuously turns "last writer wins" into "that master always wins."
• Local logic that bypasses the variable. If a PR200 input energises the output directly, remote status diverges from reality.
• Address or type drift. A different register offset or data type in the PE210 than in the IPP120 creates a second, invisible variable.
• Power-up state. Decide whether the start command should be retained through a power cycle. Set the variable's retention to match that decision, then test it by cycling power with the fan running.

FAQ