shelidonNovember 20, 2020Leave a Comment

Mi sono recentemente trovata a gestire un’intera giornata di formazione su Dynamo per un cliente nel settore infrastrutturale e ho avuto il lusso di poterla dedicare quasi tutta allo scambio strutturato di dati. Non una delle lezioni più leggere che io abbia tenuto, ma certamente una delle più utili. A loro beneficio quindi, ma a beneficio di tutti, pubblico qui una collezione di “cose che si possono fare con le Schedule (e Dynamo)”. Sarà pubblicato in diverse puntate, per tenervi caldi in queste notti d’inverno.

Package essenziali:

• Bumblebee e Mandrill di Konrad Sobon;
• Rhythm di John Pierson;
• Bimorph di Thomas Mahon, anche se la sua forza risiede nella gestione dei DWG.

E, naturalmente, dato che stiamo usando package personalizzati, diventa fondamentale installare l’estensione Monocle, sempre di John Pierson, che (tra le altre cose) ci consente di tenere sotto controllo i package e di annotare con rapidità l’utilizzo di nodi personalizzati all’interno dello script. Uso la “versione noiosa”, perché l’altra… ugh, Comic Sans.

Nota: la versione che sto usando negli screenshot è ancora una versione precedente di Dynamo, per motivi che definirei “personali”. Non vi preoccupate. Non dovrebbero esserci problemi significativi nell’applicare gli stessi principi alle ultime versioni.

Negli screenshot sto usando la seguente codifica colori, con l’aiuto di Monocle.

Cose che si possono fare con le Schedule (e Dynamo)

1. Creare un filtro

Spesso in Dynamo ci troviamo a utilizzare gli stessi parametri per diversi scopi: analizzare gli elementi, raggrupparli, compilare ulteriori parametri. Una volta svolte queste operazioni, spesso abbiamo necessità di comunicarle. E quale modo migliore di comunicarle, all’interno di Revit, se non con filtri grafici e Schedule.

1.1. Scegliere la Schedule

Se non volete installare package, potete farlo scegliendo la vista nell’elenco di viste disponibili all’interno del modello, ma ricordatevi di verificare la tipologia della vista e che si tratti effettivamente di una schedule.
Per eliminare il passaggio e ridurre il margine di errore, consiglio di usare il nodo di Rhythm che vi farà la grazia di elencare solo le viste di Schedule nel documento.

1.2. Interrogare i campi a disposizione e i loro valori

I filtri possono essere creati solo per parametri caricati all’interno della schedule. Bisogna quindi interrogare da una parte quali campi abbiamo a disposizione e dall’altra quali sono i valori per i quali potrebbe essere ragionevole filtrare.

Attenzione a non confondere i nodi ScheduleView.Fields e ScheduleView.SchedulableFields, perché il primo vi fornisce i campi caricati nella schedule, mentre il secondo vi restituisce tutti i parametri che sarebbe possibile includere, compresi quelli già inclusi.

Dall’altra parte, il filtro andrà fatto sui valori. Esistono due modi per interrogare i valori degli elementi nella categoria della schedule: interrogare gli elementi nella vista oppure ripescare tutti gli elementi della categoria in schedule.

Il primo metodo, richiede una ripetizione manuale di cui non sono una fan, ma è decisamente più veloce, specie se avete numerosi elementi all’interno della schedule.
Per un metodo più raffinato, dobbiamo solo ricordarci che la schedule è una vista come tutte le altre e, a patto di avere la schedule come vista attiva, possiamo utilizzare il nodo All Elements in Active View per estrarre gli elementi presenti nella schedule.

Anche questo metodo non è perfetto, perché potremmo non avere la schedule come vista attiva. All’interno di Rhythm esisterebbe un nodo che apparentemente ci potrebbe aiutare a rendere il tutto a prova di errore, ovvero All Elements of Category in View. Abbiamo la vista, perché l’abbiamo selezionata al punto 1, ma ci rimarrebbe comunque da selezionare manualmente la categoria. Al massimo possiamo utilizzarlo per un ulteriore controllo.

