Triggered text freezes while the PLC outputs toggle because the panel's device is pointed at the wrong protocol, usually a serial driver on an Ethernet link. Open Panel Manager, set PLC Protocol to the PLC's Ethernet driver, enter the PLC's IP address, and transfer the project. Then run every trigger bit through both states; four bits mean eight text checks.
Four screens of triggered text, four outputs toggling in the ladder, and a panel that sits frozen: that combination usually comes down to one project setting. The screens read their bits from the PLC through the panel's device definition. When that definition is set to a serial protocol while the panel and the PLC are wired for Ethernet, no bit the PLC sets ever reaches the text. The fix is to set the device's PLC Protocol to the PLC's Ethernet driver, enter the PLC's IP address, transfer the project, and test every trigger bit through both of its states. The link light stays bright through all of this; it tells you the cable is seated, and the protocol setting decides whether any data crosses it. The whole repair takes about 15 minutes at the bench. No ladder edit and no new hardware belongs in this repair until that setting has been checked.
What triggered text needs before it can change
Triggered text is a runtime read, and it rides a chain with four links:
- The ladder sets an output high or low, C13 for example.
- The Ethernet module on the PLC rack carries the value onto the network. On a DL250-1 installation that module is an H2-ECOM, and the module talks at 10 or 100 Mbit/s.
- The panel asks for the value through its device definition, and the definition's PLC Protocol sets the language of that conversation.
- The text object's tag reads the bit and selects the off text or the on text.
A serial setting in step 3 breaks the chain at the panel while steps 1, 2 and 4 stay healthy. Watching the outputs turn on in the programming software shows the sequence running; it says nothing about step 3. The panel's own manual frames it the same way: the touch panel talks to whichever PLC is configured in the project, over the connection that project defines. The device definition is where serial and Ethernet are told apart, so it is the first place to look when text never moves.
Symptoms and what each one points to
Match what you see against these rows before editing anything:
| What you see | What it points to | First move |
|---|---|---|
| Outputs C11 through C14 toggle online, no screen text ever changes | Device definition set to a serial protocol on an Ethernet link | Set PLC Protocol to the PLC's Ethernet driver, enter the PLC's IP address |
| Link lights bright at both ports, tags still dead | Physical link up, application conversation absent | Check the device protocol, then both IP addresses |
| Every screen frozen after the driver change | PLC address mistyped, panel address missing, or the two on different subnets | Compare both addresses node by node on one subnet |
| One screen frozen, the other three follow their bits | That screen's tag or its on and off text assignment | Check the tag address and both text states for that screen |
| The wrong word appears on a state change | Tag aimed at the wrong bit, or on text and off text swapped | Correct the tag address or swap the two texts |
The first row is the pattern that produced this fix, and it is also the cheapest to correct.
Set the device to the PLC's Ethernet protocol
Save a copy of the project before editing, so the working screens can be restored unchanged. Then:
- Open the project and select the Function tab.
- Open Panel Manager and click the device your tags reference; in a project shaped like this one the device is named dEV001.
- Change PLC Protocol from the serial selection to AutomationDirect ECOM Ethernet, the driver that matches the Ethernet module on the PLC.
- Enter the IP address of the PLC side of the link, meaning the module's address. An ECOM module gets its address through NetEdit3, its last octet accepts 1 through 254, and the module manual's example address is 192.168.70.15.
- Confirm the panel holds its own separate address on the same network. A project downloaded over Ethernet is good evidence the panel already has one.
- Transfer the updated project to the panel by the site's normal download method; on a 10 Mbit link a project of a few megabytes moves in well under 5 minutes. Then run the test in the next section.
Two addresses, two fields. The device definition wants the PLC's address; the panel's own address lives in the panel's setup. Typing the panel's address into the PLC field aims the panel at itself and leaves every tag dead. Setting the PLC type on the Micro panels happens on this same Panel Manager screen, and the PLC type setup for the Micro panels covers the selection screen in detail.
Example: four trigger bits on a 15 in panel, eight text states
The inputs, as the project lays them out:
- 4 output bits, C11, C12, C13 and C14, each trigger one screen of text on the 15 in panel. C11 and C12 sit in a timed sequence and are held high for their timed periods.
- Each screen carries 2 texts: an off text shown while its bit is low, an on text while high.
- The panel connects to the module with a crossover cable, and the link light is bright at both ends.
- Addresses in this example: module 192.168.70.15, panel 192.168.70.16, both last octets inside the accepted 1 through 254 range.
The rule in words: a protocol change counts as fixed when every trigger bit drives its own screen through both of its states. With N trigger bits and 2 texts per screen, the test has 2 x N states to observe. A driver fault kills all of them at once; a tag fault kills one screen's pair.
The arithmetic: here N = 4, so 2 x 4 = 8 states. Run each bit low, high and back to low while watching the online value and the screen together. C11 and C12 are the timed bits, so judge their text during the on-time window; in this project the timers hold each bit high for 10 seconds, which is long enough to read the on text twice before it drops. Once the timer expires the bit drops and the screen is meant to return to its off text.
The result and the decision it gives:
- 8 of 8 states tracking the bits: the device link is healthy and the repair is closed.
- 0 of 8 updating: the fault sits upstream of the tags. Recheck the protocol selection, the PLC address in the device, and the panel's own address for uniqueness inside 1 through 254 and one shared subnet.
- 6 of 8 updating, both failures on one screen: the other six prove the driver, and the fault is that screen's tag or text assignment.
Safety note: forcing bits can start motion. Run the test with the machine in a safe state, or at a cycle point where these four outputs can toggle without moving anything, and tell the operators before you force the first bit.
Checks before any hardware is replaced
A bright link light at both ends means the cable is seated and the ports agreed on a physical link. Reachability is a different thing from the conversation, and a panel that answers a ping while its reads fail has the same shape of fault; that ping-but-no-reads walkthrough takes the driver check from the top.
Module age is not evidence of failure. In this pattern the H2-ECOM carried the link the whole time; the wrong setting sat in the project file. Replace hardware only after a correct driver, a verified PLC address and a checked tag map leave all eight states dead. Swapping the panel is the expensive first guess, and the walkthrough on checking the PLC serial protocol before replacing a legacy HMI applies the same discipline.
If the link really is serial and updates arrive late or drop out, that is a different fault; dropped PLC-triggered messages on a serial panel have their own fix.
One boundary worth stating: an HMI panel and a signage screen are different products. If the cell also needs a board that plays its own slides and notices beside the machine, the shop-floor screens we build are made for that job, and the HMI stays an HMI.
Keep the fix on record
Copy the corrected project beside the original backup, and write the driver and both IP addresses into the maintenance record. The next frozen screen then gets found by a search of the notes instead of a fresh hour of cable swapping.
Recommendation: Check the device definition before touching ladder logic or hardware. Open Panel Manager, set PLC Protocol to the PLC's Ethernet driver, enter the PLC's IP address, transfer the project, and prove the repair with the full eight-state test. Replace a module only when a correct driver, a verified PLC address and a checked tag map still leave every state dead.
Questions
The panel downloads over Ethernet. Why did the tag reads still fail?
Downloading and runtime reads are two separate conversations. The download goes from the programming computer to the panel at the panel's own address. Triggered text is read by the panel from the PLC through the device definition, using that device's protocol and the PLC's address. A correct download path leaves the device definition untouched, so the text can stay frozen while transfers work fine.
Does the cable between the panel and the module have to be a crossover?
On classic 10 and 100 Mbit Ethernet, two ports wired the same way need the send and receive pairs crossed, so a crossover cable was the reliable choice. Most current ports cross the pairs themselves, so a straight cable usually links as well. Try the straight cable first for a minute and swap to a crossover when the link light stays dark; without a light, nothing can converse at all.
What if the panel address and the module address are the same?
That is a conflict, and it freezes reads exactly like a wrong driver. Two devices answering one address on the same subnet corrupt each other's traffic. Give each node its own last octet inside the accepted 1 through 254 range: the module at 192.168.70.15 and the panel at 192.168.70.16 cannot collide. Fix the duplicate before changing anything else.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.