Anyone here set up rule-driven checks in ShipConstructor 2023 to flag SOLAS/IMO clearances (e.g., 900 mm escape route width, A‑60 boundary offsets) at the part level instead of catching it later in Navisworks? I’d like to constrain ladders, doors, and handrails so revisions can’t violate the yard standard and trigger a preflight before we release NC for 8 mm AH36 plates.
We’ve had luck adding UDAs like clear_width and a60_offset to the ladder/door catalogs, then a Project Insights query that marks Release_OK only if clear_width ≥ 900 mm and the A‑60 offsets pass; the NC export reads that flag and blocks plates when it’s false. It’s not a hard constraint in the model — more of a speed bump than a brick wall — but it catches violations before 8 mm AH36 goes out. Do you have Project Insights/EnterprisePlatform in your stack, or want the sample SQL we used?
I’ve done it in SC 2023 by tying ladder/door block params to catalog props and a SQL view that flips a “ReleaseReady” flag to false whenever “900 mm” or A‑60 rules are violated, so Approval Manager blocks NC on the 8 mm AH36 plates until it passes. Small caveat: some legacy blocks didn’t expose the params cleanly, so we rebuilt those once. Do you already gate NC off the Approval status?
But set parameter floors in Catalog Editor for ladder width, door clear opening, and A‑60 offsets, and bind them to a project variable (e.g., SOLAS_Escape_Min) so SC 2023 won’t accept edits below the yard standard; pair that with an Approval state on the part that the NC export filter requires, and your “preflight before we release NC” just happens. Only caveat: handrails modeled as plain solids ignore the limits unless you convert them to a custom catalog part with exposed params.
Quick win: we enforced the escape minimum by adding an INSTEAD OF UPDATE trigger on the ladder/door catalogs that cancels saves and writes a short note to the part’s revision comment whenever clear_opening drops below 0.9 m; it keeps noncompliant sizes from ever persisting and your ReleaseReady flag stays false by default until it’s fixed (T‑SQL pattern: CREATE TRIGGER (Transact-SQL) - SQL Server | Microsoft Learn). @Leena_S did you try a DB constraint first or go straight to a trigger? Minor caveat: triggers can get wiped by major updates, so keep a deploy script in source control.
Instead of a trigger, @rajKumar85, add a CHECK constraint on the catalog columns via a scalar UDF (e.g., dbo.fn_SolasMin(‘EscapeWidth’)) so any out‑of‑spec access fixture can’t be saved — like a bouncer at the door. Pair it with a tiny preflight that queries a view of offenders and flips them to a red layer before NC; do you already have a Config table holding the rule values?
We’ve had good luck modeling egress corridors and A‑60 offsets as locked “no‑go” volumes (Generic Model) driven by a project variable, then running Clash Manager as a “preflight” before NC publish; if anything intersects, we flip the parts to Hold and the job won’t run. It’s bowling with lane bumpers, but you still aim. Do you already have those control solids seeded per zone, or do you want a small script to auto-drop them from the catalog?