The operator sees a station that never updates, a blank OPC selection list, or a response that arrives as an unusable character packet. Follow the transaction backward from the display: value binding, parser, communication driver, local COM port, server modem, remote modem, and controller. For this installation, a normal tag configuration is not enough. The resolving paths are a custom Rapid SCADA Communicator driver or an external OPC server that implements the proprietary exchange.
What is the screen actually telling you?
A SCADA tag holds a processed value; it does not define how an arbitrary serial byte stream becomes that value. If a display object shows no data, first read the tag quality, update time, and raw value. These readings separate a display problem from a communication problem.
| Reading | Location | Meaning | Next check |
|---|---|---|---|
| Good quality and correct raw value | SCADA tag | The acquisition path works; the screen binding or formatting is wrong. | Inspect the display object's tag binding. |
| Bad quality or stale update time | SCADA tag | No valid value is reaching the SCADA Server. | Inspect the Communicator or OPC transaction. |
| Complete packet but no numeric values | Driver or OPC diagnostics | The transport works, but parsing or field mapping is missing. | Define packet boundaries and field conversions. |
| No received bytes | COM-port trace | The fault precedes tag processing. | Check the request, port ownership, modem path, and station response. |
When the tag contains the expected value but the display does not, the tag is right; the binding is wrong. Changing modem or serial settings cannot correct that branch.
Does the request leave the local COM port?
Capture the transmitted bytes at the component that owns the COM port. The demonstrated requests include GOW0134 and short station selectors such as 01 and 02. Compare the capture byte-for-byte with the configured request, including any terminator that the actual protocol definition requires.
The local Cinterion BGS2T modem operates as a TCP server with several remote modem clients. A request sent through its COM port reaches the connected remote paths. Each Omron CP1E listens for its own selector and only the matching station returns data. The stations do not communicate with one another.
| Observation | Effect | Action |
|---|---|---|
| No transmit bytes | The poll scheduler or communication component did not issue the request. | Confirm that the polling item is active and that the intended process owns the COM port. |
| Wrong request bytes | No controller recognizes the station selector. | Correct character encoding, station text, and protocol framing from the device specification. |
| Correct request, no remote response | The break lies in the modem connection, remote serial link, selector handling, or controller logic. | Check modem connection state and monitor the remote controller's receive condition. |
| Correct request and response bytes | The transport path works. | Continue to transaction timing and parsing. |
Is each station transaction kept separate?
A response takes in this installation. The poller must send one station request, wait for that station's complete response, parse it, and only then send the next selector. Sending 01 and 02 without transaction control can merge responses or associate a late response with the wrong station.
Read four items from a timestamped trace: request time, first received byte, final received byte, and next-request time. If the next request precedes completion of the current response, serialize the poll sequence. If the response starts within the expected window but never becomes complete, fix the packet-completion rule. That rule must come from the actual protocol: a declared length, terminator, or other documented frame boundary. An idle gap alone is safe only when the protocol and worst-case inter-character delay make it unambiguous.
Do not convert an incomplete packet into tags. Keep the previous good values or mark the station data invalid according to the application's quality policy. Also clear or quarantine residual bytes before retrying, or the retry parser may consume the tail of the failed transaction.
Which component should parse the proprietary packet?
Rapid SCADA Communicator needs a protocol-aware driver for this nonstandard request and response format. The driver is a .NET DLL. It sends the selector, receives the packet, validates its structure, converts fields into channel values, and passes those values from Communicator to the SCADA Server.
| Configuration | Parsing location | Effect |
|---|---|---|
| Custom Rapid SCADA driver | Communicator | Directly exposes parsed values to the SCADA Server and removes an intermediate controller or simulator. |
| Custom-protocol OPC server | OPC server scripts or protocol module | Owns the COM or TCP endpoint, sequences requests, parses packets, and publishes variables for SCADA consumption. |
| Raw string forwarded to another controller | Local controller or simulator | Can work, but adds another device, another mapping layer, and another failure boundary. |
Both the custom driver and custom OPC paths can implement the exchange. Prefer the Rapid SCADA driver when Communicator should own polling and the engineering team can maintain the DLL. Prefer OPC when the selected OPC server already provides a proven custom-protocol scripting path and its values are visible through the SCADA connector.
Why is switching to Modbus not the immediate fix?
The remote BGS2T connection is established through AT-command operation, followed by transparent mode. The CP1E application then exchanges station-specific characters directly through the modem COM port. The stated controller and modem arrangement cannot simply change that live exchange to Modbus after connection.
A communication channel that first sends the required modem commands and then starts Modbus polling is a different architecture. It applies only when SCADA initiates and controls the connection. Communicator did not provide this communication-channel extension as a DLL in the described configuration, so a device driver alone cannot add that missing connection-establishment layer.
A static external IP offers another topology: a capable OPC server can listen as a TCP server and accept remote station connections directly. That removes the local modem in principle, but it does not remove the need for request sequencing, station identification, packet validation, and parsing.
How do you implement and verify the resolving branch?
- Document the exact request and response frames for every station. Record field boundaries, encoding, completion rule, and invalid-response conditions rather than treating the packet as an opaque string.
- Capture a known-good exchange for selectors such as
01and02. Confirm that only the addressed CP1E responds and measure the complete transaction against the observed response interval. - Select one owner for the endpoint: the custom Communicator driver or the OPC server. Two processes cannot safely poll through the same COM port.
- Configure sequential polling. Send one selector, collect one complete response, validate it, publish its fields, and then advance to the next station.
- Map each parsed field directly to a SCADA value with quality and update time. Retain the raw packet in diagnostics so malformed frames can be compared with valid traffic.
- Force three tests: a valid response, a silent station, and a malformed or incomplete packet. Verify that valid data updates the correct station, silence cannot shift the following response into the wrong station, and invalid data is not published as good quality.
- If using OPC and its selection list is empty, verify that the OPC server is operational and visible to the same connector context before changing serial settings. An empty selection list is an OPC discovery or integration branch, not proof of a COM-port fault.
What happens in the common failure branches?
What happens if every remote modem receives the same request?
Each CP1E must compare the received selector with its own station identifier. With requests such as 01 and 02, only the matching station should transmit a response.
What happens if the next poll starts before the response arrives?
The response can be attributed to the next station or combined with another frame. Wait for a complete response or a declared transaction failure before sending the next selector.
What happens if Rapid SCADA receives the packet as one string?
A custom .NET Communicator driver must split and convert the proprietary packet before publishing channel values. Forwarding the whole string to another controller works but adds an unnecessary processing layer.
What happens if the OPC server list is empty?
Troubleshoot OPC discovery and connector visibility separately from serial polling. First prove that the OPC server is running and exposes variables to the connector context; then bind those variables to SCADA channels.
What happens if one station does not answer?
End that station's transaction without publishing fresh good-quality values, then start the next request from a clean receive state. The final verification is a complete cycle in which every responding station updates only its own tags and the silent station cannot shift, merge, or corrupt the following response.