Name: ZYPLC
Address: CN
Telephone: +86 19859288691

Industrial automation spare parts, urgent sourcing, and global supply support.

A small VersaMax station beside a pump can look like a self-contained controller even when its job is to exchange I/O with a controller elsewhere. That visual similarity creates an expensive spare-parts mistake: ordering a CPU for a station whose head is a network interface unit, or treating a CPU replacement as though it only needs a network address.

The quickest useful question is not how many modules are attached. It is where the application logic runs. That answer determines who owns the program backup, which configuration has to be restored, and which hardware reference belongs on the purchase request. A shared VersaMax family name does not resolve those responsibilities.

Trace the decision-making path through the installation

Emerson’s VersaMax modular I/O and control brochure distinguishes controller CPUs from network interface units. It lists CPU references such as IC200CPU001 and IC200CPUE05 separately from network heads such as the PROFINET IC200PNS001 and PROFIBUS IC200PBI001. The distinction is architectural, not merely a difference in connector shape.

For a CPU-based station, the recovery scope includes the application running in that controller and its associated configuration. For a remote I/O station, the controlling application may live in an upstream PLC, while the local head exchanges field data over its specified network. Both can stop production, but they do not necessarily require the same archive, software or replacement procedure.

Use the electrical drawings, hardware configuration and actual nameplate together. Do not infer the station’s role from an Ethernet socket, a green indicator or the presence of nearby I/O slices. Those observations are useful evidence, but they cannot establish where a pump sequence or interlock is evaluated.

Read the exact reference before discussing alternatives

An enquiry for a VersaMax IC200CPU001 CPU should identify the installed controller and its application recovery requirements. Emerson’s IC200CPU001 product entry identifies it as a CPU with built-in serial communications. That is a different equipment role from a network interface unit, even when both appear at the left of an I/O station.

The IC200CPUE05 VersaMax CPU is another controller reference that can appear in a plant’s inventory. Its existence does not make it an automatic replacement for CPU001. Any change between references needs an application-specific review of the supported configuration, software, communications and installed equipment. This article is not a conversion procedure.

Old catalog descriptions sometimes use “controller,” “interface” and “module” loosely. Make the complete order code the stable identity, and use manufacturer documentation to resolve the function. If the listed title and the documented model role disagree, request clarification instead of incorporating the ambiguity into the material master.

Three recovery records that should agree

First, maintain a hardware record showing the head reference, local module arrangement and relevant carrier or terminal details. Second, keep the application and configuration archive that applies to that station. Third, record the network relationship: which equipment communicates with it, which engineering project describes that relationship, and who can restore it.

These records do not have to be elaborate, but they must agree. A cabinet photograph from commissioning can become misleading after a later modification. A backup file with an unexplained name may belong to another machine. An IP address list cannot substitute for the configuration that defines how field signals are interpreted.

For remote I/O, ask the upstream-controller owner to confirm the recoverable hardware configuration and the documented response to communication loss. For a local CPU, ask the application owner to confirm the program baseline and restoration method. Keep any field-specific retained values or commissioning data under the site’s established change-control process rather than assuming a generic archive contains everything.

Use the failure evidence to choose the spare boundary

Consider a pump station that loses indication at the control room. A head-module failure is one possibility. So are a communication interruption, local power trouble, a configuration discrepancy or a fault elsewhere in the control chain. The maintenance record should distinguish observations from conclusions before a replacement is authorized.

Capture relevant diagnostics through the approved tools and procedures. Identify whether the local station is powered, whether the controller reports a communication or configuration problem, and which signals are affected. Do not disconnect equipment or alter addressing on a running process simply to test a theory. Production and safety constraints govern how evidence can be collected.

A spare request should state whether it is an exact recovery item for a diagnosed component or a stock-risk reduction purchase. Those are both legitimate purposes, but they lead to different acceptance questions. The first needs confidence that the failed function has been identified. The second needs confidence that the spare covers the intended installed population.

What to confirm before accepting delivery

Compare the offered label and condition with the request, establish the agreed test scope, and confirm any included accessories. Preserve the serial or traceability information in the receipt record. If commissioning support is needed, arrange it before the outage rather than assuming the delivered hardware will provide the missing application knowledge.

