Connecting Legacy PLCs to a Modern SCADA: What Protocol Gate

Connecting Legacy PLCs to a Modern SCADA: What Protocol Gateway Components an Independent China Desk Stocks

An independent China-based automation distributor sources new-surplus, refurbished PLCs, drives and protocol converters. A Red Lion protocol gateway between a legacy PLC and a modern SCADA on PROFINET or EtherNet/IP is one of the lower-risk retrofit moves on the table.

The shape of the problem

A 2007-era S7-300 station still runs the line. The SCADA package has been replaced twice. The new SCADA speaks only PROFINET and EtherNet/IP. The PLC still speaks MPI or PROFIBUS. The choices are to rewrite the program (cost: a week of engineering, plus risk of behavioural drift) or to insert a gateway that translates between the two protocols (cost: one DIN-rail box, plus configuration time). The gateway option wins most retrofit decisions, but only when three conditions hold. The legacy protocol is on the gateway's published support list. The data block map is writable from the gateway vendor's configuration tool. The buyer accepts that the gateway is an additional failure point with its own MTBF.

Red Lion Controls makes Crimson-loaded modular controllers (CSMSTR family) and protocol-converter modules (DSPLE series) precisely for this niche. Their Crimson software is well-known in mixed-protocol plants because it lets the same hardware bridge Modbus TCP, Modbus RTU, PROFIBUS, EtherNet/IP, PROFINET, DNP3 and a long tail of legacy serial protocols. We stock CSMSTRLE, CSMSTRV2 and CSMSTRSX as the modular controller rung, and DSPLE000, DSPLE001, DSPSX000, DSPSX001 as the protocol-converter rung in our inventory. We do not write the Crimson configuration for the buyer. We quote hardware per line, quote configuration software separately, and stop.

What we quote, line by line

A typical retrofit BOM for an SCADA bridge looks like this on our quote sheet, with per-line condition stated and per-line MOQ discipline preserved. Stock figures, unit price and lead time come back on the quotation, confirmed per line item; the buyer confirms the configuration file obligation in writing before we ship. Where the buyer asks for a consolidated shipment, the gateway plus its sibling modules ship together under one invoice.

CSMSTRLE (Red Lion modular controller, modular backplane, aiDemandScore 64.52). Used when the buyer wants a flexible rung that can hold a CPU module and up to four PID or communications modules in the same chassis.
CSMSTRV2 (modular controller, value-tier, aiDemandScore 64.32). Used where the buyer only needs the protocol-bridge function and does not want PID slots.
CSMSTRSX (modular controller, serial-heavy, aiDemandScore 63.6). Used where the legacy side is RS-232 or RS-485 with multiple drop addresses.
DSPLE000 (Ethernet protocol converter, base model, aiDemandScore 64.74). Used where the legacy is on Modbus TCP or Modbus RTU and the SCADA side is EtherNet/IP or PROFINET.
DSPLE001 (Ethernet protocol converter, expanded tag count, aiDemandScore 64.24). Used where the data block exceeds a few hundred tags.
DSPSX000 (serial protocol converter, aiDemandScore 63.6). Used where the legacy fieldbus is RS-232 or RS-485 and the SCADA side accepts Modbus TCP or EtherNet/IP.
DSPSX001 (serial protocol converter, expanded, aiDemandScore 63.38). Used for high-tag serial bridges.
CSPID2RM, CSPID2SM, CSPID2TM (PID plus protocol modules, aiDemandScore 64.48 each). Used when the buyer wants a closed-loop PID loop implemented on the gateway rather than on the legacy PLC.
CSPID1RM, CSPID1SM, CSPID1RA, CSPID1SA (PID modules, generation 1, aiDemandScore 63.6 each). Used for legacy CSMSTR chassis or where the buyer already has a Crimson program from a prior installation.

What we will not bridge

Five classes of inquiry we decline at the inquiry stage.

