The symptom: after power-up the actuators never go to their home positions. The homing logic sits in the Run First Scan Only task, and it uses potentiometer and proximity switch feedback. When the Manual/Auto selector is in Manual, the Manual mode logic in a Run Every Scan task resets the outputs and nothing moves. The cause is not a firmware bug. The first scan task runs for exactly one scan, and a scan is far shorter than any physical move.
Skip the Quick Fixes That Do Not Work
These are the usual first attempts. Each one fails for a scan-cycle reason, not a wiring reason.
| Quick fix | Why it fails |
|---|---|
Leave homing in Run First Scan Only and hope it finishes |
The task is active for one scan only, on power-up or on a Stop-to-Run transition. It never runs again. A rung that waits for a prox switch is evaluated once, found false, and passed over. |
| Add a loop or a jump back so the homing rungs repeat until the home switch makes | Physical outputs are not written until the scan ends, and physical inputs are not re-read until the next scan starts. Inside the loop the actuator never gets its output and the prox never changes state, so the scan stalls. Logic that jumps back to an earlier point is poor ladder practice for this reason. |
| Move the Manual/Auto logic into a separate task, expecting outputs to update between tasks | Outputs are updated once, after every active task has been evaluated. Splitting code across tasks changes the order in which internal memory is evaluated. It does not create an extra output update. |
| Switch the selector to Auto at power-up to get past it | This hides the bug. The homing code still runs for one scan, so the actuators still do not home. |
Get it running, then fix it properly. The proper fix is a flag set on first scan and a homing task called every scan until the home conditions are proven. The checks below confirm that this is your fault before you rewrite anything.
Check 1: Find Where the Motion Code Lives
Open the Task Management window and find the task that contains the homing rungs.
-
Homing is in
Run First Scan Only: go to Check 2. This is the most likely fault. -
Homing is in a
Run When Calledtask: find theCall Taskinstruction that calls it. If that call sits in the first scan task, you have the same problem one level down, so go to Check 2. If the call sits in aRun Every Scantask, go to Check 3. -
Homing is in a
Run Every Scantask: the one-scan limit does not apply. Go to Check 3.
How the first scan task works: it executes once on power-up and once on each Stop-to-Run transition. That is the only time it is ever active. All other active tasks execute top to bottom in the order they appear in the task window.
Check 2: Count How Many Scans the Homing Needs
Read the homing rungs and answer one question: does any rung depend on a physical input changing because of an output the same code turns on? A prox switch that makes after the actuator travels is an example. So is a potentiometer value that reaches a window after motion.
- Yes: the routine needs many scans. It cannot work in a one-scan task. Go to the rebuild procedure.
- No: the code only initializes values, such as setpoints, counters, or mode bits. That is valid first scan work. The fault is elsewhere, so go to Check 3.
The mechanism works like this. Each scan has three phases:
- Read all physical inputs and store their states in memory.
- Evaluate the logic in every active task. Coils write to internal memory only, not to the terminals. Input images can be overwritten in this phase because they are only memory now, and that is a trap of its own.
- Copy the output memory to the physical outputs.
Execution never parks on a rung until it goes true. It tests the rung and moves on. A homing sequence therefore spans many scans:
- On scan 1 the output coil is set in memory.
- At the end of scan 1 the output energizes.
- Over the following scans the actuator moves.
- Some scans later the prox makes and is read at the start of a scan.
A task that runs only on scan 1 sees none of the steps after the first.
Check 3: Find Every Rung That Writes the Same Outputs
Cross-reference every output the homing routine drives. List every rung in every task that writes those same addresses.
-
Manual mode logic writes them too: the last write in the scan wins. On the first scan, the first scan task writes the output ON in memory. The Manual mode rung in a
Run Every Scantask then writes it OFF before the output update. The terminal never sees ON, not even for one scan. This is exactly the symptom where homing only fails in Manual. - Only the homing code writes them: go to Check 4.
Task order matters here, but only for internal memory. A task lower in the window sees values that tasks above it wrote during the same scan. It can also overwrite them. Use this to control which logic has the final say over an output. Do not expect it to push anything to the terminals early.
Check 4: Look for Loops, Jumps, and Special I/O
- Loops or backward jumps: remove them from the homing path. They hold the scan without refreshing I/O and push scan time up.
- Immediate I/O instructions or high-speed I/O: these can read or write the hardware outside the normal scan-end update. The simple rule of inputs at the start and outputs at the end may not hold for those points. Check the instruction help for each one before you rely on its timing.
-
A
Run Every Secondtask holds part of the startup logic: check whether it runs on the first scan by setting a latch in it and looking at that bit in a data view right after a Stop-to-Run. Do not assume it runs alongside the first scan task.
If none of these apply and the outputs still do not energize while the flag logic below is working, stop here. Check the output module status and the field wiring before you change any more code.
Match the Symptom to the Branch
| What you see | Cause | Branch |
|---|---|---|
| No motion at power-up in either Manual or Auto | Homing is inside the one-scan first scan task | Check 2, then rebuild |
| No motion in Manual, partial or odd motion in Auto | Homing is one-scan, and Manual logic also overwrites the same outputs | Checks 2 and 3 |
| Homing works, but other logic fights it while it runs | Other tasks are not blocked while homing is active | Rebuild, step 4 |
| Controller slows down or scan time jumps during homing | A loop or backward jump waits for a feedback signal | Check 4 |
| Homing repeats after a program download | Normal: the first scan task runs again on Stop-to-Run | Decide whether that is acceptable (rebuild, step 6) |
| Output state disagrees with the rung that should control it | A later task writes the same address | Check 3 |
Rebuild Homing Around a GO_HOME Flag
The first scan task does one thing: it sets a flag. A task that is called every scan does the actual homing and clears the flag when the home conditions are proven. Everything else waits until the flag clears.
-
Empty the first scan task. Leave only the rung that sets
GO_HOME, plus any pure initialization with no feedback dependency. -
Move the homing rungs into their own
Run When Calledtask. Keep the potentiometer and proximity switch logic intact. -
Add a
Call Taskto the firstRun Every Scantask, conditioned onGO_HOMEbeing ON. Put it at the top so homing is evaluated before any other logic in the scan. -
Condition all other logic on
GO_HOMEbeing OFF. This includes the Manual/Auto selector handling and anything else that writes the homing outputs. Otherwise the Manual mode reset overwrites the homing outputs later in the same scan. -
Clear
GO_HOMEinside the homing task when the home-complete conditions are true, for example the potentiometer is within its home window and the home prox is made. Drop the homing outputs on the same rung or in the same scan. -
Decide the restart policy. Because the first scan task runs on every Stop-to-Run, a download or mode change re-triggers homing and moves the actuators without an operator command. If that is not acceptable, set
GO_HOMEfrom an operator pushbutton, or require the selector in a defined position before the call is enabled. -
Add a homing timeout. Start a timer while
GO_HOMEis ON. If it expires before the home-complete conditions are met, stop the outputs and raise an alarm. Take the preset from the measured stroke time of the slowest actuator, not from a guess.
TASK: Run First Scan Only
Rung 1: ----------------------------------------( SET GO_HOME )
TASK: Run Every Scan (first in list)
Rung 1: --[ GO_HOME ]----------------------------( Call Task: Homing )
Rung 2+: --[/GO_HOME ]--[ Manual/Auto logic ... ]-- (all normal code gated OFF during homing)
TASK: Homing (Run When Called)
Drive actuators toward home based on pot value and prox state
--[ pot in home window ]--[ home prox ]---------( RST GO_HOME )
--[ GO_HOME ]--[ timer done ]--------------------( stop outputs, raise homing fault )The same structure answers the question about sequences. A sequence or state machine does not hold the scan until it completes. It is evaluated once per scan like any other logic and advances a step when its conditions become true. It "owns" an output only if no logic later in the scan writes that output. If another task writes the same address, the sequence loses control. Gate that other logic with the sequence's active bit the same way GO_HOME gates the normal code above.
Verify Before Handing the Machine Back
-
Watch the flag. Put
GO_HOME, the home prox inputs, the potentiometer value, and the homing outputs in a data view. Cycle Stop-to-Run. The flag must go ON, stay ON through the move, and clear only when the home conditions are met. - Test in both selector positions. Power up with the selector in Manual, then again in Auto. Homing must complete the same way in both. If it only works in Auto, some Manual logic is still ungated, so go back to Check 3.
-
Confirm the outputs follow the homing task. While
GO_HOMEis ON, force-free observation must show the homing outputs energized at the module, not only in memory. - Test the timeout. Block or disconnect one home prox (with the machine safe) and confirm that the timer stops the outputs and raises the alarm.
- Check scan time. For machine control, a target around 10 ms (about 100 full scans per second) is a sound benchmark. Slower processes tolerate longer scans. Anything needing much tighter timing, such as precise positioning, belongs in a dedicated motion controller, with the controller only supplying commands like the end position. A scan time that jumps during homing points to a leftover loop.
- Test a mid-move restart. Cycle Stop-to-Run with the actuators away from home and confirm the restart policy you chose in step 6 behaves as intended.
FAQ
Does the P3000 Run First Scan Only task run again after a Stop-to-Run transition?
Yes. It executes once on power-up and once on each Stop-to-Run transition, and it is never active at any other time. Any motion it triggers, directly or through a flag, repeats after a download or mode change unless you gate it.
Can I split logic into multiple tasks to update physical outputs partway through the scan?
No. Physical inputs are read at the start of the scan, and physical outputs are written after all logic in all active tasks has been evaluated. Task order only controls which internal values later tasks see and which write lands last.
Does a sequence stop the scan until it completes?
No. A sequence is evaluated once per scan and advances when its step conditions are met, while every other task keeps running. If other logic writes the same outputs later in the scan, it overrides the sequence, so gate that logic with the sequence's active status.
Can I use a loop in the first scan task to wait for the home prox switch?
No. Inside the loop the outputs are never written to the module and the inputs are never re-read, so the actuator does not move and the prox never changes. Set a GO_HOME flag instead and call the homing task every scan until the home conditions clear it.
Stop and call the manufacturer's official technical support if the outputs never energize while the GO_HOME task is active and the module status and wiring check out. Also call if the first scan task behaves differently from the once-per-power-up or Stop-to-Run pattern. Have the project file, the controller firmware version from the system information, and a data view capture of the flag and I/O ready.