Plan recovery verification around the process, not just the module LEDs. The authorized commissioning team should confirm the intended I/O interpretation, communication behavior and operational sequence using the approved test plan. A station that exchanges data is not necessarily a station whose signals have been mapped correctly.

Frequently asked questions

Does an Ethernet connection mean the unit is only remote I/O?

No. A network connection does not identify where the application executes. Read the exact hardware reference and confirm the engineering configuration. Controller CPUs and network interface units can both participate in networked installations while serving different roles.

Can a CPU be ordered instead of a network head?

Not as an assumed spare substitution. Changing the station role can require a different control architecture and engineering work. Use the installed reference for recovery, or treat the proposed change as a separately approved redesign.

Is the program backup enough for a remote I/O replacement?

It may not describe every required setting or physical arrangement. Confirm the upstream hardware configuration, station identity, module order and relevant network documentation. The responsible engineer should identify the complete recovery package before the replacement is scheduled.

What should I send when the station identity is unclear?

Provide clear nameplate photographs, the complete station layout and an authorized configuration extract with sensitive details removed. Include the equipment function and observed symptoms. These allow the enquiry to be narrowed without guessing from the general family appearance.

Send ZYPLC the exact VersaMax head reference, quantity, required condition and destination. State whether the requirement is for a CPU-based station or remote I/O, and flag any unresolved identification. A correctly scoped quotation starts with that distinction.

Image: AI-generated editorial illustration, not an exact product photograph or installation reference.

A controller change on a mature machine is rarely just a processor swap. The CPU determines program capacity, memory behavior, supported expansion, communications and timing assumptions that have accumulated in the running project. The Omron CJ1M-CPU13 is a specific member of the CJ1 family, and model suffixes matter. A spare that looks close in a catalog may not have the same built-in I/O, Ethernet function, unit version or application behavior. Begin with an inventory and backup exercise while the existing machine is still stable, not during the first production outage caused by a failed CPU.

Capture the complete installed configuration

Photograph the CPU nameplate and every unit in the rack. Record CPU model and unit version, power supply, I/O units, special and CPU-bus units, expansion rack, communication adapters, memory card, network addresses and the cable paths. Note controller error history and the last known-good program revision. Omron’s CJ1M documentation differentiates models by I/O points, program capacity, data memory, expansion-rack support and built-in functions. These differences can change what a replacement can execute even when the front panel and rack dimensions appear similar.

Check the CPU13 limits against the real project

Omron’s official CJ1M operation manual lists the CPU13 variant with 640 I/O points, 20K steps of program memory and 32K words of data memory; it also distinguishes the CPU13 from the CPU23 built-in-I/O model and from Ethernet-equipped -ETN versions. Treat those figures as a screening checklist, then confirm the unit version and exact manual for the installed controller. Review actual program use, I/O table, special-unit count, high-speed functions, retentive areas and communications. A listed maximum does not prove that the present application is portable without revalidation.

Do not use a close family number as a substitute

ZYPLC lists an Omron CJ1M-CPU13 CPU module and a separate CJ1G-CPU43H controller reference. These are different order codes and must not be treated as drop-in alternatives. Compare the exact model, I/O and memory requirements, built-in functions, unit version, expansion capability, programming software and communications before selecting a replacement. The catalog item can help identify a part to quote; the site engineer owns application fit and the change approval.

Make the backup restorable

Save the online project and controller data using the supported Omron tools and site version-control process. Capture PLC program, comments and symbols, I/O table, routing tables, network settings, special-unit parameters, data memory values and any retained recipes or machine constants that the process owner approves for backup. Record software version and communication method. Open the backup on a controlled engineering workstation and verify it is readable. A file that exists is not a recovery plan unless its dependencies, passwords, licenses, cables and restoration steps are also available.

Plan migration and rollback as separate work

For a planned replacement, map every signal and its physical terminal to the program address. Identify pulse, interrupt, positioning, serial and network functions whose timing or configuration may change. Define how current process values and retentive memory will be transferred, what must be initialized, and who authorizes each step. Keep the old CPU and a verified project snapshot available until the new controller passes the agreed functional tests. For a failed CPU, do not assume data in memory can be recovered; use the approved backup and follow the vendor procedure for any upload or restore.

Test the machine, not only the CPU status

