Why Does the SPK107 Freeze After a Pump Start Command?

On the SPK107 [M01], the reported failure follows a pump-start command: the displayed values and control state stop updating, and the pump command remains active until the controller is restarted. After the fault is isolated and corrected, the SPK107 must respond again, update live values, and release or change the pump command as the process requires.

Which hop fails when the SPK107 sends a pump-start command?

Trace the transaction from the level measurement through the controller and onward to the pump controller before changing the application. In this installation, the SPK107 reads the receiving-tank level over Modbus, combines it with pump motor-hour information, and sends a start or stop command over Modbus to one of three pumps. A PR200 sits between the SPK107 and each pump. Each PR200 also receives critical high- and low-level discrete inputs, so those float switches can start or stop the pump independently of the SPK107.

The critical floats explain why the pump continues cycling even though the SPK107 has stopped responding: the PR200 can still switch the pump at its independent level limits while the SPK107's start word remains asserted. The observed event therefore contains at least two separate questions: why the SPK107 stops updating, and how the PR200 handles a retained command. Do not treat correct level indication before the event as proof that the panel, application, and serial link remain healthy during it.

Does the 24 V supply dip when a pump starts or stops?

The SPK107 supply is reported as 24 V. The pump uses a soft starter, with direct starting also provided. A switching event can disturb a shared supply or couple noise into nearby control and communication wiring. That is a plausible physical-layer route to a controller fault, not a confirmed cause. Measure it at the controller rather than inferring power quality from a normal reading taken while the pump is idle.

Capture the measurement at the SPK107 terminals while reproducing a start and a stop. Check the supply feeding the panel as well as the panel-side voltage: a disturbance can originate upstream in a shared cabinet supply. If measurements identify conducted interference, review the supply arrangement and any line-filter option with the equipment documentation and electrical design. A filter using inductive, capacitive, and varistor elements was suggested for the supply feeding the SPK107 and other low-voltage equipment, but its ratings and suitability must come from the installed power supply and filter documentation. Do not install an unspecified filter as a substitute for measuring.

Does the freeze track pump switching or appear independently?

Both reported freezes followed the transmission of a pump-start command. That timing makes the start event a priority for reproduction, but it does not distinguish a software exception from a supply disturbance, electrical coupling, or a communication/runtime fault. The pump can also be started directly, so compare paths under controlled conditions while retaining the PR200's independent critical-level protection.

1. Record the date and time, pump selected, tank level, SPK107 command state, PR200 state, and whether the start was issued through the SPK107 or by the alternate start path.
2. Repeat the two start paths separately, keeping other test conditions as constant as the process allows. Record supply measurements and whether the touchscreen, displayed values, and control word continue to update.
3. If a freeze follows both a direct start and an SPK107-commanded start, prioritize the physical switching event and shared wiring or supply. If only the SPK107 command path produces it, inspect the Modbus transaction, application logic, and runtime log next.
4. If the panel freezes without a pump event, broaden the capture to other loads and project activity, including trend recording, instead of assuming the pump start is causal.

The installation has both soft-starter and direct-start options, and starts through both paths were reported. No controlled comparison isolates one of those paths. A repeatable timestamped test supplies that missing distinction. Do not bypass the PR200 float protection to make the comparison.

Does the PR200 receive a changing Modbus command or retain one value?

Read the command at both ends of the serial exchange. The description says the start word remains regardless of tank level and also describes the command as continuing on Modbus. Those descriptions do not by themselves show whether the SPK107 continues transmitting, leaves a word latched in its application, or whether a PR200 continues acting on its last received value. A bus capture and receiver-side observation decide between these cases.

Record the actual register addresses, function, values, polling arrangement, and devices sharing the port from the project and device configuration; none are specified in the incident description. Do not invent an address or assume the SPK107 is the Modbus client or server without checking the configured exchange. A serial analyzer must match the interface and be connected in a way that does not change termination, biasing, isolation, or the bus topology. Compare request and response timestamps with the controller log and voltage capture. A communication error can explain stale input or output data, but it does not alone explain a nonresponsive touchscreen.

Can CODESYS show a log while the SPK107 is frozen?

Connect from CODESYS while the failure is active and inspect Device > Log (shown as Device - Журнал in the supplied interface description). The controller log is available as a live diagnostic during the hang; the reported answer was that the cause cannot be recovered from that log after restarting the controller. Rebooting first can erase the opportunity to capture the live state.

1. Before a controlled reproduction, prepare the engineering connection and record the project, device configuration, and the software/runtime and firmware identifiers shown by the installed tools.
2. When the panel stops responding, record the visible values and time, then connect to the device and inspect the log without first restarting it.
3. Save any log entries and record whether the device remains reachable, whether the log advances, and whether the Modbus capture shows further requests and responses.
4. If CODESYS cannot connect or the log contains no useful event, retain the supply and bus captures; a lack of a readable entry is not proof that no fault occurred.

