Symptoms and First Actions
The reported failure pattern on the SPK110 panel controller is consistent: warning triangles remain lit on the configured Modbus modules, the controller's Network LED stays off, and the connected field devices show only their Power indication. The modules never enter data exchange even after the COM port appears to be set correctly.
Before changing configuration, power-cycle the entire system (controller and modules together) and download the corrected project to the SPK110 again. Stale port state or a partially applied configuration can persist until a full restart. If the triangles remain after a clean power cycle and reload, treat the project itself as suspect and verify every communication setting before blaming hardware.
COM Port Mapping: Match the Physical Port Number
The most common root cause in this case is a port-ID mismatch. Setting the Modbus configuration to "COM1" is not enough: in the modbus_com tab, under General, the COM port number must equal the physical port ID of the specific SPK110 unit. Open the controller's Info tab, read the physical port numbers listed there, and assign exactly those numbers to the corresponding physical COM ports in the project. A mismatch (for example, entering 2 where the port ID is 1) leaves the bus task bound to a nonexistent or wrong interface, which produces the triangle indicators and a dark Network LED.
Port Parameters and Bus Task Settings
Verify the remaining serial and task settings against the module configuration:
-
Parity: "no parity" must be entered as
None, notEven. A wrong parity silently kills all exchanges even when the port ID is correct. - Auto-restart: enable the auto-restart checkbox so the driver recovers from transient bus errors instead of latching the fault state.
- Mapping mode: in the mapping/association settings, select the "On2" option — the variable is updated in every bus cycle task. A mapping tied to the wrong task update mode leaves module data stale or unrefreshed.
Apply these settings, then repeat the full power-cycle and project download before judging the result.
Isolating Controller vs. Module Faults with MBPoll
When the corrected configuration still fails, determine whether the problem sits in the SPK110 or in the modules:
- Disconnect all modules and reconnect them one at a time to isolate a faulty or misconfigured device.
- Poll each module individually from a PC using the MBPoll program. A module that does not respond to MBPoll has its own addressing or parameter problem, independent of the SPK110.
- Use the same MBPoll setup to test the SPK110 port itself, confirming the controller's serial interface and project configuration actually transmit and receive.
This split confirms which side to fix: modules that answer MBPoll but fault under the SPK110 point back to the controller project; modules that never answer point to module configuration.
FAQ
Why do SPK110 Modbus modules show warning triangles with the Network LED off?
The triangles and dark Network LED indicate the bus task never established exchange — most often because the configured COM port number does not match the physical port ID listed in the controller's Info tab. Correct the mapping, then power-cycle everything and reload the project.
What parity setting should I use for "no parity" on the SPK110 Modbus port?
Enter None for no parity — not Even. An incorrect parity value blocks all communication even when the port ID and wiring are correct.
How do I test whether the SPK110 or the Modbus module is at fault?
Connect modules one at a time and poll each with MBPoll from a PC, then use MBPoll to test the SPK110 port itself. Devices that respond to MBPoll but still fault under the controller indicate a project configuration problem; devices that never respond need their own settings corrected.