L’ideale sarebbe avere una via di mezzo tra i due, ovvero la possibilità di avere gli elementi di una vista selezionata da un menu. Sono certa che il nodo esista, o quantomeno potrebbe esistere. Semplicemente non è tra i miei package e non si trova nella documentazione on-line.

Per isolare i loro valori, invece, potremmo essere tentati di utilizzare il solito nodo Element.GetParameterValueByName, ma ricordate che il nodo legge parametri di tipo laddove gli venga dato un tipo in input e parametri di istanza laddove gli venga data un’istanza come input. Dovremmo quindi estrarre tipo dall’istanza e darli entrambi come input, per poi trovarci con liste da ripulire dei nulli. Esiste un nodo migliore, nel package Rhythm, che consente di pescare il valore di un parametro sia che si tratti di un parametro di istanza o di un parametro di tipo.

ʳʰʸᵗʰᵐ|Elements.GetParameterValueByNameTypeOrInstance

In questo momento sto facendo un test sul primo elemento della lista, ma chiaramente quel nodo List.FirstItem se ne dovrà andare.

Il lacing dell’ultimo nodo dev’essere settato a “longest”, perché altrimenti pescherete solo il primo campo (nel mio caso, Family and Type). Se non ricordate esattamente come funzioni il lacing, vi consiglio questo eccellente articolo.

Per analizzare i valori e, quindi, utilizzarli nella nostra Schedule, i nodi Unique.Items, Round e GroupByKey sono fondamentali. Vediamo ad esempio la mia situazione.

Vediamo ad esempio che nel mio caso ho tre tipi, due dei quali hanno il Type Mark compilato, e una lista piuttosto lunga di lunghezze. Arrotondando la lista di lunghezze e pescando gli elementi unici, mi ritrovo con le key che mi servono anche per quanto riguarda le lunghezze. E se li voglio in ordine, ad esempio per individuare dei range, il nodo List.Sort risulta utile.

Ipotizziamo di voler usare il Type Mark, per il momento: la situazione è decisamente più semplice. Sì, ci sono dei modi per collegare il parametro al suo indice, per situazioni particolarmente complesse, ma per il momento non mi sembra il caso.

Quel nodo List.UniqueItems è solo per consultazione, ma non userò il suo risultato come input per List.GroupByKey. La lista di key deve sempre essere di lunghezza uguale alla lista degli Element.

1.3. Usare i campi per creare un filtro

Una volta interrogati i parametri presenti nella schedule e isolati i loro valori significativi, la creazione effettiva del filtro è semplice e procede in modo analogo alla creazione del filtro manualmente nella schedule.

Potrei ad esempio decidere di includere nella schedule solo gli elementi il cui Type Mark è stato compilato e quindi escludere tutti gli elementi che nel mio raggruppamento si trovano nella sottolista 1.

La creazione del filtro avviene con un nodo relativamente semplice, ScheduleView.AddFilter, che richiede la vista (ce l’abbiamo dall’inizio) e il nuovo filtro (che non abbiamo).

Il funzionamento del nodo di creazione ScheduleFilter.ByFieldTypeAndValue è abbastanza intuitivo, perché segue gli stessi passaggi per la creazione manuale del filtro: richiede il campo, il tipo di filtro, e il valore contro cui testare il valore del campo.

L’unico elemento apparentemente misterioso rimane l’input filterType, anche se dovrebbe essere chiaro quali siano le nostre opzioni. Attenzione perché il nodo che stiamo cercando è Schedule Filter Types, e non Select Rule Type, che invece lavora sui filtri grafici.

Attenzione perché anche usando le tipologie di filtro “HasNoValue” e “HasValue” è comunque necessario dare un input alla porta “Value”, che non ha un default. Si tratta quindi di condizioni difficili da utilizzare.

