RUIYI

Other Systems & Customization Suite

Robot Control System

RoboticsControl

The hard part of robotic work is rarely the robot. It is the waiting: a handling arm standing idle while a conveyor delivers, a machine holding a part while the next station is blocked, a whole line stopped because one station missed its window. Coordination is what turns a set of machines into a process.

Robot Control System coordinates industrial robots — arms, mounting and handling equipment, conveying and transfer machines — from one place instead of one screen per machine. Programmes, movements and the relationships between machines are held as configuration under version, and what is about to run is checked before it is released.

What it deliberately does not do is stand between the machine and its safety. The interlock logic that protects a person stays where it belongs, in the machine's own safety arrangement. This application coordinates work: what runs, when, in what order, and what happened.

Machines do not fail to coordinate. They wait for each other in the order somebody happened to build.

One console for the cellSequences under versionChecked before releaseInterlocks stay with the machines

What it is

  • One place for the cell. Every machine registered with what it is, what it can do and what it is connected to, instead of existing only inside its own programming.

  • Coordination between machines. What may run together, what must wait, and for how long — held as configuration rather than left to the timing in each program.

  • Sequences as versioned configuration. A change to how the cell runs is a controlled change with a record, not an edit made on a machine while production is running.

  • Checked before release. What is about to run is verified against the configuration — timings, interlocks between machines, conditions that must hold — before it is allowed to start.

  • What actually ran is retained. Which sequence ran, when, and what the machines reported, so a stoppage can be looked at afterwards.

  • Machines keep their own safety. The hardware safety arrangements, guards and emergency stops remain the responsibility of the machine and the site's safety design, and this application does not replace them.

What gets in the way today

One screen per machine. Nobody can see the cell, only the machines.

  • Each machine is programmed and watched separately. So coordination happens in the timings somebody typed into each program.

  • A change to one machine means visiting it. Which is why changes get made when nobody is watching, and not always recorded.

  • The version of each program is not obvious from the machine. So nobody can say what is actually loaded.

Waiting is invisible. Time is lost between machines, not inside them.

  • An arm stands idle and nobody can say whether it is waiting or broken. So the first response is to go and look.

  • A transfer machine waits for a part that arrives late, and the whole cell absorbs it. Which never appears as a number anywhere.

  • Cycle time is measured per machine. Which misses the fact that the cell's time is set by the slowest handshake in it.

A stop stops everything. One machine's problem becomes the cell's problem.

  • An abnormal stop on one machine halts the rest. Because the sequence has no defined way to pause and resume.

  • Restarting means manual intervention at the machine. Which needs someone who knows that particular cell.

  • What was in progress when it stopped is not always known. So recovery starts by working out what was halfway through.

The cell on the floor is not the cell in the office. The configuration and the reality drift.

  • A machine is replaced and the program is adjusted on the spot. So the configuration no longer describes what is running.

  • Timing that was tuned is never recorded. So a maintenance visit resets it and nobody knows.

  • Changes made during production are not captured anywhere. Which is how a cell becomes unreproducible.

Several robots, one sequence

The same four points for every cell, however many machines are in it.

Several robots, one sequenceMachines are registered with what they are and what they can do. Work is coordinated across them so one machine waits for another deliberately rather than by luck. The sequence is checked before it is released, and what ran is retained afterwards.RegisterWhat each machine isCoordinateWho waits for whomReleaseChecked before it runsReviewWhat actually ranCoordination, not a screen per machineThe interlock logic stays with the machines; this is the layer above them

What the site configures is the coordination: which machines may run together, what must be true before a sequence starts, and what happens when one machine in the sequence stops. What each machine does inside its own safety envelope remains its own. The separation is deliberate: this application is the layer that decides what runs next, not the layer that decides whether a person may be near the machine.

What you get

Every machine in one placeWhat each machine is, what it can do and what it is connected to, held once rather than inside its own programming.
Waiting designed rather than accidentalWhat may run together and what must wait is configuration, so idle time is a decision.
Cycle time you can account forThe time between machines is visible, which is where most of the waiting in a cell actually happens.
Stops with the reason attachedWhich machine stopped, at which point in the sequence, and what it reported at the time.
State and sequence in one viewWhere every machine is and what it is doing, without switching between screens.
Changes made as changesA modified sequence is a versioned release with a record, not an edit made on a machine while it is running.

Where it is used

What changes between these settings is how many machines interact, and how much the cell changes over its life.

Setting

What robot control usually focuses on

Machining and assembly cells

Arm, machine and transfer coordination, and the cycle time between them

Handling and palletising

Sequences that depend on what is available on the infeed

Mounting and installation systems

Machines that must act together in a defined order with defined conditions

Conveying and transfer lines

Handshakes between conveyors, buffers and downstream equipment

Cells that are changed often

Product changes, machine replacement and layout changes kept under configuration

Capabilities

Grouped by what they do.

Capability

What it means

Machine register

Each machine, what it can do, what it is connected to, and where it sits in the cell

Sequence management

Work defined as a sequence of steps, with the conditions each step depends on

Coordination rules

What may run together, what must wait, and for how long

Version control

Sequences held under version, with what changed between releases recorded

Pre-release checks

Timings, handshakes and required conditions verified before a sequence is allowed to run

State monitoring

Where every machine is, what it is doing, and what it reported

Stop and resume

Defined behaviour when a machine in the sequence stops, including what happens to work in progress

Abnormal handling

Stops routed with the reason attached, and the in-process state recorded for recovery

Cycle and wait analysis

Time inside machines and time between them, seen separately

Product changeover

Sequence and parameter changes for a new product handled as configuration

Maintenance support

What was running when a fault occurred, and what it reported at the time

Simulation and dry run

Check a sequence before it is released to the floor

Operator interface

A consistent interface across machines, rather than one per machine

Integration

Connect to the line control layer, the machines themselves, and the systems that carry the work

Deployment choice

On the cell controller, a machine controller, or centrally, decided by latency and by availability requirements

Roles and retention

Role-based access, retention set by policy, with releases and overrides logged

How it works

  1. Register the machines. What each machine is, what it can do, and what it connects to.

  2. Define the work. The cell's work expressed as sequences of steps, with the conditions each step depends on.

  3. Set the coordination. What may run together, what must wait, and how long a wait is acceptable before it is flagged.

  4. Check and release. A sequence is verified against the configuration and then released, under version.

  5. Run and watch. State, waits and stops are visible, and a stop carries the reason and the in-process state.

  6. Change and release again. A change is a new version with a record, not an edit made on a running machine.

Boundaries and what it does not decide

  • It coordinates; it does not make machines safe. Guards, emergency stops and the safety functions that protect a person stay in the machine's own safety arrangement and under the site's safety design. This application must not be part of that safety chain.

  • It does not replace the machine's own control. Movements inside the machine's envelope remain governed by the machine.

  • It does not prove a cycle time is achievable. It shows where time goes between machines, which is usually the part nobody was looking at.

  • Where it runs. On the cell controller, on a machine controller or centrally, decided by latency and by what happens to production if a connection is lost.

  • What is local. Machine safety, guarding and working practices are determined by the site's risk assessment and the local rules, not by this application.