After controlled installation, verify power-up diagnostics, rack recognition, communication links, I/O mapping, analog scaling, interlocks, alarm texts, sequence state and operator functions. Test representative operating modes and safety-related behaviors with production and safety teams present. Compare critical timing and handshake data against the old baseline. The related ZYPLC guide on Omron compact PLC I/O evidence before machine recovery covers field-side documentation; use it alongside the CPU inventory rather than assuming identical project constraints. Update the spare register, drawings, software archive and as-left revision before closing the work order.

Separate emergency recovery from lifecycle migration

A like-for-like CPU recovery and a platform modernization are different decisions with different approval, budget and validation needs. If a verified CJ1M-CPU13 spare restores a stable machine, document that recovery without implying that the obsolescence question has disappeared. Separately assess whether memory, communications, engineering-tool access or expansion limits threaten the next operating period. Estimate engineering effort, cabinet changes, software conversion, operator training and outage duration alongside hardware cost. This separation lets the team restore production under a controlled scope while giving management a realistic, evidence-based modernization request rather than an emergency proposal written during a breakdown.

Questions maintenance teams ask

Is CJ1M-CPU13 the same as CJ1M-CPU13-ETN?

No. The suffix identifies a different execution. Confirm the installed communications feature, unit version and applicable Omron manual before ordering.

Can a CJ1G CPU replace a CJ1M CPU directly?

Do not assume so. Compare program and data memory, I/O, expansion, built-in functions, software support, communications and the actual machine project.

Which data should be saved before a CPU replacement?

Preserve the project, I/O table, routing and network settings, special-unit parameters, approved retained values, tool versions and a tested restore procedure.

Does a successful CPU RUN light prove the machine is ready?

No. Verify application behavior, I/O, alarms, interlocks, communications and representative sequences under the approved commissioning plan.

For a CJ1M sourcing inquiry, send ZYPLC the complete CPU and unit-version labels, rack inventory, software version, project status, expansion details and shutdown date. We can help verify the exact catalog item and the documentation needed for your engineering decision.

Compact machines often fail in practical ways: a PLC will not run, an input never changes, an output will not energize, or an HMI alarm points to a device that has already been replaced twice. Omron compact PLC spares should be selected from CPU role, mixed I/O, terminal wiring, backup status, and the machine test.

ZYPLC readers support equipment where small PLCs carry big production consequences. A clear RFQ prevents a maintenance team from buying a CPU when the real recovery boundary includes remote I/O, sensor wiring, and configuration evidence.

Start With CPU And Program Evidence

Record CPU model, power, expansion modules, communication port, memory or backup status, program version, I/O count, fault history, and the machine sequence affected.

The live Omron CP1E-N40SDR-A PLC CPU unit is the product match when machine recovery depends on compact PLC identity.

Photograph labels, wiring, expansion connection, power terminals, LEDs, communication cable, backup evidence, and the alarm screen before removal.

Mixed I/O Requires Channel-Level Notes

A mixed I/O module can restore one function and still leave another uncertain if channel type, terminal wiring, common power, or sensor polarity was not recorded.

The related Omron SRT2-MD16T-1 mixed I/O module helps frame channel-level evidence for remote or distributed I/O recovery.

Ask suppliers for actual photos, terminal scope, condition, tested status, accessory inclusion, and any substitute limits before the machine window opens.

Acceptance Should Run The Machine Sequence

After replacement, verify CPU RUN state, program load, I/O diagnostics, sensor inputs, actuator outputs, communication, alarms, and a controlled machine cycle.

If the machine still fails, review field power, terminals, sensor wiring, common connections, output loads, backup file, and safety interlocks before rejecting the spare.

Store labels, channel list, backup file status, photos, cycle-test notes, and maintenance approval with the spare record.

RFQ Evidence That Makes The Spare Usable

Send CPU labels, I/O photos, channel list, sensor and actuator details, backup status, condition requirement, and machine deadline.

An Omron compact PLC RFQ should say whether the site needs CPU recovery, distributed I/O recovery, or a complete machine-control spare package.

For substitutes, require controls review of I/O type, terminal scope, program compatibility, communication, and acceptance testing.

A strong spare request does not start with the cheapest matching description. It starts with the installed function, the exact hardware identity, the accessories needed to install it, and the acceptance test that will prove the plant can run again.

That discipline matters more as legacy automation fleets age. Similar modules can differ by firmware, connector, terminal base, memory device, communication option, environmental rating, or configuration dependency. Those differences are easy to miss when the buyer only sends a copied model family.

