Reading Dependencies on the EDGEBIC Design Canvas

On the EDGEBIC design canvas, dependencies are the arrows. Every connector between two nodes says the same thing: the step the arrow points at cannot start until the step the arrow leaves has finished. Read the arrows and you have read the routing's logic, because those arrows are the exact next-in-sequence links the scheduler follows to order the work. EDGEBIC by User Solutions draws the routing as a flow chart precisely so this logic is something you see rather than something you reconstruct from a grid.

This post is a reading guide: how to trace a chain, spot a branch and a merge, and recognize the three shapes of a broken dependency before they reach the schedule. For the wider tour of the designer, see the visual scheduling guide.

The Arrow Is the Dependency

Each step in a routing is a node on the canvas. Each next-in-sequence link is a connector, an arrow drawn from the upstream node to the downstream one. That arrow is not a stylistic choice. It holds the same value the data grid stores in its next-in-sequence column, and the scheduling engine follows it to decide execution order.

This matters because a routing also carries a display sequence number on each step, and it is tempting to assume that number controls the order. It does not. The sequence number is a display-order hint. The connectors drive the real order. Two steps can share the same low number and still run one strictly after the other, because the arrow between them, not the digits on the row, is what the engine reads. When you want to know what actually runs when, the canvas is the reliable surface.

Tracing a Linear Chain

Start with the simplest routing: a straight run. Saw feeds drill, drill feeds deburr, deburr feeds the finished bracket. Four nodes, three arrows, one path.

To read it, put your eye on the first node and follow the arrows to the terminal end-product node. Every routing must arrive there. The end-product node is the one node with arrows coming in and none going out, and it is created with the routing itself. If your finger runs off a node with nowhere to go before you reach the finished product, that node is a dead-end, and the routing is broken.

EDGEBIC quietly assigns each step a depth from this chain, a level counting how far the step sits from the finished product. The step just before the end product is level 0; each step further upstream is one higher. You rarely need the number, because a left-to-right layout turns depth into position. But it is worth knowing the engine computes it from the arrows, not from the sequence column, which is one more reason the connectors are the source of truth.

Reading Branches and Merges

Real routings are not always straight. Two shapes show up constantly, and both are obvious once you know what to look for.

A branch is one node with two or more arrows leaving it. The step splits into parallel downstream paths. A merge is one node with two or more arrows arriving. Several upstream paths converge on one step.

The most common merge is a sub-assembly joining the main flow. A frame is welded and painted on its own short chain, then its final node connects into the assembly step of the main product. On the canvas that assembly step is a merge: an arrow from the machined body arrives, and an arrow from the finished frame arrives. Read the arrows into any node and you have the complete list of what must be ready before that step can start. EDGEBIC uses exactly that list to time the branches, so the frame finishes just as assembly needs it. Sub-assembly nodes also wear a star marker because the component has a routing of its own, which is your cue that the branch behind it explodes into more steps at schedule time. That behavior is covered in how the designer shows sub-assembly branches.

The Three Shapes of a Broken Dependency

A dependency you meant to draw is only half the story. The canvas is also where you catch the ones that broke. EDGEBIC recognizes three failure shapes and marks the affected node with a warning icon:

1. No link set. The step has no next-in-sequence value. Nothing follows it, so on the canvas no arrow leaves the node. If the step is not the finished product, it is a dead-end.
2. Dangling link. The step points at another step that has since been deleted. The arrow references a node that is no longer there. The engine cannot resolve it.
3. Cycle. A chain loops: A feeds B and B feeds A. The routing has no clear upstream and downstream, so both steps get pinned to the same depth and flagged. The schedule can still run, but the order is ambiguous, which is precisely the confusion the warning is telling you to fix.

The value of the icon is that these are the failures a spreadsheet routing hides. A dangling next-in-sequence value looks fine as a cell. On the canvas it is a node whose arrow points into empty space, and the warning removes any doubt.

A Worked Example: Finding the Early Step

Widget-A's routing is meant to run body machining, then a merge with a welded frame, then assembly, then paint. A planner reports that paint scheduled on day one, before assembly even started.

Open the routing in the designer and trace the arrows into the paint node. There is only one, and it arrives from assembly, which is correct. So the fault is upstream. Follow arrows backward: assembly should be fed by both body machining and the frame. On the canvas, only the body machining arrow arrives. The frame node sits to the side carrying a warning icon, and its next-in-sequence value is empty, so no arrow leaves it. The frame connects to nothing.

Because assembly's only satisfied predecessor is body machining, the engine can start assembly as soon as machining is done, and paint follows. The frame, disconnected, schedules on its own at the job's start time, which is why paint appeared to be racing ahead of its inputs. Turn on the connector tool, draw one arrow from the frame node into assembly, and the merge is restored. Save, and the warning clears. On the next reschedule, assembly waits for both inputs and paint falls back to its proper slot.

This is the everyday payoff of reading dependencies on the canvas: a scheduling symptom (a step too early) becomes a visible cause (an arrow that was never drawn). The same instinct applies once the work is scheduled, where an upstream edit lights up downstream operations that may now be out of sequence.

Reading Dependencies Is the Habit

Manufacturers have reasoned about routings as flows for as long as there have been routings, and User Solutions has been putting that flow on a screen since 1991. The discipline is small and pays every day: before you trust a routing, follow its arrows from first step to finished product and confirm every merge has its inputs and every node has a way out. Check the type of each arrow while you are there, because parallel and alternate branches on the canvas schedule nothing like a plain next-in-sequence link. A dependency violation that would have surfaced as a strange schedule three days from now surfaces instead as an arrow that is missing today.

Bring a routing you are unsure about to a demo, and read it together. Give US the messy one.