The DL-450 can collect non-MODBUS RS-485 data through a custom protocol routine; a BASIC Coprocessor was the working integration path for this application. A successful PC test proves that a device can communicate with the PC setup, but it does not provide the PLC with the message format, transaction timing, or parsing logic needed to poll and store the data.
Document each device protocol before changing the PLC
Do not begin by copying a PC terminal session into PLC logic. RS-485 defines an electrical signaling method; it does not define the messages carried over the wire. Since the target devices are not MODBUS, the PLC needs each device's own command and response rules.
Collect the device manuals and record the settings and message details for every instrument:
- Serial settings, including baud rate, data bits, parity, and stop bits.
- Whether the device expects a request before transmitting, and how it identifies the requested data.
- Request and response byte sequences, including any address, delimiter, checksum, or termination characters.
- How the device signals an invalid request, missing data, or communication failure.
- Whether the device sends unsolicited messages or requires a defined delay between transactions.
Keep literal protocol bytes separate from decoded engineering values. For each wanted measurement, document the response field, its data type, scaling, units, and valid range as specified by the instrument manufacturer. Do not infer a scale factor from a PC display unless the device documentation confirms it.
Check: For each instrument, you can write down the serial settings, request, expected response, and conversion rule from its documentation. If one of these is unknown, resolve it before coding.
Separate an electrical link problem from a protocol problem
A PC communicating with an instrument is a useful starting point, not proof that the PLC-side interface will work. The PC test may use a different adapter, port configuration, wiring arrangement, or application-level protocol. The first diagnostic decision is whether the receiving system sees valid characters at all; only then should you debug message interpretation.
| Observed symptom | Likely area to investigate | Next check |
|---|---|---|
| No response at the PLC-side interface | Serial configuration, wiring, interface compatibility, or request transmission | Compare the configured serial settings with the device manual and inspect the transmitted request using an approved diagnostic method. |
| Characters arrive but do not match the expected response | Framing, message boundaries, wrong request, or electrical noise | Compare the received bytes with a known-good device response, including delimiters and any checksum. |
| Response is valid but values are wrong | Field offsets, signedness, data type, or scaling | Decode one documented field and compare it with the device's own display or a trusted PC reading. |
| Intermittent or stale values | Polling overlap, timeout handling, or a reply assigned to the wrong transaction | Log request and response order, and make sure only the expected reply updates each instrument's data. |
RS-485 is commonly used for multidrop serial links, but the device documentation determines the actual wiring and network requirements for a particular installation. Verify the interface type and topology against the instruments and the coprocessor documentation; do not assume that a PC adapter's wiring or termination arrangement can be copied without checking.
Check: Identify the exact point where communication fails: no received data, malformed bytes, or correctly received data that decodes incorrectly. Keep that observation for the next stage.
Use the BASIC Coprocessor as the custom protocol layer
The reported integration used a BASIC Coprocessor with routines written for the non-MODBUS devices. That approach keeps the instrument-specific polling and reply handling in a layer designed for custom serial behavior instead of trying to treat a proprietary message set as MODBUS. The reported application reached operation after implementing this route.
Before writing code, verify in the DL-450 and coprocessor documentation how the module connects to the CPU, which serial resources it provides, how the PLC exchanges data with it, and what BASIC dialect and programming tools it supports. The BASIC used by FACTS may differ from regular BASIC, so syntax and runtime assumptions must come from the applicable manuals. Do not assume a particular port, instruction, memory map, or baud-rate capability without checking the hardware documentation.
For a temporary production restore, retain the instruments' analog outputs for measurements already available that way, if those signals are suitable for the process. This does not replace the desired digital data; it can keep selected existing values available while the custom serial integration is commissioned.
Check: Confirm the coprocessor model, supported serial interface, data exchange method, and programming environment from the manuals before assigning ports or PLC data locations.
Build one request-response transaction at a time
Implement a controlled transaction sequence rather than transmitting continuously. A polling routine needs to transmit the correct request, wait for the response, recognize a complete message, and then either accept or reject it. If several devices share a link, serialize requests unless the device protocol explicitly allows another arrangement. Otherwise, delayed replies can be mistaken for the response to a later request.
- Select one instrument and prepare its documented request using the required serial settings.
- Transmit the request, then wait for the expected response using the framing rule defined by that device. A terminator, fixed length, or documented timing rule may define completion; choose only the rule the protocol specifies.
- Reject incomplete, malformed, or invalid responses. Apply a timeout based on the device documentation and measured response behavior; do not invent a universal value.
- On success, validate any checksum or other integrity field required by the protocol, then decode the response.
- On failure, record a communication status and retry according to a deliberate policy before moving on to the next device.
Keep receive buffers isolated between transactions. Clear or reset them according to the coprocessor's documented behavior so leftover bytes cannot be treated as a new reply. If the protocol includes a checksum, calculate it exactly as specified; a response with a bad integrity check must not update the process value.
Check: With one device connected, demonstrate repeated complete request-response cycles and prove that each rejected or timed-out response leaves the last valid value distinguishable from current data.
Decode responses into explicit PLC data fields
Do not copy raw serial characters straight into HMI tags and treat them as measurements. Separate the received message, validation result, decoded numeric value, and data-quality status. That separation makes it possible to distinguish a real process value from a stale value or a conversion error.
For each response field, verify byte order, sign handling, decimal placement, units, and scaling against the device documentation. If the instrument returns text, parse only the documented field boundaries and character format. If it returns binary data, use the documented representation and storage size. These choices are protocol-specific; do not substitute conventions from another instrument or from MODBUS.
Update a displayed value only after the entire reply passes framing, integrity, and range checks. Preserve a last-good value only if the HMI also exposes its age or a clear communications status; otherwise, an old reading can look current after the link fails. Name and map the PLC data fields using the actual DL-450/coprocessor documentation rather than assumed addresses.
Check: Compare each decoded value and unit against a documented device reading, and force or simulate a rejected response to confirm the quality indication changes while invalid data does not overwrite the valid value.
Schedule polling around actual device response behavior
Once a single transaction works, expand the routine to the remaining instruments. Keep a clear device sequence and avoid starting a new poll while the previous response is still pending. If instruments have different response lengths or processing delays, handle each according to its protocol rather than using one assumed response pattern for all.
Choose the polling rate from the process need and measured transaction times. Account for request transmission, instrument response, message validation, and any required inter-message delay. If the sum exceeds the desired update interval, reduce the requested update rate or retrieve fewer values per cycle; do not allow overlapping requests to hide the timing problem.
Map only the required decoded values into the HMI. The integration goal was to bring additional pertinent instrument data into the display beyond what was already available through analog outputs. For every HMI value, define what the operator sees during startup, timeout, malformed data, and recovery. A communications indicator or explicit stale state prevents an old number from being mistaken for a live measurement.
Check: Observe several complete polling cycles with all devices connected. Confirm replies map to the correct instrument, updates remain within the required process interval, and faults produce a visible stale or bad-quality state.
Prove recovery before returning the data to operations
Commission in stages: one instrument, then the complete device set, then the HMI. Preserve a known-good PC exchange as a comparison reference, but rely on PLC-side captures and values to prove the final integration. Test normal replies, delayed replies, missing replies, and malformed data where the equipment and test method permit.
When a device fails to answer, verify that the routine times out, marks the data invalid or stale, and continues polling other instruments according to the intended sequence. When communication returns, verify that the status clears only after a valid response and that the decoded value updates correctly. Confirm the HMI labels, units, and quality indication agree with the PLC data.
Software-tool compatibility also needs a commissioning check. The application reported minor issues using FACTS ABM Commander while converting equipment to Windows 2000 and used workarounds. Treat that as a setup-specific warning: validate the programming and transfer workflow on the actual engineering computer and retain a recoverable copy of the working program.
Check: Release the serial values for use only after normal polling, failure indication, recovery, HMI presentation, and program recovery have all been demonstrated on the installed equipment.
FAQ: Commission non-MODBUS RS-485 with a DL-450
How do I connect non-MODBUS RS-485 devices to a DL-450?
Use a custom protocol routine; the reported working approach used a BASIC Coprocessor. Confirm the coprocessor's interface and PLC data exchange method in the applicable hardware manuals before wiring or assigning data locations.
How do I poll an RS-485 device that does not use MODBUS?
Implement the instrument's documented request and response sequence: send a request, detect a complete reply, validate it, decode its fields, and handle timeout or malformed data without updating process values.
How do I know whether the problem is wiring or message parsing?
First determine whether the PLC-side interface receives characters. No data points to configuration, wiring, interface, or request transmission; received but incorrect bytes point to framing, request content, or signal quality; valid bytes with wrong values point to parsing or scaling.
How do I keep the HMI from showing stale serial data?
Track response validity and age or a communications status separately from the last-good measurement. Mark the value stale or invalid on timeout, and clear that state only after a valid response updates the data.
When should I stop troubleshooting and contact official support?
Stop before changing wiring, port assignments, or program memory when the DL-450 or coprocessor documentation does not identify the interface or data exchange method. Contact AutomationDirect official technical support with the exact hardware models, documented serial settings, request/response captures, and the stage where the transaction fails.