Troubleshooting Bolid S2000PP Missing Counter Values

Bolid S2000PP responds with its name and firmware in SCADA 6+, but the ASR8 and ASR2 counter values stay empty. That tells you the driver reaches the S2000PP. It does not prove that the S2000PP can read all nine S2000KDL controllers or that SCADA addresses the downstream values correctly.

Separate the visible symptom from the failed path

Start here. Record exactly what the point shows: blank, zero, frozen, stale, or bad quality. Those results lead to different checks.

Reading the S2000PP identity validates only the first communication segment. A gateway can answer an identification request from its own memory even when downstream devices are unavailable. Reinstalling the driver or changing display formatting at this stage wastes time.

Prove the downstream communication branch

Check whether the S2000PP can obtain any live data from each S2000KDL. Use the device configuration or diagnostic view that exposes communication status, response state, or current input data.

1. Test S2000KDL address 1 and record whether it returns any changing input or status value.
2. Repeat the same test for addresses 2 through 9.
3. If no address responds, inspect the common link between the S2000PP and the controller chain.
4. If only selected addresses respond, investigate those failed addresses individually before changing SCADA tags.
5. If all nine respond outside SCADA, move to the driver-addressing check.

A failed common branch points to the shared communication path: physical connection, interface settings, controller power, or the S2000PP configuration used to reach the chain. A single failed branch points to a local connection or address problem. The exact diagnostic screen and communication parameters depend on the installed configuration; read them from the project and device tools instead of substituting assumed values.

Validate every controller address

The installation assigns S2000KDL addresses 1 through 9. Verify the configured address in each physical controller. Do not rely only on labels or project documentation.

1. Read the address stored in the first controller.
2. Match it to the address used by the S2000PP configuration.
3. Match that address again to the corresponding SCADA point.
4. Repeat the comparison for all nine controllers.

Each downstream point needs enough information to identify both the intended controller and the intended input or value. The S2000PP address alone selects the gateway, not a unique ASR8 or ASR2 value behind it. A duplicated controller address can also make one unit appear to work while another disappears or produces unstable responses.

If the driver configuration offers separate fields for gateway, controller, input, value class, or function, compare them with the driver documentation. Do not collapse several addressing levels into one field unless the documented syntax explicitly requires it.

Interpret input setting 13 before changing it

All S2000KDL inputs reportedly use configuration value 13. Treat that number as a configuration value until the installed device documentation identifies its function. It may describe an input type, operating mode, or another property; it is not automatically the SCADA read address.

Take one ASR8 or ASR2 point and trace four layers:

1. Confirm that the physical counter is connected to the intended S2000KDL input.
2. Read the input's current state or numeric value in the native configuration or diagnostic tool.
3. Confirm that setting 13 is the required mode for that connected device and for the value being requested.
4. Map the SCADA point to the same controller, input, and value type.

If the native tool shows only a discrete state while SCADA requests a numeric counter, the requested data class is wrong. If the native tool shows a changing numeric value, keep setting 13 unchanged and correct the SCADA mapping. Changing all inputs at once destroys the comparison you need.

Build one controlled point

Reduce the system to one known path. Use one S2000KDL, one connected counter, and one SCADA point. This separates a driver-definition error from faults caused by the nine-device chain.

1. Select a controller that returns live data in its diagnostic tool.
2. Select one ASR8 or ASR2 value that visibly changes or can be checked against the source device.
3. Create one SCADA point with the documented S2000PP, S2000KDL, input, and value selectors.
4. Disable scaling or engineering conversion temporarily if the driver can expose the raw value.
5. Start polling and inspect the value, quality, timestamp, and driver diagnostic message.
6. Change only one addressing field at a time if the point remains invalid.

If the test point works, clone its structure and change only the downstream address and input selector for the remaining points. If it fails while the same value is readable through the native diagnostic path, focus on driver syntax, supported data types, and the relationship between the driver version and the configured devices.

Verify the resolving branch

Do not accept one plausible number as proof. Verify communication and value behavior together.

1. Confirm that the S2000PP identity still reads correctly.
2. Confirm that each S2000KDL at addresses 1-9 has a unique, responding address.
3. Compare one raw ASR8 value and one raw ASR2 value between the device diagnostic view and SCADA.
4. Cause or observe a legitimate source change, then confirm that the SCADA value and timestamp update.
5. Restart polling and confirm that the points recover without manual remapping.
6. Restore required scaling only after raw-value verification.

Document the working address fields and value type. Apply them methodically to the other controllers. Do not bulk-copy an unverified point or use identical downstream selectors for all nine addresses.

FAQ