Actual-item photos remain one of the most useful controls. Front labels, side labels, connector faces, terminal blocks, memory cards, rack slots, cable tags, and LED states often expose the difference between a usable spare and a part that will create another maintenance delay.

Condition language should also be clear. Factory sealed, new surplus, refurbished, repaired exchange, tested used, and untested used items are not equal. Ask what was tested, what accessories are included, and what still has to be validated at site.

The RFQ should name the fallback path before the order is placed. If a substitute fails bench or field acceptance, the plant should know whether it can reinstall the old item, use a repaired exchange, isolate a noncritical function, or escalate the migration plan.

Receiving inspection should repeat the same checks used in the RFQ. Compare photos, labels, connector condition, accessory scope, and visible damage before the item enters stores as a critical spare.

For shutdown work, keep the spare evidence with the maintenance package. A useful record includes the supplier response, approved photos, configuration notes, test results, and the name of the engineer who accepted any substitution risk.

Good documentation also improves the next purchase. If the same platform appears in several lines or units, a clean record prevents each engineer from rediscovering the same suffix, cable, firmware, or terminal detail under outage pressure.

This is not paperwork for its own sake. It is the practical bridge between procurement speed and engineering confidence, especially where obsolete PLC, DCS, SIS, or monitoring hardware still protects production.

When lifecycle pressure is already visible, record it without exaggeration. Scarcity, weak test evidence, missing accessories, and frequent substitution requests are sourcing facts that help justify a planned migration without inventing unsupported claims.

The final purchase decision should compare availability, condition, test evidence, accessory completeness, shipping route, and acceptance risk together. A fast spare that cannot pass the site test is not truly fast.

Where possible, ask maintenance, controls, reliability, and purchasing to agree on this evidence before the outage. One shared checklist prevents late arguments about whether the spare is electrically correct, operationally useful, and acceptable for the risk carried by the asset.

FAQ

What must match on an Omron compact PLC spare?

Match CPU model, power, I/O scope, communication ports, backup compatibility, expansion layout, and machine test method.

Why include mixed I/O evidence?

Because a similar module may differ by channel type, common wiring, terminals, or sensor/output behavior.

What should the RFQ include?

Send labels, wiring photos, channel list, backup status, condition requirement, and recovery deadline.

What proves recovery?

RUN status, loaded program, healthy I/O diagnostics, working sensors and outputs, clear alarms, and approved machine cycle.

Send ZYPLC the Omron labels, I/O photos, channel list, backup status, condition requirement, and recovery deadline. We can help prepare a compact PLC spare RFQ.

Modernization pressure around legacy PLC platforms is real, but many plants still need a controlled TSX Premium recovery before migration can happen. Schneider TSX analog I/O spares should be selected from channel range, terminals, wiring, calibration, processor dependency, and the migration evidence the plant is building.

ZYPLC readers need practical steps that keep a process running while engineering prepares longer-term replacement. A spare purchase can be both an emergency recovery action and a useful signal for the migration file.

Start With The Analog Channel

Record module model, channel list, input range, sensor type, terminal assembly, loop power, shielding, calibration status, alarm history, and the process consequence of losing each signal.

The live Schneider TSXAEY414 analog input module is a direct product match when the RFQ concerns analog channel recovery.

Photograph labels, terminal wiring, sensor tags, cabinet position, diagnostic LEDs, and trend or alarm evidence before removing the module.

Processor Context Shapes The Migration Window

An analog module can be correct while the processor, project backup, rack, or firmware still blocks a clean recovery. The spare record should keep the controller context visible.

The related Schneider TSXP4720 TSX Premium processor helps connect I/O sourcing with controller lifecycle planning.

Ask suppliers to state exact condition, terminal inclusion, photos, channel test evidence, and whether a substitute changes configuration or calibration work.

Acceptance Should Prove The Signal

After replacement, verify module recognition, channel diagnostics, input range, loop power, scaling, alarms, trend behavior, and controlled simulation or calibration checks.

If the signal remains wrong, review wiring polarity, sensor health, terminal seating, shield grounding, project configuration, and input range before rejecting the spare.

Store photos, calibration notes, backup status, channel list, test results, and migration implications with the spare record.

RFQ Evidence That Reduces Downtime

