After the retrofit, the press should execute each machine state through a documented control path, reject unsafe transitions independently of the standard controller, and expose diagnostics for every field signal. For the ARBURG ALLROUNDER 220-75-250, serial 137638, that outcome requires more than replacing the failed floppy drive or translating the old schematics into EtherCAT terminals. The decisive work is reconstructing the machine sequence, characterizing every electrical interface, and validating the safety functions.
Where does the control path begin, and where can it stop?
Follow the packet from an operator request to the physical actuator. A start command enters the controller, the sequencing logic evaluates permissives, the EtherCAT master updates its process image, an output module drives a valve or contactor, and feedback returns through an input. A command that disappears anywhere along that path produces the same visible symptom: no motion.
| Path segment | Address or interface | Timing or setting | Reading to take |
|---|---|---|---|
| Operator request to sequence | HMI variable or controller tag | Task update configured in the new controller | Confirm the command changes once and remains valid for the intended state |
| Sequence to EtherCAT master | Mapped process-image bit or word | Bus cycle and control-task relationship | Compare commanded data with transmitted process data |
| Master to I/O terminal | EtherCAT topology and logical mapping; no TCP or UDP application port | Configured EtherCAT cycle | Check link, slave state, working counter, and topology diagnostics |
| I/O terminal to field device | Physical terminal and conductor | Output update plus device response | Measure terminal voltage or current under load |
| Device back to controller | Sensor terminal and input mapping | Input filtering and control-task sampling | Compare the physical state, terminal indication, and controller value |
EtherCAT can carry deterministic standard I/O, but deterministic transport does not make the application logic complete or the safety system valid. Loss of a network cable, controller task, I/O power group, sensor, or output driver must lead to a defined machine state.
Does the physical layer match the proposed I/O?
Layer one first. Use the original electrical schematics to locate sensors, motors, heaters, valves, pressure signals, temperature channels, and safety circuits. Then verify each device at the machine. Old drawings identify connections; they do not prove that later repairs preserved the drawing or that a modern terminal can drive the load directly.
| Device class | Reading or document needed | Decision |
|---|---|---|
| Discrete sensor | Supply, active-state voltage, polarity, leakage, conductor reference | Select a compatible input and define open-wire behavior |
| Valve or contactor coil | Coil voltage, steady current, inrush, suppression, switching arrangement | Use a rated output or an interposing device with suitable suppression |
| Temperature channel | Sensor construction, conductor count, range, isolation, existing transmitter details | Select the matching temperature input; never infer sensor type from wire color alone |
| Pressure channel | Signal type, supply, scaling, reference, range, failure indication | Configure the analog channel and scaling from the device data |
| Motor or heater | Nameplate, starter or power-controller topology, feedback, protective devices | Retain only hardware that can be controlled, protected, and diagnosed correctly |
| Safety device | Contact architecture, reset behavior, diagnostics, final switching path | Assign it to a safety-rated design rather than ordinary process I/O |
Record field readings with the machine isolated where required. Mark discrepancies on an as-built drawing. Before selecting Beckhoff or other EtherCAT hardware, complete this signal register; otherwise terminal selection becomes guesswork.
Can the original machine sequence be reconstructed?
The obsolete controller contains behavior that the electrical prints do not show: mode selection, startup conditions, interlocks, pressure and temperature permissives, alarm latching, manual functions, automatic-cycle transitions, recovery after interruption, and timeout handling. Read the operator manual and outline every function before writing replacement logic.
Model the process as explicit states rather than a collection of loosely coupled outputs. For each state, document the entry conditions, commanded outputs, expected feedback, exit conditions, abort conditions, operator indications, and permitted recovery action. Trace manual, setup, and automatic operation separately. A manual output command must not bypass guards, hydraulic permissives, travel limits, or mutually exclusive valve logic.
Exercise the original controller only when it can be operated safely. Capture input and output behavior without defeating interlocks. If the failed floppy drive prevents program handling but the remaining controller functions, a compatible drive emulator or repair can preserve the machine while the sequence is documented.
Does repair or a complete retrofit resolve the actual problem?
| Reading or condition | Meaning | Next branch |
|---|---|---|
| Only the floppy drive has failed and the controller still operates correctly | The storage interface may be the narrow fault | Evaluate a compatible emulator or repair before removing control hardware |
| Replacement requires recurring repair of obsolete proprietary cards | The support problem extends beyond removable media | Compare a full retrofit with machine replacement |
| The machine sequence cannot be documented or tested | A replacement controller cannot be acceptance-tested against a known specification | Recover documentation and behavior before implementation |
| Field devices cannot be characterized or supported | Keeping original hardware transfers obsolescence into the new system | Replace the affected device or abandon the retrofit branch |
| Current safety obligations cannot be met within the project | The retrofit cannot be commissioned responsibly | Repair within an approved scope or replace the machine |
Engineering cost can exceed the value of an old press even when the new controller hardware appears inexpensive. Include I/O investigation, software design, electrical changes, drawings, safety assessment, validation, commissioning, training, spare parts, and production downtime. Read clamping force and all electrical ratings from the machine nameplate; the model string is not a substitute for rated data.
Can LinuxCNC control the press by itself?
LinuxCNC provides programmable real-time control and EtherCAT integration, but CNC motion experience does not supply an injection molding machine sequence or a validated safety architecture. The press is primarily a state-controlled hydraulic and thermal process with guarded hazardous motion. Its controller must manage interlocks, modes, alarms, temperature control, pressure-dependent transitions, interruption recovery, and controlled shutdown.
A PLC runtime on an industrial PC is the clearer default when EtherCAT I/O is already planned. It expresses discrete sequencing, diagnostics, retained settings, alarm handling, and maintainable state logic in a form familiar to industrial service personnel. LinuxCNC may remain useful only where a defined function specifically benefits from it and the responsibility boundary is documented.
Neither a PLC nor LinuxCNC should be treated as the safety layer merely because its cycle is deterministic. Route guard monitoring, emergency stopping, reset logic, and removal of hazardous energy through a safety-rated architecture selected from the applicable machine requirements and validated for the modified press. Determine the current legal and safety obligations for the installation before altering the original controls.
How should the resolving retrofit branch be executed?
- Freeze the current condition. Back up every recoverable setting and program, photograph cabinets and terminations, label conductors, and preserve the unmodified schematics.
- Create an as-built I/O register. For every point, record device function, physical terminal, electrical characteristics, normal state, failed state, controller mapping, and related machine state.
- Write the functional specification from the operator manual and observed behavior. Include all modes, state transitions, permissives, alarms, resets, aborted-cycle recovery, heating behavior, and hydraulic shutdown behavior.
- Define the safety concept separately. Identify hazards, protective devices, final switching elements, reset rules, diagnostics, and validation tests under the rules applicable to the modified machine.
- Select the controller and EtherCAT terminals from measured interface requirements. Partition power groups and separate standard process signals from safety functions.
- Bench-test the controller, network, and I/O mapping with simulated loads and signals. Force only within the controlled test setup, never as a substitute for machine interlocks.
- Commission one function at a time with hazardous energy controlled. Verify input polarity and scaling before enabling outputs, then test each actuator at reduced risk before allowing automatic transitions.
- Challenge every permissive and feedback path. Disconnect or suppress one expected signal at a time and confirm that the state machine blocks the transition, raises the correct diagnostic, and commands the defined safe response.
- Run the documented acceptance sequence in manual, setup, and automatic modes. Record actual EtherCAT state, process-image values, physical measurements, alarms, safety-test results, and final as-built revisions.
FAQ
Can I retrofit an ARBURG ALLROUNDER 220-75-250 with EtherCAT I/O?
Yes, if every original signal is electrically characterized and mapped before terminal selection. EtherCAT solves the I/O transport layer; it does not reconstruct the machine sequence or validate safety functions.
Can I use LinuxCNC as the only injection molding controller?
LinuxCNC can execute real-time logic, but the replacement still needs a complete state model, process control, diagnostics, recovery behavior, and a separate safety-rated architecture. A PLC runtime is generally the more maintainable basis for this sequence-heavy application.
Does replacing the failed floppy drive avoid a full retrofit?
It can if the removable-media interface is the only fault and the proprietary controller remains serviceable. Test the controller and evaluate a compatible emulator or repair before dismantling it.
Can I keep the original hydraulic valves, heaters, and drives?
Keep a device only after recording its supply, command interface, load, feedback, protection, and failed-state behavior. Replace any device that cannot be safely driven, protected, diagnosed, or supported by the new controls.
Does a successful automatic cycle prove the retrofit is complete?
No. The final verification is to challenge each permissive, feedback, network-loss response, guard function, stop function, and recovery path, then record the physical readings and acceptance result in the revised machine documentation.