Setup Time Looks Wrong on a Job: Reading the Changeover Trail

A setup time that looks wrong is almost always the engine correctly reporting which resolver level it landed on, and the setup source recorded on the operation tells you which one in a single glance. Before assuming the number is a bug, read the source: it separates "the matrix fired" from "the matrix was bypassed and the flat default was used," and those point at completely different fixes.

EDGEBIC by User Solutions resolves changeover time through an ordered chain and records where it landed on every scheduled operation. This post sits in the EDGEBIC troubleshooting guide and is the diagnostic companion to building a setup matrix, which covers the configuration; here the concern is why a configured matrix does not seem to apply.

First, Read the Setup Source

Add the setup source column to the Job View. Every scheduled operation carries a short code and a human-readable reason sentence explaining where the setup time came from. The codes:

The Job View even brightens the matrix sources and mutes the fallbacks, so a screen full of muted sources tells you at a glance the matrix is not being consulted. That is the whole diagnosis: a matrix source means sequence-dependent logic fired; a default source means it did not. Sequence-dependent changeover, defined explains why the two differ.

The Resolver Chain, in Order

The engine walks these checks and stops at the first hit:

1. Cold start. No previous product on the machine: use the routing or work-center default. This is preparation, not changeover, so it is not zero.
2. Same product. Previous product equals current: return zero. This fires before the matrix is even consulted.
3. Product-level cell for the exact from-product to to-product pair on this machine.
4. Family-level cell for the from-family to to-family pair, which requires both products to have families assigned.
5. No cell found: fall back to the routing or work-center default.

Every returned value is in hours. The matrix itself is entered in minutes, the planner's natural unit, and converted on the way out. Confusing the two is a sixty-fold error, so if a changeover reads sixty times too long, a minutes value reached an hours field somewhere upstream of the matrix.

Cause 1: The Matrix Was Bypassed (Fallback Source)

The most common "wrong setup" is a job showing a default source when you expected a matrix hit. Three sub-causes:

• No previous product to compare against. A cold start uses the flat default by definition. The first job on a machine each run has no predecessor.
• The cell does not exist. No product-level and no family-level cell matched that exact transition. The resolver falls through silently; there is no error.
• One product has no family. The family lookup needs both the previous and the current product assigned to families. If only one is, the family level is skipped and the flat default wins. This is the single most common reason a family matrix works for some transitions and not others.

Fix: for a missing cell, add the product-level or family-level entry for that transition. For the family gap, assign both products to families. The self-explaining reports and the reason sentence spell out which pair was looked up, so you know exactly which cell to add.

Cause 2: The Matrix Never Loaded

If every operation across every machine shows a default or cold-start source even though a matrix is configured, the matrix data may not have reached the engine at all, or it may be genuinely empty. The resolver treats an empty matrix as "always fall through."

How to tell: no operation anywhere shows a matrix source. This is broader than one bad transition.

Fix: confirm the matrix has rows for the machine in question, then re-run scheduling. The session log records the resolver's decision per operation, including the resolved source, which confirms whether the matrix was consulted. If the matrix is populated and still never fires, the exported detail belongs on a support ticket.

Cause 3: A Bad Cell Is Being Applied

The opposite complaint: a changeover charged too much or too little because the matrix cell itself is wrong. The anomaly report has a family of checks specifically for matrix integrity: negative minutes (which the engine clamps to zero, so the config is silently wrong), duplicate cells for the same transition (whose resolution is non-deterministic), self-pair cells that can never apply, and cells pointing at deleted machines, products, or families.

How to tell: run the anomaly report on a full scan (matrix checks are plant-wide, so do not scope to one job) and read the matrix-integrity rows.

Fix: the matrix checks name the exact cell. A duplicate cell means two rows exist where one should; delete the stale one. A self-pair cell is dead data; remove it. A negative value came from a direct data edit that bypassed the editor's guard; correct it. Running and reading the anomaly report covers scoping and export.

A Note on Mirrored and Started Operations

Two setup sources are deliberate and not to be second-guessed. A dependent-parallel mirror inherits its parent's changeover and is marked as mirrored-from-parent; it does not re-run the resolver, because it is the same physical event. And on a reschedule, an operation with recorded actuals keeps the setup it already had, because actuals are never recomputed. If a "wrong" setup appears only on mirrors or only on started operations, this is why, and it is the same immutability principle behind actual dates that look wrong.

Prevention

• Assign every product a family before relying on a family matrix. The family level is only as complete as the assignments behind it.
• Verify with the setup source after building a matrix. Schedule once, add the source column, and confirm real transitions show matrix sources. A screen of muted fallbacks is the signal that assignments or cells are missing.
• Audit the matrix after any bulk import. The matrix-integrity checks catch the negatives, duplicates, and stale references a spreadsheet import can introduce, before they charge a wrong changeover on the floor.
• Do not enter same-product cells. They never apply and only clutter the matrix.