Send module labels, channel list, terminal photos, sensor details, project-backup status, condition requirement, test scope, and migration deadline.

A TSX analog RFQ should say whether the plant needs immediate like-for-like recovery or a substitute that supports a staged migration.

For substitutes, require review of terminals, channel ranges, calibration, processor compatibility, and acceptance testing.

The core discipline is simple: prove identity, prove function, and prove acceptance. Identity confirms the installed hardware. Function explains what the plant expects the spare to restore. Acceptance defines how maintenance will know the replacement is ready for service.

This matters because mature automation platforms rarely fail in isolation. A module, cable, terminal, firmware note, project backup, cabinet power path, and field device can all shape the same symptom. The RFQ should keep those dependencies visible instead of reducing the request to a copied title.

Actual-item photos are still one of the fastest ways to remove uncertainty. Front labels, side labels, connector faces, terminal assemblies, memory devices, handles, latch points, and accessory scope often expose differences that a catalog description hides.

Condition language should be precise. New surplus, factory sealed, refurbished, repaired exchange, tested used, and untested used parts should not be compared as if they had the same risk. Ask what was tested and what remains a site responsibility.

For urgent downtime, define the fallback before ordering. If the item fails bench or field acceptance, the plant should know whether to reinstall the old unit, try a repaired exchange, isolate a noncritical function, or escalate toward migration.

Finally, keep the purchasing evidence with the spare after it arrives. If the evidence disappears into email, the next engineer has to repeat the same investigation under more pressure. A good spare record saves time twice: once during sourcing and again during the restart.

Receiving inspection should repeat the same evidence check. Compare the approved photos with the received item, confirm connector condition, verify included accessories, record visible damage, and keep packaging notes when the item has fragile terminals, exposed boards, probes, displays, or communication ports.

The request should also state what the supplier is not being asked to prove. If field configuration, software loading, safety validation, or final loop testing remains the plant responsibility, say so clearly. Clear boundaries reduce confusion when the maintenance window is already open.

For plants with several similar systems, include the installed unit or machine name. A spare that fits one package skid, turbine train, boiler burner, or PLC rack may not be suitable for the next cabinet even when the brand and family appear the same.

If lifecycle pressure is part of the discussion, record it without exaggeration. Scarcity, weak test evidence, missing accessories, or frequent substitution requests are useful signals for migration planning, but they should be supported by sourcing facts rather than assumptions.

Good RFQs do not slow the job down. They remove vague follow-up questions and give the supplier a fair chance to confirm exact stock, repaired exchange options, substitution limits, and realistic dispatch timing before the plant commits to a recovery path.

FAQ

What must match on a Schneider TSX analog spare?

Match model, channel count, input range, terminals, loop power, configuration, diagnostics, and calibration test.

Can another TSX analog module be used?

Only after channel range, wiring, terminal scope, project configuration, and controls approval are checked.

What should the RFQ include?

Send labels, terminal photos, channel list, sensor details, backup status, condition requirement, and deadline.

What proves recovery?

Recognized module, correct signal range, stable trends, cleared diagnostics, valid calibration, and approved loop test.

Send ZYPLC the Schneider TSX labels, terminal photos, channel list, project-backup status, condition requirement, and migration deadline. We can help prepare a controlled TSX spare RFQ.

A PACSystems RX3i CPU failure can freeze a machine cell, but the CPU is only one part of the recovery. Firmware, backplane, power, Ethernet settings, memory, project backup, I/O modules, and controller role all decide whether the spare can restart the equipment safely.

ZYPLC readers need a CPU RFQ that helps controls engineers as much as buyers. A similar RX3i processor may look close in a product list, but a rushed replacement without project and rack evidence can create another outage.

Capture The Installed Controller Context

Record CPU model, firmware, rack, backplane, power supply, Ethernet ports, IP address, memory, project backup, I/O list, remote drops, HMI and drive links, and the machine function controlled by the rack.

The live GE Fanuc IC695CPU310 RX3i reference is a product match for CPU recovery. Compare firmware, rack role, project compatibility, Ethernet settings, and installed function before approval.

Photograph the CPU label, rack, power supply, Ethernet cables, memory device, adjacent modules, cabinet environment, diagnostic LEDs, and any fault or project status screen.

A Nearby CPU Is Not Automatically Equivalent

