Yes, the panel can bridge the two devices. The PLC sets a request bit, an event on the panel copies each controller value into a PLC address, one copy action per value, and a final action writes the bit back to zero. Copies first, reset last, and check each mapping on its own.
Yes, a panel that talks to both a temperature controller and a PLC can move controller values into PLC memory. The method is a handshake. The PLC raises a request bit, an event on the panel watches that bit and copies each controller value to a PLC address, and a final action writes the bit back to zero. The order is the whole design: copies first, reset last, one action per value. This page walks the complete job: how often to request, what to prepare on each side, the event build, a worked scaling example, and the checks that prove each mapping. Editor menus differ between HMI packages, so each piece is named by what it does: a trigger, copy actions, a reset.
Why doesn't the displayed controller tag reach the PLC?
The screen object reads the controller tag and stops there. Display data moves one way, from the controller to the panel, so a value can sit on the screen all day while the PLC memory set aside for it stays at zero. In this arrangement the panel is the only device with a working connection to both the controller and the PLC. So the panel is the bridge, and a bridge needs instructions. HMI editors document an event action, commonly called a tag copy, that moves the current value of a source tag to a destination tag, including from one controller to another. That action is the write the display never performs. If your real job is sending one operator-typed string, that is a smaller task with its own route for passing a recipe name from a panel to a PLC variable.
How often should the PLC request a copy?
Every 5 seconds for temperature values: 12 transfers a minute, each carrying a handful of numbers. That is far more often than a heated process changes. What moves the number: if the PLC alarms on rate of change or you trend the values, drop to 1 or 2 seconds, and accept that at 1 second most copies repeat the previous number. Going faster than the controller refreshes its own registers buys nothing. Each cycle costs one event execution plus one read per source tag and one write per destination. A four-value list at 5 seconds is eight tag operations every 5 seconds, a light load for one panel. You can also skip the clock entirely: toggle the request bit from a value-change event on the tag the operator edits, and the copy follows the action instead of the timer.
What do you need before you start?
A list of every value with its controller tag and its PLC destination, a request bit the PLC logic owns, matching data types with a scaling decision for each fractional value, and both device connections working in one project. Prepare four things:
- Source and destination per value. Confirm the tag you display is the process value, and that its destination register is reserved and untouched by existing PLC logic.
- The request bit. One spare bit that your one-shot sets and the event's reset clears, and that nothing else touches.
- Data types. A fractional temperature going to integer memory needs its scale factor chosen now, because a plain copy drops the decimal. The arithmetic is the same job as passing whole numbers from a float into 16-bit integers.
- Connections. The controller tags and the PLC addresses sit on two device connections in the same project, each tag addressed per its device, the per-device tag discipline used when one panel serves several PLCs.
How do you set the PLC request bit?
Use a repeating timer and a one-shot so the set condition lasts a single scan: the bit goes to 1, stays 1, and waits for the event's reset action to clear it. The one-shot matters because of what happens without it. If the set condition stays true as a level, the event clears the bit and your logic sets it again on the next scan. The panel then copies the same list many times a second. One edge per interval, one copy per interval. The bit returning to 0 is also your completion signal, the same role a handshake tag plays when a PLC catches a recipe load. This raise, answer, clear sequence is the poll-and-zero handshake a PLC uses when it hands a block of data to another device: the requester raises a location, the responder answers and zeroes it, and no interrupt is needed on either side.
How do you build the event and its copy actions?
Create one event that watches the request bit, give it one copy action per value with the controller tag as source and the PLC address as destination, and put the action that writes zero to the bit after all the copies. In the panel project:
- Open the events area of your editor. Editors name this differently; the piece you want is an event that runs actions when a tag changes.
- Set the trigger to the request bit changing to 1. If the editor offers a choice between an edge and a level, choose the edge.
- Add the first copy action: source is the controller's process value tag, destination is its PLC register.
- Repeat step 3 for every remaining value, in a fixed order you write down.
- Add the final action: write 0 to the request bit.
- Save, download the project to the panel, and put the timer rung in the PLC, with the machine in a safe state under your site's change control.
The reset position is the one thing installers get wrong. Keep it last, so the bit stays 1 until every copy has executed. An early reset opens a window where a fresh trigger slips in before the list finishes.
How does a full transfer run in an example?
One oven zone: the controller holds 245.7 °C with a 250.0 °C setpoint, the panel copies four values into PLC registers every 5 seconds, and each fractional value goes to a floating-point register so the decimal survives. The values and destinations:
| Value | Source | Destination | Lands as |
|---|---|---|---|
| Process value | Controller PV tag | Real register | 245.7 |
| Setpoint | Controller SP tag | Real register | 250.0 |
| Output | Controller output tag | 16-bit integer | 37 |
| Alarm status | Controller status tag | 16-bit integer | 0 |
Four values means 4 copy actions plus 1 reset, 5 actions per cycle. At the 5 second interval that is 12 cycles and 60 actions per minute. The cycle itself: the timer one-shot sets the bit, the panel's next tag update sees it, actions 1 through 5 run in order, the bit reads 0 again, and a falling-edge rung in the PLC stamps the row as fresh.
If the logging table only accepts 16-bit integers, pick the scale before the first copy. At 0.1 °C per count, 245.7 °C becomes 245.7 × 10 = 2457 counts, and the signed 16-bit ceiling is 32767 counts = 3276.7 °C, so the range fits with room to spare. At 0.01 °C per count the same reading is 245.7 ÷ 0.01 = 24570 counts, which still fits. But the ceiling drops to 32767 × 0.01 = 327.67 °C, and a 350 °C process overflows. When those numbers also belong on a board the whole floor sees, our shop-floor screens run offline playback or your own Android app; moving the values onto that board is a separate link.
How do you check the transfer worked?
Force one request with the panel online and watch three things together: every destination takes its source value, the request bit returns to 0, and a second forced request transfers again. Check each mapping on its own; one good value tells you nothing about the next one. A real destination should read 245.7 when the source reads 245.7 °C. A destination reading 245 means the copy dropped the decimal into integer memory, so the register type is wrong for that value. An integer-in-tenths destination should read 2457; 246 or 24.57 means a scale factor is off by a factor of ten somewhere. Then confirm what the consuming logic assumes: units, sign, decimal place. Last, let the timer run ten cycles and watch the bit alternate 1, 0, 1, 0 with the destinations tracking the oven.
What breaks this handshake later?
Three failures account for most stalls: a request bit that never clears, a communication loss that leaves old numbers in the destinations, and a second writer that zeros the bit out of turn.
- Bit never clears. The reset action is missing, or it sits ahead of the copies and a fresh trigger slips through before the list finishes. On the DL260, a Modbus timeout can also leave the SP116 busy bit set and hang the polling sequence; that busy-bit failure and its clear procedure are covered separately.
- Stale numbers. The destinations keep whatever was last copied when the controller stops answering, and a number that stays numeric looks live. Count falling edges of the request bit in the PLC and flag the data when it misses three cycles, 15 seconds at the 5 second interval.
- Second writer. A panel tag linked for writing can push its power-up value, often zero, into the PLC while the PLC is still starting, a documented way linked tags clobber PLC values at start. Give the request bit one writer on each side, and if it changes with no copy requested, find what owns that address.
- Copy storm. A set condition left as a level retriggers the event every scan; the one-shot fixes it.
Recommendation: build the event copy when the list holds fewer than about 20 values and a 2 to 5 second update serves the process; a 21-action event on a 5 second cycle is a light load for one panel. When the list is longer, the update must be faster, or the PLC makes control decisions from the numbers, give the PLC its own network link to the controller and read it there, and leave the panel to display.
Questions
Does displaying a controller tag on the panel also write it to the PLC?
No. The display object reads the controller and the reading stops at the glass. The only write to PLC memory is the one you configure: an event triggered by the request bit, with one copy action per value and the reset last. The PLC then reads the destination registers, never the controller tags.
How many actions does a four-value transfer need in the event?
Five: four copy actions, one per value, plus the reset that writes zero to the request bit. Each copy action moves one tag, so the action count for a list of any length is the list length plus one.
Can a fractional temperature land in a 16-bit integer register?
Not as a fraction. A plain copy into integer memory drops the decimal, so 245.7 °C lands as 245. Use a floating-point register for fractional values, or scale to counts: at 0.1 °C per count, 245.7 °C is 2457 counts, and the signed 16-bit ceiling of 32767 counts equals 3276.7 °C, so the range fits.
How does the PLC know the copied values are fresh?
The request bit returning to 0 marks a finished cycle. Increment a counter in the PLC on that falling edge and flag the data when it misses three cycles, 15 seconds at a 5 second interval. Without that check, the destinations hold the last copied number, which still looks like a live reading after the controller stops answering.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.