Configuring Do-more Stage Programming for CTRIO2 Homing

The CTRIO2 home routine runs as a reusable staged program after placing it in its own Do-more PROGRAM code block, starting it with RUN from $Main, and ending its completion stage with EXIT. Monitor Home.Done in the calling logic before allowing the machine sequence to continue.

Reject the quick fixes first

Do not force the tested homing logic into a subroutine. The programming environment does not allow the required CTRIO instructions there, so rearranging contacts or adding another subroutine call will not correct the block-type restriction.

Do not place repeated copies of the routine throughout $Main either. That may get one sequence moving, but it creates multiple versions of the homing logic and makes later corrections harder to control. A separate PROGRAM code block provides a single routine that can be started where the application needs it.

Check before moving on: confirm that the failure occurs when inserting the CTRIO instruction into a subroutine, not because of an incomplete operand or unrelated editor error.

Choose the correct Do-more code block

$Main is already a PROGRAM code block, so stage logic can run inside it. A new PROGRAM code block is not mandatory merely because stages are used. The separate block becomes the better choice when the homing sequence must remain self-contained and be started more than once from the main machine logic.

Other PROGRAM code blocks receive their own set of 128 stage bits. Those bits are not shared with the 128 stage bits belonging to $Main. This separation prevents a stage transition in Home from directly consuming the stage state assigned to $Main, but it also means online troubleshooting must be performed in the correct block.

Keep machine-level permissives and requests in $Main. Keep the ordered CTRIO2 homing steps, transitions, completion handling, and local stage state in Home. This divides responsibility without converting the motion routine into an unsupported subroutine.

Check before moving on: open the code-block properties and verify that Home is a PROGRAM, not a subroutine or task.

Create and connect the Home program

1. Open $Main in Do-more Designer.
2. Insert a RUN instruction where the homing request is accepted.
3. Enter Home as the program to run.
4. Watch the element-editor indicator. It changes from red to yellow when Home is a syntactically valid name that does not yet exist.
5. Press Enter in the RUN editor.
6. When prompted, create the new heap item.
7. Answer Yes to create both the single PROGRAM element and its actual code block.

Designer should open the new Home code block. If it creates only a name without an editable PROGRAM block, stop and inspect the creation choice before copying any motion logic. The calling instruction needs a real executable program object, not an unresolved element.

Drive RUN Home from a deliberate homing request. Avoid an unconditional rung during commissioning: a continuously asserted request can hide whether later starts are separate commands or merely the same command remaining active. Use the surrounding sequence to prevent production motion from proceeding until homing finishes or an abnormal condition is handled.

Check before moving on: compile the project and verify that Home resolves as a valid PROGRAM element in the RUN instruction.

Move the tested CTRIO2 stages intact

Copy the known-good home routine into Home without changing its motion order at the same time. First prove that relocating the logic preserves its behavior; streamline transitions only after the separate program runs correctly.

Stage execution is state-oriented. Only the active stage path should command the current homing step, while transitions advance the routine through its defined sequence. Because Home owns a separate stage set, references intended to coordinate with $Main must use explicit program status or other deliberate shared conditions rather than an assumption that corresponding stage numbers represent the same state.

Review every CTRIO2 instruction operand after the move. Confirm that the same module references, command conditions, completion indications, and abnormal-state paths used by the tested routine remain connected. A clean compile proves syntax and element resolution; it does not prove that a physical axis is ready to move.

During the first online test, inhibit downstream automatic sequencing and observe the active stage before issuing the home request. Stop here if the initial stage is unclear, more than one stage appears to command conflicting motion, or the CTRIO2 diagnostics show an unresolved condition.

Check before moving on: issue one controlled request and verify that Home enters the intended first stage and follows the tested transition order.

Terminate the sequence with EXIT

Add an EXIT instruction in the completion stage of Home. Reaching that instruction stops the Home program and sets its .Done status bit. For a program named Home, use Home.Done in $Main as the notification that the staged routine has finished.

Place EXIT only on the successful completion path. If it is placed in an earlier stage, Home.Done can report completion before all homing actions finish. If it is omitted, the program does not provide the intended completion event through this mechanism and may remain in its terminal stage.

Keep fault or abort handling distinct from successful completion. Do not use Home.Done alone as proof that the mechanism reached a safe physical home position; combine program completion with the position or module indication already used by the tested routine. If the application needs separate success and failure outcomes, expose those outcomes explicitly to $Main rather than treating every program stop as success.

Check before moving on: watch Home.Done transition only after the completion stage executes EXIT.

Prove repeated operation end to end

1. Start from a known safe machine condition and clear the external homing request.
2. Apply one request and verify that RUN starts Home.
3. Observe each expected stage transition and the associated CTRIO2 response.
4. Confirm that the completion stage executes EXIT, the program stops, and Home.Done becomes available to $Main.
5. Remove the first request and verify the calling sequence leaves its completed state as designed.
6. Apply a second distinct request and confirm that the program starts at the intended entry state rather than resuming an unintended stage.
7. Repeat once with a controlled abnormal condition and verify that production sequencing does not interpret it as successful homing.

The second start is the critical commissioning check when the routine will be used several times. Observe the program status and stage state online; their actual transitions determine whether the request logic provides a clean new invocation. Do not infer repeatability from one successful cycle.

Check before release: complete two separate home requests, verify the physical home indication on both, and confirm that downstream logic advances only after the corresponding Home.Done event and the routine's physical success condition.

FAQ