The CPU family, firmware level, memory, port behavior, performance, and project support can differ. Treat a processor change as a controls decision, not a cosmetic part swap.

The related GE Fanuc IC695CPE305 RX3i CPU reference is useful for comparing RX3i processor options, but it still requires project, firmware, rack, and communications review.

Ask suppliers to quote exact, tested exchange, refurbished, and substitute CPU options separately. Include firmware evidence, actual condition, warranty, dispatch timing, and configuration support assumptions.

Restart Testing Should Include The Machine

After replacement, verify CPU boot, firmware, project restore, Ethernet communication, I/O recognition, remote drops, HMI and drive links, alarms, interlocks, recipe data, and the approved dry run.

If the rack boots but the machine does not behave correctly, review project version, IP address, I/O mapping, field power, HMI tags, drive communications, and downloaded parameters.

Store the CPU with a project-backup note, firmware evidence, rack photos, I/O list, network map, and final restart approval.

What Makes The RFQ Actionable

Send CPU labels, rack and power photos, firmware, project backup status, Ethernet settings, I/O list, condition requirement, test scope, and restart deadline.

Ask for actual-item photos, not only a product-family statement. Connector condition, battery or memory scope, and firmware notes can change installation risk.

For modernization, keep direct CPU replacement and migration separate. A migration may be smart, but it needs software conversion, validation, and a longer outage plan.

The useful discipline is to keep identity, function, and approval separate. Identity says what the part is. Function says what the plant expects it to restore. Approval says who can accept the risk when one detail differs.

For older control systems, the cheapest mistake is usually made before the order: a photo is missing, a firmware note is assumed, a cable is treated as generic, or a tested exchange is compared with an untested used item. Those small gaps become expensive only when the cabinet is open.

Ask for actual-item photographs when the schedule is tight. Front labels, side labels, terminals, connectors, latch points, power markings, and accessory scope often reveal more than a polished catalog description.

The purchasing record should travel with the spare after it arrives. If the item goes into stores without the evidence that justified the purchase, the next maintenance team has to repeat the same work under worse conditions.

Do not let the word compatible replace engineering judgment. Compatible can mean electrically similar, physically similar, repairable, configurable, or only suitable after a migration review. Spell out which meaning applies.

A good spare plan also names the fallback. If the replacement fails bench checks or field acceptance, the plant should know whether it will reinstall the old item, use a repaired exchange, isolate a noncritical function, or escalate to a migration decision.

The article topic should also connect to real search intent. Maintenance engineers are usually not searching for theory; they are searching because a rack, network segment, safety channel, drive axis, or loop is already fragile. Write the RFQ around that pressure.

Condition language needs discipline. New surplus, factory sealed, refurbished, repaired exchange, tested used, and untested used items do not carry the same risk. A buyer should ask which condition is being offered before comparing lead time or price.

Accessory scope is another common trap. Terminal blocks, memory cards, SFP modules, connectors, mounting clips, cables, batteries, license media, and configuration files may be outside the base item. Name them early so the spare can be installed, not merely received.

For critical equipment, the acceptance method should be written before the purchase order is approved. A loop test, axis jog, proof test, node diagnostic check, or network failover test tells the supplier and the plant what ready actually means.

Document the unresolved points openly. If firmware is unknown, configuration is unavailable, or a substitute requires engineering review, the RFQ can still move forward, but the risk should remain visible instead of disappearing into the quote notes.

This approach does not slow procurement down; it gives procurement something precise to send. A well-documented request usually gets a more useful response because the supplier can confirm exact stock, repair path, or substitute limits without guessing.

FAQ

What must match on an RX3i CPU spare?

Match CPU model, firmware, rack and backplane role, memory, Ethernet settings, project compatibility, I/O dependencies, and restart test.

Can another RX3i CPU replace it?

Only after firmware, project, performance, ports, memory, rack compatibility, and controls approval are reviewed.

What should the RFQ include?

Send labels, rack photos, firmware, project status, network settings, I/O list, condition requirement, and restart deadline.

What proves PLC recovery?

CPU boot, project restore, recognized I/O, stable network links, restored HMI/drive communication, alarms, interlocks, and approved dry run.

Send ZYPLC the GE Fanuc CPU labels, rack photos, firmware and project status, Ethernet details, condition requirement, and restart deadline. We can help prepare a controlled RX3i spare RFQ.