#09 | Il Parametro Muto: funziona nell'Editor ma smette di funzionare nel Progetto
Umberto RinaldiShare
La catena di errori dietro un parametro che non risponde più
Sei in Revit, hai caricato la nested family dentro la host, gli assi sono impostati, la specchiatura regge. Apri il Type Properties della host e vedi il parametro — larghezza cassetto, profondità, altezza. Lo modifichi. La famiglia si aggiorna. Tutto risponde.
Carichi nel progetto. Selezioni la famiglia, apri le proprietà, modifichi lo stesso parametro — e non succede niente. La geometria resta ferma. Il cassetto non si muove. Il parametro è lì, visibile, modificabile, ma muto. Non c'è un messaggio di errore. Non c'è un avviso. Revit non ti dice che qualcosa è rotto — perché dal suo punto di vista non lo è. Il parametro esiste, l'associazione esiste, la famiglia è caricata correttamente.
Il problema è più a monte. Ed è quasi sempre una combinazione di cause, non una sola.
La catena degli errori
Quando un parametro dimensionale funziona nel Family Editor ma si blocca nel progetto, la tentazione è cercare un unico colpevole. Nella pratica, raramente è così. È quasi sempre una catena — e basta un anello rotto per bloccare tutto.
Tipo vs Istanza: stai guardando nel posto sbagliato
Prima di sospettare qualsiasi cosa più complessa, controlla la cosa più ovvia: dove stai modificando il parametro.
Sei nel progetto, se il parametro della famiglia è impostato come Tipo, ogni modifica va fatta dal Type Properties — e si riflette su tutte le istanze di quel tipo, non su quella singola che hai selezionato. Non puoi cercarlo nelle proprietà d'Istanza aspettandoti un cambiamento immediato sull'elemento selezionato — perché stai bussando alla porta sbagliata.

Vale anche il contrario: non cercare il parametro di Istanza nel Type Properties — perché per definizione appartiene al singolo elemento, non al tipo.
Promemoria per chi nidifica: se la nidificata ha parametri di Istanza, e la inserisci più volte nella stessa host — pensa a una cassettiera con due cassetti identici, stessa nidificata inserita due volte — l'associazione con la host va fatta per ogni singola istanza. Non basta associarla una volta e aspettarsi che valga per entrambe le copie: sono due istanze distinte, ognuna con la propria associazione da impostare.

È la causa più banale della lista, ed è anche la più comune — proprio perché nessuno la sospetta per prima. Prima di aprire l'Editor e mettersi a caccia di associazioni rotte, vale la pena chiedersi: sto guardando il pannello giusto?
L'associazione è impostata nel verso sbagliato
Supponiamo che il pannello sia quello giusto. Il problema può essere nel collegamento tra host e nidificata.
Quando posizioni la nidificata dentro la host e apri il suo Type Properties dall'interno dell'Editor, trovi i parametri della nidificata elencati. Selezioni quello da associare — ad esempio la profondità del cassetto — e Revit ti propone in automatico solo i parametri della host compatibili per unità dimensionale: se è un parametro di Lunghezza, vedrai solo parametri di Lunghezza in lista. Non puoi sbagliare tipo di dato, perché Revit non te lo permette.

Quello che puoi sbagliare è associare il parametro sbagliato tra quelli proposti: se la host ha più parametri di Lunghezza (profondità cassetto, altezza cassetto, spessore pannello, ...), è facile selezionare quello con un nome simile ma che controlla un'altra dimensione. Revit non protesta — l'associazione è formalmente valida, ma non è quella che volevi. Il segnale parte dalla host e arriva a destinazione, solo non dove pensavi.
L'errore è nella modellazione, non nel parametro
Questo è il caso più difficile da diagnosticare — perché il parametro funziona. Il problema è che la geometria non è costruita per riceverlo.
Nel caso del comodino: se il cassetto non è correttamente appoggiato sulla Reference Line che gestisce la traslazione, il parametro dimensionale arriva ma non trova niente su cui agire. La Reference Line si muove, il parametro cambia valore, ma il cassetto resta fermo — perché il vincolo tra il corpo del cassetto e la linea di riferimento non è stato costruito correttamente in fase di modellazione.

