A NAK on a DF1 full-duplex link means the PLC received a damaged packet, so chase power and noise before settings. Feed the panel from a dedicated 24 VDC supply rated at least 1.5 A, route the RS-232 cable away from inductive loads, and power-cycle the panel as routine recovery after every PLC program download.
A NAK on a DF1 full-duplex serial link is not a settings fault. It is the PLC telling the panel that a packet arrived damaged and was discarded. When baud, parity, stop bits and CRC already match on both ends, and the link still logs NAK entries and PLC comm timeouts before dying until a power cycle, the damage is physical or procedural. A panel supply that sags, an RS-232 cable that picks up noise from inductive loads, or a driver left out of step by a PLC program download. This page gives the check order, the numbers that decide each step, and the recovery routine for a panel talking DF1 full duplex to a PLC serial port at 19200 baud with a DH-485 network on the second channel.
Why does a DF1 link send NAKs when all the serial settings match?
Because a NAK is not an argument about settings: it is the reply code a DF1 full-duplex device sends when it received a packet it did not understand, and on a link whose framing already matches, that means bytes were damaged on the way in.
DF1 full duplex frames every packet between DLE and STX control characters and protects the contents with a CRC. The receiver answers ACK when the frame checks out and NAK when it does not. Your settings tables show both ends agree on 19200 baud, no parity, 1 stop bit and CRC error detection. A framing mismatch fails on the first packet and never communicates at all; a link that runs clean for an hour and then fills its log with NAK entries is collecting damage in transit. That split is the whole diagnosis: suspect the wire, the supply and the resync behavior, and leave the protocol settings until last.
What does each logged error point to?
Read the two log lines as different faults: a NAK received from the PLC means the PLC got a packet and rejected it, while a PLC comm timeout means the panel gave up waiting for a valid reply.
| Log line | Who saw the failure | What it points to |
|---|---|---|
| NAK received from PLC | The PLC | Your packet arrived damaged: the CRC checked badly, the framing broke, or the PLC had no buffer for it. Corruption on the panel-to-PLC wire, or an overloaded processor. |
| PLC comm timeout | The panel | No valid reply arrived in time. The request was lost, the reply was lost or corrupted, or the PLC answered too late. |
| Comm recovers only after a power cycle | Both ends | The retry counters ran out and the two drivers are out of step; neither side will resync until one of them restarts. |
The lockout is the second-order symptom; the NAK entries ahead of it are the cause. The counting matters: with NAK retries at 3 and ENQ retries at 3 on the PLC, three consecutive failures exhaust the PLC side and the driver stops polling the panel, which is how a run of bad packets becomes a dead link.
Does a DH-485 network on the second channel conflict with DF1?
Not on the wire: the two serial channels hold separate protocol settings, so DH-485 traffic on Channel 1 does not corrupt DF1 packets on Channel 0, and you do not fix this fault by disconnecting the network.
The interaction shows up at a different moment. A program download or a processor mode change restarts the PLC's channel handling, and a panel attached through the download is left driving a driver state the processor no longer expects. The pattern repeats across installations: the same NAK-and-timeout lockout lands right after a download to the PLC, on links with the DH-485 network attached and on links without it, and it clears only when the panel is power-cycled or receives a project transfer.
Two conclusions follow. A lockout immediately after a download is expected behavior, not evidence of a wiring fault. A lockout with no download and no power event behind it points back at the physical layer.
How should the panel be powered so the corruption stops?
Feed the panel from a dedicated 24 VDC supply rated at least 1.5 A, and meter the voltage at the panel's terminals with the screen live while the largest load in the cabinet switches.
The panel needs its own supply; its maker sizes the feed at 24 VDC and a 1.5 A minimum. A supply shared with contactor coils, solenoid banks or drive output circuits dips every time one of them pulls in. The dip is far too short for a spot check with a meter, but long enough to garble bytes at the UART or reset the panel, and every garbled packet the PLC receives comes back as a NAK. Meter the terminals under load: have someone cycle the largest contactor while you watch. Any dip below the rated 24 VDC at the panel is a finding, and moving the panel feed onto its own supply or its own DIN-rail feed is the fix. The sizing arithmetic for that feed, including inrush, is in sizing a separate 24 VDC supply for HMI inrush current.
Example: one shared supply, four loads
A 24 VDC supply rated 2 A feeds the panel, two indicator towers at 120 mA each, and an input rack drawing 300 mA. Steady draw is 1.5 A + (2 × 0.12 A) + 0.3 A = 2.04 A, already past the 2 A rating before any inrush. Every time a contactor pulls in, the rail dips, the panel's serial output corrupts, and the PLC answers NAK. The decision writes itself: the towers and the input rack stay on the 2 A supply, and the panel gets its own. Size that supply from the 1.5 A minimum with headroom: 1.5 A × 1.3 = 1.95 A, so the next standard rating up, 2 A. Verify it by watching the meter hold 24 V at the panel terminals through 20 contactor cycles with no new NAK entries in the log.
How should the RS-232 cable be routed, and how long can it run?
Keep the three-wire run short and give it its own path: the commonly cited working limit for RS-232 is about 15 m (50 ft) at 20 kbit/s, and your link runs at 19200 baud, right at that ceiling.
Route the cable away from contactors, solenoid banks and drive output wiring. Cross power cables at right angles where a crossing is unavoidable, and never share a tray or a bundle with them. Every switching event on an adjacent conductor couples a spike into an unterminated RS-232 run; the CRC catches the damaged frame and the PLC sends a NAK, so the log timestamps the switching, not the settings. The full distance arithmetic for this interface is on how far can an HMI be from the PLC on DF1 RS-232. Where the run has to grow or the noise will not settle, move to differential signaling; RS-232 to RS-422 cable distance for an HMI panel link carries the comparison numbers.
Which DF1 settings are worth changing, and in what order?
None until the power and routing work is done, because every PLC-side edit needs a program download, and a download with the panel attached reproduces the lockout you are chasing.
- Panel firmware. Load the current firmware and programming software from the panel maker, then reload the project so driver and project versions agree.
- Poll time. The panel is set to poll time 0, so requests leave back to back. Raise it in small steps while you watch the log, so the processor is not answering the panel flat out while it also serves the network channel and its own scan.
- Embedded response. The PLC has embedded response enabled, which lets acknowledgements ride inside reply packets, and the PLC manual also offers an auto-detect embedded response option. Check what the panel's DF1 driver does with embedded responses: if it never sends them, switch the option off on the PLC and retest.
- ACK timeout. The PLC waits 50 × 20 ms = 1.0 s for a reply before it declares a miss. If the processor is busy with network traffic, a longer wait gives slow replies room to land. NAK retries and ENQ retries sit at 3 each, the defaults; leave them until clean power and clean routing are in place.
Timing settings change how the link copes with damage. They cannot repair a damaged packet, so NAK entries that survive clean power and clean routing need the driver and embedded-response checks above.
How do you bring the panel back after a program download?
Cycle power to the panel, or transfer a project to it, and leave the PLC running: with the panel attached, a program download restarts the PLC's channel handling and strands the panel's driver until one side restarts.
Put the step in the commissioning procedure, worded as routine: after any download to the PLC with the panel attached, power-cycle the panel or transfer a project to it before judging the link. A project transfer resets the panel's driver too, so use whichever fits the shift. If the panel comes back up with its screens missing after the cycle, stop and treat that as its own fault; HMI panel loses its project after a power cycle walks the checks for it.
How do you prove the fix before you close the job?
Watch one full production shift with a live-data screen on the panel and an empty error log, then stress the cabinet: switch the largest inductive load twenty times and confirm no new NAK or comm timeout entries land.
- Quiet run. A full shift of production with no new entries in the panel's error log.
- Switching test. A large contactor or solenoid in the same cabinet cycled twenty times while you watch. A NAK during switching exposes a noise path the quiet run missed.
- Network run. Reconnect the DH-485 network and repeat the shift; the log must stay clean with the network active.
- Download test. Send a program to the PLC with the panel attached, run the documented recovery, and confirm live data resumes without cycling PLC power.
Recommendation: when a DF1 link logs NAK received from PLC entries ahead of a lockout, spend the downtime on the physical side first: a dedicated 24 VDC supply rated at least 1.5 A for the panel, the RS-232 run pulled out of every bundle that carries inductive loads, and current panel firmware with the project reloaded. Change DF1 timing settings only if clean power and clean routing still leave timeouts, and write the post-download panel power cycle into the procedure so the next download ends with a scheduled reset instead of a fault call.
Questions
Can I just raise the retry counts until the link stops locking up?
You can move them, and it is a stopgap. The PLC-side NAK retries and ENQ retries each accept 0 to 10, with 3 as the shipped default, and the driver stops polling once its count runs out. The panel driver accepts 0 to 255 retransmissions. Higher counts on a noisy wire trade a lockout for longer stalls on damaged packets, so set power and routing right first and keep the defaults.
Does a USB-to-serial adapter on the programming laptop change any of this?
It can, during programming sessions. An adapter adds another UART and its own buffers between the laptop and the PLC port, so a timeout that shows up while you are downloading a program can belong to the adapter, not the link. Repeat the test once from a machine with a built-in serial port. If the errors vanish there, leave the DF1 settings alone and look at the adapter.
What if the whole fix has to happen in one shutdown window?
Do the physical work in that window and defer the settings. Fit the dedicated 24 VDC supply, reroute the RS-232 cable, update the panel firmware and reload its project, then power up and run the switching test with the contactors cycling. PLC-side changes, such as turning embedded response off, wait for the next planned download, because the download itself restarts the channel handling.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.