MCT Nexus
Electrical Design
Electrical documentation that connects machine requirements to the panel, field devices, and controls. MCT Nexus develops coordinated design packages for new equipment and machine changes.
MACHINE CONTROLS SOFTWARE
Machine sequences, operator screens, and diagnostics developed around how the equipment actually runs. MCT Nexus supports new controls software and changes to existing PLC and HMI applications.

SERVICE SCOPE
Controls software must handle normal production, manual operation, faults, and recovery. We translate the process into defined machine states and operator actions, then coordinate the program with the electrical design and field devices. Our engineering background includes Allen-Bradley and Omron-based equipment.
PROJECT DELIVERABLES
Define how the machine starts, stops, changes mode, and recovers from interrupted cycles.
Show the condition preventing operation and the information needed to investigate it, rather than relying on a generic fault message.
Agree program organization, comments, backups, software versions, and handover information with your team.
PROJECT APPROACH
Review the machine sequence, I/O, operating modes, platform, and acceptance conditions.
Build the application, review operator interactions, and test available logic and interfaces before machine startup.
Check I/O, sequence behavior, alarms, and recovery during the agreed commissioning and acceptance activities.
COMMON QUESTIONS
Yes, subject to access to the project files, compatible software, and a review of the current application. Backups and a rollback approach are agreed before changes.
It can. The proposal identifies software development, site work, testing, travel, and handover as appropriate so the responsibilities are clear.
CONNECTED CAPABILITIES
MCT Nexus
Electrical documentation that connects machine requirements to the panel, field devices, and controls. MCT Nexus develops coordinated design packages for new equipment and machine changes.

MCT Nexus
Coordinate separate machines, controls, and devices into a working production sequence. MCT Nexus defines the interfaces that let equipment exchange status, commands, and process information.
MCT Nexus
Move from assembled equipment to verified operation with a defined startup plan. MCT Nexus supports controls checkout, sequence testing, acceptance activities, and the information your team needs after startup.
An alarm should help identify the condition that prevents operation and the approved recovery path. Review the machine states, sensor feedback and interlocks before adding more messages.
A new sequence can affect operator screens, drive settings, network interfaces, recipes and production data. Define those dependencies so the testing scope matches the actual machine change.
Agree editable source files, software versions, device configurations, backups and a change record. Discuss who will maintain the system and what access they need before the final handover.
Continue with our PLC program handover checklist.
Tell us the PLC and HMI models, the machine sequence, available source files, and what needs to change.
Industrial PLC programming begins with a description of what the equipment must do. MCT Nexus reviews automatic cycles, operator tasks, manual functions, start conditions, stop conditions and the behavior required after a fault. The control narrative becomes a reference for programming and testing rather than leaving critical behavior to assumptions made during startup.
For existing machines, we review available backups and compare the documented sequence with the equipment. An uploaded controller file may not contain all comments, project information or dependencies needed for maintainable changes. Software versions, licenses, device configurations and access requirements are identified before a migration or major modification is committed.
The PLC program coordinates inputs, outputs, states, permissives and equipment interfaces. A useful structure makes the current step understandable and separates a command from the condition that confirms it happened. Timeouts and abnormal conditions need explicit responses. Where appropriate, sequences are organized so a technician can identify the active step and the condition preventing progress.
Manual operation requires its own requirements. Jogging an axis, opening a valve or running a conveyor can create different conditions from an automatic cycle. Review access, permissives and protective functions for each mode. The operating program does not replace the machine’s required safety system or risk assessment.
HMI programming covers status pages, navigation, alarms, recipes, maintenance information and authorized settings. The operator should be able to tell whether the machine is ready, waiting, running, stopped or faulted. Important permissives should be described in plain language related to the actual equipment.
Alarm design includes the condition, message, acknowledgment behavior and the state required to clear it. A history can help diagnose intermittent events, but it needs useful timestamps and context. Adding more alarm messages without prioritizing them can obscure the actual cause of a stop. We review the information the operator and maintenance team need during production.
Recipe requirements identify which settings change between products, permitted limits, approval responsibilities and how the selected recipe is verified. Equipment communications define ownership of commands and status, handshake timing and the response to a lost connection. Where data collection is included, agree on identifiers, units, timestamps, storage responsibilities and how an unavailable destination affects the machine.
The industrial network and tracking requirements should be considered with the software design. A successful message transfer alone does not prove that the correct result has been associated with the correct part.
Programming checks can include simulated inputs, device-level tests, dry cycles and representative production sequences. The test plan should address interrupted cycles, reset, restart, unavailable equipment, invalid recipes and communication loss where applicable. FAT and commissioning establish which checks can be completed before shipment and which require the installed machine.
Agree on native PLC and HMI project files, comments, software versions, configuration records, network information and recovery instructions. Ownership and licensing of reusable libraries or third-party software should be clear in the scope. Backup files need to correspond to the delivered machine revision, not an earlier development copy.
For a new inquiry, identify the controller and HMI if already selected, the machine sequence, I/O, connected equipment and whether startup support is needed. For changes to an existing program, include the current issue, available files and the shutdown window. See our PLC program handover checklist for the information that helps keep a machine supportable.