Rebar Schedule Shows Wrong Bar Marks After Revision
A cast-in-place parking structure has 240 columns scheduled on a single sheet. The schedule is a multi-category schedule filtered to structural columns and sorted by a shared parameter called Bar Mark. After revision 3, the contractor notices that columns C-101 and C-102 now share the same bar mark even though their reinforcement differs: C-101 has 8-#8 verticals and C-102 has 12-#10. The shared parameter was populated by a spreadsheet import. The schedule shows a count of 2 for that bar mark. The detailer needs to issue a corrected schedule today, and the model cannot be re-imported from the spreadsheet until tomorrow.
1. Explain the most likely cause of the duplicate bar mark and give an interim fix that preserves schedule integrity.
Read the worked answer
The duplicate almost certainly came from the spreadsheet import: the shared parameter is a text or integer field, and two rows were mapped to the same value, or the import used a lookup that collapsed similar reinforcement types. A schedule sorted by a shared parameter will happily group distinct elements under one mark, and the count of 2 is the schedule faithfully reporting bad source data, not a Revit error.
Interim fix that preserves integrity:
- Do not overwrite the schedule with a manual text edit; that breaks the link between schedule and model.
- In the model, open the element properties for C-102 and correct the Bar Mark shared parameter value directly, using a unique mark that follows the project numbering convention.
- Verify the schedule re-sorts and the count drops to 1 for each mark.
- Tag the corrected elements so the annotation matches the schedule.
- When the spreadsheet is available, reconcile the import mapping so the same collision cannot recur, and add a validation step that checks for duplicate marks before issuing.
The judgment point is that schedules are reports of model data; fix the data, not the report.
2. What process change would prevent recurrence, and what is the tradeoff of adding a duplicate-mark check?
Read the worked answer
Prevent recurrence by making the shared parameter the single source of truth and validating it at the point of entry. Concretely: define a numbering convention, import into a staging file or a key schedule first, run a duplicate-value check, then push to the model. Keep the spreadsheet mapping documented so a re-import does not silently collapse rows.
The tradeoff of an automated duplicate check is added friction in the detailing workflow: every import or manual edit must pass the check before the schedule can be issued, which slows down fast turnarounds like this one. A lighter option is a schedule filtered to 'count > 1' that the detailer reviews before each issue, which catches collisions without blocking edits.
The exam-relevant reasoning is that data validation belongs upstream of documentation. Adding checks after the schedule is issued only catches errors that have already reached the contractor.