I risultato finale è qualcosa del genere:

Dato che, al contrario degli altri filtri, i filtri delle Schedule non sono salvati centralmente insieme agli altri filtri di selezione, il controllo tramite script ci consente di centralizzare il controllo dei valori rilevanti, utilizzando ad esempio porzioni dello stesso script per una creazione parallela di filtri grafici che usino gli stessi valori.

La cosa può essere fatta in modo relativamente facile. Bisogna solo replicare ciò che abbiamo fatto per il filtro nella schedule con i corrispondenti nodi per i filtri grafici.

In particolare:

ScheduleView.AddFilters corrisponde a View.AddFilter [entrambi agiscono sulla vista]
ScheduleFilter.ByFieldTypeAndValue corrisponde a ParameterFilterElement.ByRules [l’output in entrambi i casi è il filtro]

2. Creare una Schedule

Sempre per gli stessi motivi, potremmo trovarci nella necessità di creare nuove schedule sulla base dei parametri che abbiamo utilizzato per analizzare il modello fino a questo momento. Il nodo che ci consente di farlo è ScheduleView.CreateSchedule, che richiede come informazioni minime:

• la categoria;
• il nome della schedule;
• la tipologia della Schedule, a sua volta da selezionare tra i tre tipi di schedule che è possibile creare in Revit con il nodo Schedule Type: un Material Takeoff, una Key Schedule o una Schedule “normale”, chiamata RegularSchedule.

Per il momento, ciò che stiamo creando è un rarissimo esempio di schedule vuota, senza alcun parametro caricato. Qualcosa che difficilmente è possibile osservare in natura.

A questo punto è necessario aggiungere i campi e la cosa può essere fatta senza troppo sforzo con il nodo ScheduleView.AddFields. Ecco che quindi ci torna utile anche quel misterioso ScheduleView.SchedulableFields, che ci forniva tutti i parametri che è possibile aggiungere alla schedule.

3. Esportare la Schedule

Esportare dati è relativamente semplice laddove si abbia, all’interno di Dynamo, un workflow già completo per la raccolta dei dati. Ma la maggior parte delle raccolte dati da parte degli utenti avviene, spesso, tramite Schedule. Sono comode. Sembrano Excel.

Ricreare la struttura dati all’interno di Dynamo, estraendo i valori e combinando le liste, è medioevale. Il nodo ScheduleView.Export è estremamente comodo, se ci si prende un attimo per cercare di capire che cosa sono quelle exportOptions.

ExportOptions è un modo per Dynamo di impacchettare una serie di settaggi importanti per l’esportazione delle Schedule, che a sua volta ha bisogno di altre impostazioni. Questi settaggi riguardano:

• La modalità di esportazione delle intestazioni (Header) che a sua volta richiede di selezionare l’opzione dal nodo Export Column Header, che offre Multiple Rows, None e One Row;
• Il delimitatore di campo (fieldDelimiter) che richiede di indicare il delimitatore tra i campi e il cui valore di default è il tab: se si desidera esportare un CSV in senso stretto, ad esempio, il delimitatore dovrà essere “,”;
• Una booleana per indicare se si desidera esportare le intestazioni, i piè di tabella e le righe bianche (headersFootersBlanks) il cui valore di default è false;
• Il qualificatore di testo (textQualifier) che anche in questo caso può essere selezionato con l’apposito nodo Export Text Qualifier (si può scegliere tra Double Quote, che è anche valore di default, Quote e None);
• Una booleana per indicare se si desidera esportare il titolo (title) il cui valore di default è false.

Attenzione a “None”, perché apparentemente non si tratta di un input supportato.

Nel prossimo articolo…

Vedremo i vari modi per leggere da un file esterno (CSV, Excel con i nodi base ed Excel con Bumblebee) e ci interagiremo un po’ di più.