È un errore a monte, invisibile dall'esterno. Si scopre solo quando si testa il comportamento nel progetto e ci si accorge che la geometria non segue il parametro.
Il parametro non è condiviso — e in questo caso specifico non è un problema
C'è un'ultima causa possibile, che riguarda solo chi lavora con parametri destinati a essere schedulati o controllati da un abaco di progetto: il parametro non è uno Shared Parameter.
Un parametro normale — quello che crei direttamente nel Family Editor — esiste solo all'interno della famiglia. La host lo vede, lo controlla, lo passa alla nidificata. Ma se hai bisogno di leggerlo o modificarlo da un abaco, o di condividerlo tra famiglie diverse, un parametro non condiviso non basta.
Se non è il tuo caso — se il problema è "modifico e non succede niente" all'interno del normale flusso Editor-Progetto — molto probabilmente la causa è altrove, nei punti precedenti. Lo Shared Parameter è un argomento che merita spazio suo: lo riprenderemo in un episodio dedicato.
La soluzione: verificare il circuito
Verificare l'associazione
Dopo aver controllato pannello e collegamento, la verifica da fare nel Family Editor è semplice: modifica il valore del parametro nella host e controlla che la nidificata risponda. Se risponde nell'editor, il collegamento è corretto.
Ma non fermarti qui — carica la famiglia in un progetto di test e ripeti la stessa verifica dal pannello proprietà del progetto. È l'unico modo per essere sicuro che il parametro sia visibile e controllabile dall'esterno.
Verificare la modellazione della nidificata
Se il parametro funziona nell'editor ma non nel progetto, e hai già verificato che il collegamento è corretto, il passo successivo è riaprire la nidificata e controllare i vincoli.
Nel caso del cassetto: verifica che la nidificata sia allineata al piano verticale della Reference Line che ne gestisce la traslazione, e non semplicemente posizionata nelle vicinanze. Se manca l'allineamento al piano corretto, la Reference Line si muove ma la geometria della nidificata non la segue — perché non è mai stata legata a quel riferimento in primo luogo.

📐 Il consiglio Inside the Files
Prima di caricare nel progetto, testa il parametro in tre passaggi:
01 — Controlla il pannello. Stai modificando dal Type Properties o dalle proprietà d'Istanza? È il posto giusto per quel parametro?
02 — Modifica il valore nel Family Editor. La nidificata risponde? Se no, il problema è nell'associazione o nel tipo di parametro.
03 — Carica in un progetto di test e modifica il valore. La geometria si aggiorna? Se no, il problema è nella modellazione della nidificata.
Tre domande, tre livelli. L'errore si trova sempre in uno di questi.
Il parametro muto è uno degli errori più frustranti in Revit — non perché sia difficile da correggere, ma perché è difficile da vedere. Tutto sembra funzionare, il file non dà errori, e il problema emerge solo quando sei già nel progetto, spesso con del lavoro fatto sopra.
La buona notizia è che la catena è sempre la stessa: pannello sbagliato, associazione sbagliata, tipo non corrispondente, modellazione a monte. Conoscere la catena significa sapere dove cercare — e trovare il problema in pochi minuti invece che in qualche ora.
Con ITF#07 e ITF#08 hai gli strumenti per costruire una nidificata che regge: assi corretti, specchiatura gestita, parametri che arrivano a destinazione. Il blocco costruttivo è chiuso.
Nel prossimo appuntamento di Inside the Files analizzeremo insieme l'anatomia di un mobile parametrico — come Reference Lines, Nested Families e formule di adattamento lavorano in sincronia.