Simulating KRC2 Robot I/O Before Machine Construction

After the simulation bindings are separated from the physical I/O bindings, the KRC2 can exercise palletizing logic with manually forced states or an automatic SPS sequence. Use this to test branches, interlocks, and sequence recovery—not to validate positions against conveyors, sensors, or guarding that do not yet exist.

What is the screen telling you?

The program is waiting because its logical conditions never change. With no electrical cabinet, sensors, conveyor, or installed gripper, the controller receives none of the field transitions expected by the palletizing sequence. A part-present input remains inactive, a conveyor-running confirmation never arrives, or a storage-full condition never changes.

This does not automatically mean the palletizing logic is wrong. Trace the stalled instruction back through three layers:

When a named condition displays the expected meaning but never responds to a test stimulus, the tag is right; the binding is wrong for the current test mode.

Which simulation approach fits the test?

Use a staged hybrid. Start with manual variables because they expose each prerequisite and make recovery testing easy. After every module behaves correctly, use an SPS drum sequencer to reproduce the normal cycle. This avoids building a 100-point simulator before the program has been divided into testable behavior.

All 100 logical points can be represented as variables, but they should not all be driven simultaneously without a state model. Divide them by machine function—conveyor, part detection, gripper, storage, permissives, and faults—and simulate only the transitions needed for the active test case.

Why does changing the binding make simulation possible?

The palletizing program should read symbolic names such as conveyor_on, sensor_part_present, and storage_full. During controller-only testing, declare those names as Boolean variables in $config.dat:

DECL BOOL conveyor_on
DECL BOOL sensor_part_present
DECL BOOL storage_full

The program can then read the same names while the operator or SPS changes their values. When the electrical system becomes available, replace the test declarations with physical signal mappings:

SIGNAL conveyor_on $IN[1]
SIGNAL sensor_part_present $IN[2]
SIGNAL storage_full $IN[3]

The shown addresses are the mappings supplied for this example, not a proposed allocation for a new cabinet. The final addresses must come from the project I/O list.

Keep one active declaration for each symbolic name. A Boolean declaration and a physical SIGNAL declaration using the same name are alternative bindings, not two declarations to load together. This separation lets the robot program remain unchanged when the hardware layer changes.

How should the I/O simulation be built?

1. Create an inventory of every symbolic condition used by the palletizing program. Record whether each point is a command, status, permissive, completion signal, or fault.
2. Select one program module, such as conveyor acquisition or gripper handling. List its starting state, required transitions, expected outputs, completion condition, timeout behavior, and recovery path.
3. Replace the physical input mappings needed by that module with Boolean declarations in $config.dat. Do not create competing declarations for the same tag.
4. Set the initial values manually. Test inactive, active, stuck-active, and missing-transition cases before automating the normal sequence.
5. Confirm each program output or internal state change in the controller display. A transition must occur because the intended condition changed, not because an unrelated bypass remained active.
6. Add the tested points to the automatic sequencer, then repeat the process for the next module.

For outputs that are easy to reach from the operator interface, spare outputs can serve as labeled manual flags. Long texts reduce mistakes when many test conditions are visible. Keep a written mapping between each flag and the logical condition it represents.

How can the SPS generate repeatable sensor events?

Call a simulator conditionally from the SPS loop. When simulation is disabled, reset scan so the next test begins from its initialization state:

IF use_simulation THEN
   simulator()
ELSE
   scan = 0
ENDIF

A simple drum sequencer changes Boolean states at defined scan values:

DEF simulator()
   SWITCH scan
   CASE 0
      conveyor_on = FALSE
      sensor_part_present = FALSE
      storage_full = FALSE
   CASE 3
      conveyor_on = TRUE
   CASE 5
      sensor_part_present = TRUE
   CASE 14
      sensor_part_present = FALSE
   CASE 25
      conveyor_on = FALSE
   CASE 162
      storage_full = TRUE
   ENDSWITCH

   WAIT SEC 0.025
   delay_count = delay_count + 1
   IF delay_count >= 40 THEN
      delay_count = 0
      scan = scan + 1
   ENDIF
END

The threshold represents 40 waits of 0.025 seconds, so each scanMeasure observed transitions if exact timing matters. For the “part no longer detected” event atCASE 14, assign FALSE; assigning TRUE would leave the sensor latched.

A wait inside the SPS affects how often other SPS work runs. Keep the simulator small, watch controller responsiveness, and avoid placing machine-critical background functions behind a test delay.

How do you verify the program without the machine?

Controller-only simulation validates logical sequencing, branching, output commands, and handling of generated input states. It cannot prove that robot positions align with the absent conveyor, pallet, gripper, or fixtures. It also cannot reproduce field wiring faults, sensor response, load behavior, or interference with unbuilt equipment.

Before commissioning, restore the approved physical SIGNAL mappings, verify every point against the cabinet I/O list, and test real field transitions independently. Position validation must wait until the mechanical references exist; perform it under the site’s controlled robot setup and commissioning procedure.

Frequently asked questions