SIL or PL rated end uses. We do not supply protocol gateways for an end use where the gateway would carry a SIL-rated or PL-rated role on the certified device. That determination belongs to the buyer's functional-safety process; we will not be the party that bridges it. We tell the buyer to keep the certified bus on its certified device and to involve their functional-safety engineer. A non-safety converter should not be substituted into a certified role; the certified hardware is the right answer.
Medical device control loops. Component qualification for medical devices belongs to the device manufacturer's quality system, not to a sourcing desk. If the buyer is bridging a Class II or Class III medical device's PLC to a new SCADA, we will not write the configuration file and we will not ship until the buyer confirms in writing that the device maker has approved the change. We do not hold ISO 13485.
End uses outside our service scope. We do not supply for armed-conflict, weapons-platform or related end uses, and we decline the inquiry at the front door if the end-use declaration cannot be screened.
Regulated batch processes where the gateway is the only audit trail. If the regulatory framework requires the data path itself to be validated, the gateway alone is not sufficient. We tell the buyer to involve their validation engineer.
Acting as the system integrator. We will not be listed as the system integrator on the validation document, and we will not sign off on the configuration. Crimson configuration is the buyer's engineering scope.

The 12 axes we walk in a gateway retrofit report

When the buyer asks whether a particular Red Lion module can replace an existing gateway in their cabinet, the cross-reference report we write walks all twelve axes. The buyer-side engineering team uses the report; we do not make the final qualification call. The twelve axes are: form/fit/outline and mounting, dimensions, terminal/interface assignment, electrical parameters, function and I/O specification, firmware version, communication protocol, mechanical parameters, environmental class and EMC, ingress protection and temperature range, materials and construction, certifications and lifecycle. For each axis we record matched, differs or unknown. The most common unknown we see is firmware_version, because the buyer often has a Crimson program from a prior generation and the version compatibility is not always published. We write unknown when unknown; we do not infer. The buyer must verify against the original manufacturer datasheet and the buyer's own qualification process; we do not certify the substitution for them. As a fail-safe, when the firmware version cannot be confirmed, we tell the buyer not to substitute and to keep the original gateway on the bus until the version is read off the device label.

Document choreography for a Russia-bound shipment

A Russia-bound shipment is quoted on the quotation as EXW, DAP, or DDP, exactly as written on the quote. The Moscow-region destination is one of the supported destinations per the quotation; we do not promise a fixed transit time. The shipment travels with a commercial invoice and a packing list. It does not travel with an EAC certificate or a TR CU declaration of conformity; we do not issue EAC, we do not hold TR CU, and we will not act as the conformity assessment body on the buyer's behalf. The component-versus-finished-product compliance responsibility stays with the product placer on the Russian side. We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened.

We also will not write the customs declaration for the buyer. If the quotation states DDP, our scope inside DDP is limited to the carrier-side clearance and the import duty line; it does not include conformity assessment, product registration, or end-use licensing on the buyer's side. The import compliance decision belongs to the importer of record.

When the buyer asks for a Crimson configuration file

We do not write it. We refer the buyer to Red Lion's system integrator network. We will, on request, share the protocol module's published Crimson tag database for the buyer's engineer to start from. We will not be listed as the system integrator on the buyer's validation document, and we will not sign off on the configuration.

How the inquiry should look

The fastest first message for a protocol-gateway retrofit asks for: legacy PLC model and firmware generation, SCADA package and version, expected tag count, target protocol on the SCADA side, ambient environment (cabinet temperature, IP rating requirement, distance between gateway and PLC), and the line-item list of any CSMSTR or DSPLE modules the buyer already has in mind. Photo of the existing cabinet and the existing PLC front plate helps. We do not need the buyer's program; we need the protocol and tag map. If the buyer can already send a BOM with MPN entries per line, the quotation tool at /baojia can pre-process the file before the inquiry reaches our desk.

The takeaway

