S7-1500 watchdog after a TIA V19 download — cell stays in STOP

TS ControlsThe answer

A cycle-time watchdog right after a small OB1 edit usually means the scan now runs longer than the maximum cycle time set for the CPU. Either the edit added work, or something outside your logic is taking CPU time. Raising the watchdog is the last step, not the first.

How the S7-1500 reacts: when a cycle runs past the maximum cycle time set in the CPU properties (Cycle, Maximum cycle time), the CPU starts the time error OB, OB80, if the program has one. If the overrun continues, for example past twice the maximum cycle time, the CPU goes to STOP even with an OB80 loaded. So “comes up, then drops to STOP” fits a scan that is long on every cycle, not a one-off spike.

Start with the diagnostics. In Online & diagnostics, open the diagnostic buffer and note the exact event (cycle time exceeded or another time error) and which OB was running. Then open the cycle time view and note the shortest, current, and longest cycle since the restart. If you can let the CPU run briefly with the process in a safe state, watch whether the longest cycle climbs steadily or jumps. Check whether the program has an OB80. Adding one that only logs the event can keep the CPU running long enough to diagnose, but only if the process is safe with an overrunning scan. That is a judgment call, not a default.

Next, look at what the edit actually changed. Look for FOR or WHILE loops in SCL with a bound that is now larger, or a loop variable that never reaches its exit condition after the edit. Look for instructions that copy large structures every scan, such as MOVE_BLK over big arrays, string handling, or Serialize and Deserialize. Look for a block call that moved from a cyclic interrupt OB into OB1, or the reverse. Then compare the downloaded version against the last known-good project with an offline/online compare, so you are not guessing.

Then look at communication load, which is where the HMI version question matters. Opening a project in V19 upgrades the whole project, but a Comfort Panel can keep an older device version, within the versions V19 supports. If someone changed that version or recompiled the HMI along the way, its tag settings and acquisition cycles may have changed with it. Check the HMI’s acquisition cycles and any cyclic scripts. A large group of tags read at a very fast cycle, or a script triggered on every cycle, raises the communication load on the CPU. In the CPU properties, check the communication load setting, the share of the cycle that communication may use; high communication load stretches the scan. Also check web server use, OPC UA subscriptions with very fast sampling, and any engineering laptop left online with watch tables running.

Fix the cause, then set the watchdog on purpose. Slow the HMI acquisition cycle, move heavy work to a cyclic interrupt OB with a sensible period, bound the loop, or split the work across scans. Then measure the longest normal cycle under full production load and set the maximum cycle time with headroom above that measured value. Do not set the maximum so high it never trips. A watchdog that never trips also never tells you about the next problem.

On a press line, think about safety before anything else. Do not restart the CPU over and over with the press in an unknown state. Follow the plant’s lockout and restart procedure, and confirm the safety program’s status separately.

If the cell is still in STOP and production is waiting, that is a line-down call, not a forum thread.

Need hands on it? Send the project file, the symptom, and your outage window to sales@ts-controls.com or through the RFQ form, or call the office at (877) 524-6674, Monday–Friday, 9:00am–5:00pm Eastern. Line down right now? Call (877) 790-4697, 24/7, subject to personnel availability.