A Setup Family Change Did Not Take Effect

A setup family change fails to take effect for one of four documented reasons: the product points at a missing or inactive family, a matrix cell references a deleted entity, no cell matches the actual changeover so the engine used the routing default, or scheduling was never re-run. The setup-source column on each schedule row tells you which path the engine took, so you can diagnose this in seconds rather than guessing. EDGEBIC by User Solutions records the reason for every changeover charge.

This post belongs to the EDGEBIC troubleshooting guide. It covers the resolver's fallback chain, the anomaly checks that catch broken references, and the fix for each cause.

First, Read the Setup Source

Before changing anything, find out what the engine actually did. Each schedule row carries a setup source: a short code that names which level of the resolver supplied the setup time. Add the setup-source and setup-reason columns to the Job View grid, and the answer is on the row.

If you expected a family cell and the row reads as the routing default, the family lookup found nothing. That single observation splits the problem into its real causes.

The Resolution Chain

EDGEBIC resolves setup time through a fixed order, most specific first. A product-level matrix cell beats a family-level cell, a family cell beats the routing default, and the routing default beats the machine default. How EDGEBIC resolves setup time through the five-level chain walks the full order. The point for this symptom: the engine drops to the routing default whenever the more specific levels cannot answer, and it does so silently. That is the safe behavior, but it is also why a broken family reference produces no error, just an unexpected time.

The Four Causes and Their Fixes

1. Scheduling was not re-run. Setup times are stamped onto schedule rows at scheduling time. Editing a family assignment or a matrix cell changes master data only. Re-run scheduling for the affected jobs, then re-read the setup-source column. This is the most common cause and the cheapest to rule out, so check it first.

2. The product's family reference is missing or inactive. If a product points at a setup family that was deleted or deactivated, the family-level lookup finds nothing and the engine falls to the routing default. The anomaly report's product-assigned-to-missing-family check names the exact product and family. Fix: reassign the product to an active family, or clear the family field, then re-run scheduling.

3. A matrix cell references a deleted entity. A cell that points at a deleted work center, product, or family can never be reached, so its changeover silently falls through. The anomaly report's stale-cell check lists exactly which reference is broken. Fix: delete the stale cell or repoint it at the current active entity, then re-run scheduling.

4. No cell matches the actual changeover. If you added a Light-to-Dark cell but the previous job on the machine was in a third family, no cell matches and the routing default applies correctly. This is not a bug: it means the matrix has a gap for that specific transition. Fix: add the cell for the changeover you actually observed, using the previous job's real product or family.

Confirm the Fix

After any of these repairs:

1. Re-run scheduling for the affected jobs.
2. Re-read the setup-source column. It should now show a family or product matrix cell.
3. Read the setup-reason column to confirm the number matches the cell you configured.
4. For a configuration audit, run the full anomaly scan and confirm the setup-matrix checks are clean.

If the setup-source still reads as the routing default after all four causes are ruled out, the matrix data may not be loaded for that run at all. That is the deeper case behind the setup matrix is not being applied, a sibling worth reading. For the mirror symptom of a wrong-looking time, see setup time looks wrong on a job. The troubleshooting guide collects the full setup-matrix set.