A protocol gateway retrofit is a low-disruption move that lets a plant keep its existing PLC program while it migrates the SCADA side. It is not the right answer for SIL or PL rated end uses, medical-device control loops, regulated batch audit trails, armed-conflict or weapons-platform end uses, or any end use we cannot screen. We quote hardware per line item, with per-line condition stated and per-line MOQ discipline preserved. We do not write the Crimson configuration file. We do not certify the substitution. We do not issue EAC. We do screen end users and end uses, and we decline what we cannot classify. For a Red Lion protocol-gateway quote, send the cabinet photo, the legacy PLC model, the SCADA package version and the tag count through our inquiry form; the buyer-facing path is /inquiry for the first message and /baojia for a BOM file.

About this article

By aoctrl sourcing desk. Independent distributor and sourcing desk — not an authorized distributor of any brand on the catalogue. Last updated 2026-09-26. Data through September 2026.

Data notes: catalog-grounded product references drawn from the aoctrl.com catalogue (CSMSTRLE, CSMSTRV2, CSMSTRSX, DSPLE000, DSPLE001, DSPSX000, DSPSX001, CSPID2RM, CSPID2SM, CSPID2TM, CSPID1RM, CSPID1SM, CSPID1RA, CSPID1SA). aiDemandScore values are from the aoctrl scoring snapshot of 2026-06-29. Stock, price and lead time are confirmed per line item on the quotation; no fixed values are stated in this article.

FAQ

Can a Red Lion protocol gateway replace an existing CP module on an S7-300 station?

It can, if the Crimson firmware on the Red Lion gateway supports PROFIBUS or MPI on the legacy side and PROFINET or EtherNet/IP on the SCADA side, and if the buyer is willing to maintain the data block map in Crimson rather than in the S7-300 program. We will not write the Crimson configuration file; the buyer's engineer does that, and the buyer must verify against the original manufacturer datasheet and the buyer's own qualification process. For an end use that involves a SIL or PL rated role, we will not supply a non-safety protocol gateway.

How many tags can a CSMSTR or DSPLE bridge hold in practice?

The published tag counts vary by firmware generation and by which protocol pair is in use. We do not quote a number from memory. The right answer comes from the buyer's protocol map and the gateway's published tag-database documentation. We will share the database on request; the buyer-side engineer confirms the tag count against the actual data block.

Will a Red Lion gateway ship on a Russia-bound DDP order?

It can, when the quotation states DDP. We do not promise a fixed transit time. The shipment carries a commercial invoice and a packing list; it does not carry an EAC certificate or a TR CU declaration of conformity. We do not issue EAC, we do not hold TR CU, and the component-versus-finished-product compliance responsibility stays with the importer of record. We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened.

What is the difference between CSMSTRLE and CSMSTRV2?

CSMSTRLE is the modular controller rung for buyers who want PID slots or communications modules in the same chassis; CSMSTRV2 is the value-tier rung for buyers who only need the protocol-bridge function. The Crimson firmware is shared across the family, but the backplane I/O and the slot count differ. The buyer picks the rung based on whether they need closed-loop PID on the gateway itself or only a transparent bridge.

Can I get Crimson configuration written for me as part of the order?

No. Crimson configuration is the buyer's engineering scope, not part of the hardware order. We refer buyers to Red Lion's system integrator network for that work. We will share the protocol module's published Crimson tag database so the buyer's engineer has a starting point; we will not sign off on the configuration file.

What if the gateway firmware version is unknown in the buyer's cabinet?

Then the firmware-version axis of our cross-reference report is written unknown, not inferred. We do not guess. The buyer reads the firmware version off the device label or out of the existing Crimson program, and the version comparison goes back into the report. For legacy CSMSTR or DSPLE installations where the firmware generation is from a prior Crimson release, we treat that as a known-unknown and ask the buyer to confirm before we ship.

Do you quote protocol gateways for a CNC retrofit on a S7-1200 line?

We can, when the S7-1200 is the legacy side and the SCADA side is PROFINET or EtherNet/IP. The Crimson configuration file is the buyer's engineering scope. The cabinet environmental section matters: we ask for the cabinet temperature, the IP rating and the cable distance to the legacy PLC before we quote. We do not promise a fixed lead time or a fixed unit price; both come back per line item on the quotation.