Do-more Designer Error: Split the Rung, Not the Branch

Production returns when the rejected branch is rewritten as two accepted rungs: one drives OUT MC41, and the other drives the TMR/MOVE path. In Do-more Designer 2.5.1, Compiler Error: Trying to AND above a JOIN is a code-generation limit in the stack-based Boolean implementation, not proof that the requested machine sequence is logically impossible.

Drop the quick fixes that cannot compile

Do not spend downtime repeatedly moving the same branch or trying to force acceptance. Get it running by separating the outputs, then clean up comments and duplicated conditions after the machine is stable.

Read the compiler error as a topology fault

Do-more Designer translates ladder into stack-based Boolean operations. A simple series path maps cleanly to operations such as:

STR X0
AND X1
OUT Y0

The compiler can also continue evaluating after an output when the stack state remains unambiguous:

STR X0
AND X1
OUT Y0
AND X2
OUT Y1

The rejected structure is different. An output is evaluated on one path, and the program then needs an earlier Boolean result again to process logic above or across a join. Generating that sequence requires preserving and restoring a stack value. Conceptually, the generator would need operations such as:

STR X0
DUP
AND X1
OUT Y0
POP
AND X2
OUT Y1

DUP represents duplicating the top stack value, while POP restores the earlier evaluation context. The controller instruction set can represent this type of work, but Do-more Designer 2.5.1 does not generate and reverse-generate the required ladder form. That is why visually modest logic can still produce Trying to AND above a JOIN.

Do not diagnose this first as a CPU performance problem. The deciding layer is the compiler's conversion of the drawn rung into executable Boolean operations.

Split the rejected logic into two rungs

Preserve the shared compare and duplicate it where the two paths separate. The repair should produce one independently solvable Boolean expression per rung.

1. Record the complete condition that should energize MC41, including the shared compare and every contact unique to that path.
2. Record the complete condition that should execute the TMR/MOVE path.
3. Create the first rung with the shared compare, the MC41-specific conditions, and OUT MC41.
4. Create the second rung with the same shared compare, the lower-path conditions, and the original TMR/MOVE instructions.
5. Accept each rung separately. Compile before adding more logic.
6. Add a comment stating that the repeated compare is intentional because the two outputs require separate compiler-solvable paths.

Rung 1: [shared compare] [MC41 path conditions] --- OUT MC41
Rung 2: [shared compare] [timer/move conditions] - TMR / MOVE

Copy/paste supports whole accepted rungs and individual instructions. If the rejected rung cannot be accepted, rebuild from an existing valid rung or copy its instructions one at a time. Compile after each structural edit so the change that recreates the join error is immediately visible.

Preserve scan behavior while separating outputs

Two rungs are equivalent only when they evaluate the same Boolean conditions and preserve the required execution order. Check these points before downloading:

• Duplicate every common permissive and compare condition. Omitting one makes that rung less restrictive than the rejected design.
• Keep path-specific contacts on their original path. Moving one into the shared portion can inhibit both operations.
• Place the rungs in the intended scan order. If the TMR or MOVE reads a value written by OUT MC41 or related logic during the same scan, rung order can change the result.
• Check whether another rung also writes MC41 or the destination used by MOVE. Multiple writers can mask a correct structural repair.
• Confirm what happens when the shared compare changes state. Both rungs should drop out or become true according to the original Boolean intent.

Treat the repeated compare as a deliberate expression of the original common condition. Do not replace it with a new internal bit during a breakdown unless that bit's update order, retention, and ownership are defined; an intermediate bit adds another state and another possible multiple-writer fault.

Verify the repair before returning control

1. Accept both rungs and run a full compile. The diagnostic list must contain no Trying to AND above a JOIN entry for Lane_1_Fill_Seq#16:01:01.
2. Review the two rungs side by side. Mark the shared compare, then account for every original branch condition and instruction exactly once on its intended path.
3. Test the false state of the shared compare. Verify that MC41 remains off and the TMR/MOVE path does not execute.
4. Test the MC41-only condition and watch MC41 plus the timer and move status.
5. Test the timer/move condition and verify the timer state and move destination, while confirming that MC41 follows its own expression.
6. Test the state where both paths are true. Watch the result through consecutive scans for ordering effects.
7. Record scan time before and after the change if the controller's diagnostics make it available. Use the measured change, not rung appearance, to judge performance.

Stop the functional test if an output energizes outside its intended permissives, a timer resets unexpectedly, or a move destination changes from another rung. Correct the Boolean mapping or multiple-writer condition before returning automatic control.

Judge efficiency after correctness

The two-rung repair evaluates the shared compare twice, so it can execute more Boolean work than an ideal single compiled expression. No exact scan-time difference can be calculated without the controller's instruction timings, the operands used by the compare, and a measured program scan. The extra work is normally evaluated against the complete task scan, not in isolation.

The original rung has no practical speed result in Do-more Designer 2.5.1 because it does not compile. Compare only executable alternatives. If scan loading is high, capture minimum, current, and maximum scan diagnostics under representative machine conditions, then decide whether further restructuring is justified.

Keep the two-rung form when it makes output ownership and troubleshooting clear. Compact ladder is not automatically faster, and visual complexity does not reliably predict the generated instruction count.

FAQ