Correlate the log timestamp with the start command, measured supply, and serial exchange. A controller that is online and logging while the visualization is frozen points to a different failure boundary than a device that no longer responds to CODESYS. Preserve these observations before restarting; the restart restores service in the reported case but does not supply a post-reboot fault history.

Can exception handling reboot the SPK107 after this hang?

The Configurator's Additional tab has an exception-processing option described as a Reboot mode. Enable it only with the failure mechanism in mind: it can help when the runtime registers an exception, with division by zero given as an example. It is not equivalent to a monitor that detects every frozen display, stalled application task, serial fault, or electrical disturbance.

Distinguish the mechanisms before relying on automatic recovery. Exception handling reacts to a software exception reported by the runtime. A watchdog generally relies on a progressing task or heartbeat and can reset a system when that progress stops; availability and configuration are product-specific. Check the SPK107 documentation and installed Configurator for a separate watchdog function rather than inferring one from the exception reboot setting. If the runtime remains alive while only a particular task, screen, or communication path is stale, a watchdog that is still being serviced may not detect that partial failure.

Test exception reboot behavior on a bench or in a controlled commissioning condition, not by deliberately creating an exception in an operating station. Before enabling automatic restart in service, verify what the SPK107 and PR200 outputs do during restart, how the SPK107 initializes its pump command, and whether a retained command can produce an unintended restart. Automatic recovery addresses availability only when the recovery path itself is safe; it does not identify the original fault.

What does the PR200 protect while the SPK107 is frozen?

The PR200's discrete critical-level inputs provide a separate protective path: the reported arrangement stops a pump at critical low level and starts it at critical high level independently of the SPK107. In the observed failure, this keeps the pump bounded by those critical levels but also lets it cycle between them because the SPK107 start word remains set. The fallback is therefore not equivalent to normal level-based control or to clearing a stale Modbus command.

Verify each PR200's discrete inputs and resulting pump action independently of the SPK107. Then verify the interaction between those inputs and a retained or changing Modbus command using the PR200's documented logic. Read its configured behavior for communication loss, command retention, and local/remote priority from the actual program or manual; the incident details do not provide those settings. If critical floats fail to stop and start the pump as designed, correct that local protective path before returning the station to unattended operation. Do not treat an SPK107 watchdog or reboot as a replacement for the PR200 protection.

Do trends or RS-485 differences explain this freeze?

Trend recording was raised as a possible cause, but the response in the case was that trend problems usually appear differently. Keep it as a testable branch, not the first explanation for a freeze that repeatedly follows a pump-start command. Preserve the current project and trend configuration, then compare reproducibility with trends disabled only in a controlled copy or test condition. If the event follows a trend task rather than pump switching, use the runtime log and project configuration to narrow that branch.

Separate SPK1xx reports described slow or unstable RS-485 communication in different cabinets, including cases with multiple drives and serial devices. A repeater separating bus segments improved stability in one such setup, while shielding drive output conductors was also suggested. Those reports are not proof of the cause or remedy for this SPK107 installation. Use segment isolation or a repeater only if captures show a bus-quality problem, and check the installed transceiver, port, cable, termination, and isolation requirements before changing the topology. Likewise, a slow Modbus read is a different symptom from the reported full-panel freeze with frozen visualization and touch response.

Which checks isolate and verify the resolving branch?

Use this sequence to retain evidence and avoid replacing a measured cause with a guess:

1. Document the configured Modbus devices, ports, registers, scan/poll arrangement, SPK107 supply source, soft-starter and direct-start paths, and PR200 float wiring. Record device and software identifiers from the installed project and tools.
2. Confirm that each PR200 independently stops at the critical low float and starts at the critical high float. Record how each pump responds to a retained command before testing recovery logic.
3. Measure and timestamp the 24 V supply at the SPK107 during pump start and stop. Inspect cable routing and functional-earth wiring against the product and cabinet instructions.
4. Reproduce direct and SPK107-commanded starts separately while recording the panel response, supply, and pump state. Keep the independent critical-level protection active.
5. Capture the Modbus command and response and compare them with the SPK107's command state and PR200's received state. Follow the bus branch if exchanges fail; follow the runtime/application branch if values stop changing while exchanges continue.
6. If the panel hangs again, connect through CODESYS and save Device > Log before restarting. Correlate any event with the supply, serial capture, and switching timestamp.
7. Correct the branch indicated by the readings: repair or separate a disturbed supply/wiring path, correct a demonstrated bus issue, or revise software only when runtime or project evidence points there. Enable exception reboot only for exceptions it can detect, then validate restart outputs and command initialization.
8. Repeat the relevant start and stop tests and verify live display updates, SPK107 responsiveness, expected Modbus command transitions, and independent PR200 float operation.

Do not close the fault as resolved because a reboot restores the panel. The resolving branch is the one that removes the triggering condition and passes the same captured test that previously produced the freeze.

What should I verify before returning the station to service?