Rung order matters
Rungs run from the top down. Rung 0 reads Motor before rung 1 writes it.
Step by step
Pick a step. The rungs are drawn by the editor after Core scans the program up to that step.
Global.MotorXIC
Global.RunLampOTE
Global.StartPBXIC
Global.MotorOTE
1. Press StartPB. Rung 0 runs first and reads Motor as 0. Then rung 1 turns Motor on. RunLamp is still off.
Global.MotorXIC
Global.RunLampOTE
Global.StartPBXIC
Global.MotorOTE
2. Scan 2. Rung 0 now reads Motor as 1, so RunLamp turns on, one scan late.
Global.MotorXIC
Global.RunLampOTE
Global.StartPBXIC
Global.MotorOTE
3. Release StartPB. Motor turns off in rung 1, after rung 0 has already read it as 1. RunLamp stays on.
Global.MotorXIC
Global.RunLampOTE
Global.StartPBXIC
Global.MotorOTE
4. Scan 4. RunLamp turns off, again one scan late.
| Step | StartPB | Motor | RunLamp |
|---|---|---|---|
| 1. Press StartPB | 1 | 1 | 0 |
| 2. Scan 2 | 1 | 1 | 1 |
| 3. Release StartPB | 0 | 0 | 1 |
| 4. Scan 4 | 0 | 0 | 0 |
Why it works
- In one scan the rungs run in order. Rung 0 reads Motor as it was left by the last scan.
- Rung 1 then writes Motor. Rung 0 sees the new value on the next scan.
- One scan is a few milliseconds on a real machine, but the delay matters for one-shots and for sequences that check a value right after writing it.
Common mistakes
- Expecting the change in the same scanPut the rung that writes a tag above the rungs that read it, when they must agree in the same scan.