Follow the keypress. The check key on the pendant does not send "advance one line" to the controller. It sends "run the loaded task until the next motion target is reached, then hold." That request lands in the AS interpreter, which walks the program counter forward, executes every non-motion instruction it passes without stopping, hands the next taught point to the trajectory generator, and only returns control to the pendant when the arm settles on that point. The hop between two motion instructions is atomic from the operator's side.
That is why ten signal sets, three conditionals and a timer sitting between two taught points all fire on one keypress. There is no stopping place defined between them, because check mode's granularity is the motion segment, not the program step.
Where does the step request stop?
Two program formats sit on the same controller and they debug differently. Block programs are structured as a table of motion steps with auxiliary instructions hung off each step; the pendant editor addresses them by step number, and the step number is the motion. AS language programs are line-oriented text executed by the interpreter, and the interpreter maintains a real program counter that can be positioned on a non-motion line.
Layer one first. Before blaming the debugger, confirm the pendant is in teach mode with the enable device held, check speed override is non-zero, and the task you are stepping is the task you edited — a background or PC task keeps running at full speed while you step the main task, and its outputs will move underneath you.
Which debugging paths does the controller actually give you?
| Approach | Granularity | Driven from | Stops on logic lines? | Setup cost |
|---|---|---|---|---|
| Check forward / check back (CHECK GO / CHECK BACK) | One motion instruction | Teach pendant | No | None — native |
AS monitor single-step (STEP-class command) |
One program step | Terminal over serial or Ethernet | Yes, on AS programs | Terminal session + cable/IP |
Single instruction execution (DO-class command) |
One typed instruction | Terminal | Yes — you supply the line | Terminal session |
| Inserted breakpoint (wait-on-input or hold instruction) | Wherever you place it | Pendant, no PC needed | Yes | Edits the program; must be removed |
| Subroutine decomposition + call | One call | Terminal or pendant | Yes, per block | Restructures the program |
| Print trace to terminal window | Continuous, no stop | Terminal | Logs every line you instrument | Low; non-invasive to timing |
| I/O and variable monitor screens | Continuous | Pendant | Observes, does not stop | None |
Kawasaki's debugging model was built around motion-to-motion verification for block programming, so a pendant-only "step one line" facility is not the default path. If you need it as a supported feature on your controller generation and software version, your local Kawasaki distributor is the authority on whether an option exists for it — the pendant firmware level decides that, not the program.
How do you force a stop on a logic line?
Two mechanisms give you a real breakpoint without a terminal. Both work by turning a logic position into something the interpreter must wait on.
- Bracket the suspect range. Identify the first and last program line you doubt, and note the taught points either side of them.
- Insert a wait-on-input instruction immediately after the line of interest, referencing a spare, unwired input that is currently off. Execution reaches that line and stalls there with the program counter parked.
- Run the task in check or repeat, low speed, guarded.
- When it stalls, read state: open the variable monitor for the values written by the preceding lines, and the I/O monitor for the outputs those lines were supposed to set.
- Release the breakpoint by forcing that spare input on from the I/O force screen (teach mode only), then force it off again before the next cycle.
- Move the breakpoint down one line and repeat until the line that produces the wrong value is isolated.
- Delete every inserted wait before the program returns to production.
If forcing inputs is prohibited on your cell, use a hold-type instruction instead and resume from the pendant's cycle start — same effect, no forced I/O, but you lose the ability to leave the breakpoint armed across cycles.
The variant that scales better: pulse a spare output high before the suspect line and low after it, then watch that bit on the PLC's trace or a scope. You get execution order and dwell time per line without stopping motion, which is the only way to catch a race that disappears at check speed.
Which path should you use?
For AS language programs, drive the debug from the AS monitor over the serial or Ethernet port. The monitor exposes single-step execution of the loaded program and single-instruction execution of a typed line, which is exactly the line-by-line granularity the pendant does not offer. Confirm the command syntax and its arguments against the operations manual for your controller's software version before you rely on it — the command set differs between controller generations.
- Connect the PC to the controller's terminal port. Serial: match baud, data bits, parity and stop bits to the controller's communication parameters. Ethernet: set the PC to the controller's subnet and confirm the terminal port with a ping first — layer one and layer three before you blame the terminal software.
- Open the monitor session and confirm the prompt responds. No prompt means wrong port, wrong parameters, or the port is assigned to another function.
- Load or select the target program and position the program counter at the first line you want to examine.
- Issue the single-step command once per line. After each step, print or display the variables and signal states that line was supposed to change.
- Where a line depends on an input the cell cannot produce on the bench, execute the branch condition manually as a single typed instruction and observe which way the interpreter goes.
- For a block program, split the logic into a named AS subroutine, call it from the monitor with the arm held clear, and step the subroutine instead of the parent.
Verification and the pitfalls that repeat
Outputs are commonly inhibited or remapped in teach mode. A logic line that waits for a field device's acknowledge will sit forever if the commanding output never physically energizes, and that reads exactly like a hung program. Check the output state on the I/O monitor and at the terminal block before concluding the logic is wrong.
Check speed also changes the answer. Timing-dependent logic — handshakes with a PLC, gripper confirm windows, conveyor tracking — behaves differently at 10% check speed than at cycle speed, so a defect that only appears in repeat mode will not reproduce under check. Trace it with output pulses at production speed rather than stepping it.
Three more that cost time: an aborted task resumed with a restart command begins at line one rather than the held line, so distinguish resume from restart; edits applied to a task that is loaded but held may not take effect until the task is reloaded; and background or PC tasks are not stepped by the main task's debugger, so an output you see toggling may not come from the lines you are walking.
Close the job by running the corrected program through one full cycle in repeat mode at production speed with the program listing on screen, and confirm the pendant's step display advances to the same taught point as the fault-free reference cycle at each handshake — then re-verify that no wait-on-input or hold breakpoint remains anywhere in the listing.
FAQ
Can I step a Kawasaki program one line at a time from the teach pendant?
Not with the check keys. Check forward and check back advance one motion instruction and execute every non-motion line in between without stopping. Line-level stepping comes from the AS monitor over the terminal port, or from breakpoints you insert into the program.
Does check mode execute the logic instructions between two taught points?
Yes. Every signal set, timer, assignment and conditional between the two points runs in program order on a single keypress, which is why a logic fault looks like it happened "at" the next motion step.
Can I use a wait-on-input instruction as a breakpoint in production code?
Only during debug. Reference a spare unwired input, release it by forcing the input in teach mode, and delete the instruction before handing the cell back — a forgotten breakpoint stalls the cycle with no fault code to explain it.
Does the AS monitor single-step work on block programs?
Line stepping applies to AS language programs, which the interpreter runs line by line. For block programs, move the logic you want to examine into an AS subroutine and step that, or trace it with spare output pulses. Confirm what your controller's software version supports with your Kawasaki distributor.