3rotaie forum

Ovviamente le azioni che possiamo usare sono molte e ne abbiamo esplorato solo alcune. Vediamo qualche altro esempio.

Abbiamo visto che una singola azione può essere applicata ad oggetti diversi.
Ad esempio le luci della locomotiva che si accendono quando la locomotiva si muove e si spengono quando la locomotiva si ferma:
Azioni: Le due azioni sono state applicate alle locomotive. Qui vediamo le azioni assegnate alla Litra ed alla OBB:
Ecco cosa succede ogni volta che muoviamo o fermiamo la locomotiva (sia manualmente che in modalità automatica):


Le luci si accendono quando la locomotiva riceve un comando di movimento e si spegnono quando la locomotiva riceve il comando di velocità 0.

Ma vogliamo che le luci si spengano con un ritardo di, ad esempio, 4 secondi.
Mettiamo quindi un ritardo, tramite il campo timer nella nostra azione: Mettendo il valore 4000 nel campo 'Timer', l'azione verrà eseguita con 4 secondi di ritardo dal momento della chiamata (4000 x 100ms = 4 sec.):


Quando la locomotiva riceve il comando di velocità 0 (still) esegue l'azione, ma questa ha un timer di 4 secondi, quindi l'effetto che otteniamo e che le luci si spengono dopo 4 secondi. Questo succede ogni volta che l'azione è usata. Sarà sempre eseguita con 4 secondi di ritardo.

Ma possiamo 'personalizzare' la chiamata dell'azione. Ad esempio far spegnere le luci prima per una locomotiva e dopo per un'altra.
Riportiamo l'azione ad usare un timer pari a zero: Per dmiostrazione, metteremo un 'ritardo' di 2 secondi sulla Litra e di 4 secondi sulla OBB:
Quindi andiamo nelle azione assegnate alla Litra: Nella azione che spegne le luci quando la locomotiva e in still (velocità 0) mettiamo un ritardo di 2 secondi (2000 x 100ms): Sulla OBB mettiamo invece 4 secondi: O2a, l'azione è la medesima ma verrà eseguita con ritardi diversi, 4 ssecondi per la OBB e 2 per la Litra:


Potete verificare anche usando l'orologio di Rocrail che le luci ora si 'spengono' dopo 2 secondi dall'arresto della Litra e dopo 4 secondi nel caso della OBB.

Quindi la stessa azione ('luci_off') viene 'personalizzata'. Ovviamente quando parlo di personalizzazioni le opzioni sono relative. Qui usiamo solo il ritardo di esecuzione. Ma tramite le condizioni possiamo 'personalizzarla' maggiormente.

Però dobbiamo tenere in considerazione cosa succede quando la locomotiva è in modalitù automatica.
Vediamo cosa succede quando la locomotiva si ferma nel blocco che è impostato con una attesa di 4 secondi:

Succede che la locomotiva riparte con le luci che si spengono.
Perchè?
Analizziamo la situazione.
La locomotiva arriva nel blocco con le luci accese.
Quando si attiva il sensore 'in' la locomotiva riceve il comando di velocità 0. Viene eseguita quindi l'azione che spegne le luci (ma con un ritardo di 4 secondi).
Nello stesso preciso momento però parte anche il conteggio del tempo di attesa nel blocco. Che è impostato a 4 secondi. Ma nelle priorità di funzionamento Rocrail esegue prima le operazioni di 'movimento' e poi le azioni, speciamente quelle con un timer.
Quindi il 'conteggio' del movimento (tempo di attesa nel blocco) viene eseguito 'prima' del conteggio dell'azione'.
Se guardate viene impostato un nuovo itinerario e la loco inizia a muoversi prima che siano passati i 4 secondi del timer dell'azione.
Ora direte: ma la locomotiva ha una azione che accende le luci quando riceve un comando di movimento. Ed in effetti il comando viene dato e ricevuto solo 'prima' che siano passati i 4 secondi del ritardo dell'azione che spegne le luci.
Riepilogando in sintesi succede questo:
1) La locmotiva attiva il sensore 'in'. Parte il conteggio dei 4 secondi di tempo di attesa nel blocco.
2) La locomtiova riceve il comado di velocità 0. Parte l'azione 'luci_off' ma con un ritardo di 4 secondi (nel frattempo tra il punto precedente e questo sono passati alcuni ms...)
3) passati 4 secondi Rocrail attiva un itinerario e invia il comando di velocità alla loco per farla muovere. Si attiva l'azione 'luci_on' sulla locmotiva
4) passano i 4 secondi del ritardo dell'azione 'luci_off' e l'azione viene eseguita. Le luci vengono spente anche se la locomotiva si muove.

Ora, se l'attesa nel blocco è superiore ai 4 secondi (diciamo 10) avremo questo effetto. La loco arriva nel blocco, si ferma e dopo 4 secondi spegne le luci. Dopo altri 6 secondi viene attivato un itienrario, la loco si muove e riaccende le luci.

Però non è che una loco quando si ferma in stazione spegne le luci...

Noi volgiamo che, quando muoviamo la locomotiva manualmente, le luci si accendano subito e si spengano dopo 4 secondi quando la fermiamo (usiamo la loco OBB), mentre se la locomotiva è in modalità automatica le luci devono restare accese quando la locomotiva si ferma nei blocchi.

Vediamo come possiamo ottenere questo risultato.
N.B questo è un esempio basato sulle azioni in uso. Si può ottenere lo stesso effetto con altri sistemi (azioni).

Andiamo nelle azioni della OBB: Aggiungiamo una condizione alla azione che spegne le luci: Diciamo che l'azione di spegnere le luci deve essere eseguita solamente se la locomotiva in questione è in modalità stop.
Ricordo ancora una volta che c'è differenza tra lo stop inteso come velocità = 0 e lo stop della mosalità di funzionamento.
Rocrail non usa lo 'stop' per dare il comando di velocità 0 ma lo 'still'. Qundi lo 'stop' indica che la locomotiva non è mossa automaticamente da Rocrail.

Con la condizione data ora le luci restano accese durante le attese nei blocchi (10 secondi di attesa in questo caso):


Quando la locomotiva si ferma per l'attesa nel blocco la sua modalità e 'wait'. Non viene messa in stop. Non essendo in stop l'azione non viene eseguita.

Il rovescio della medaglia è che le luci resteranno accese anche se mettiamo in 'stop' la locomotiva manuamente (ad esempio con un doppio click nel blocco di destinazione) come nel prossimo video. Però il comando manuale della locomotiva continua a funzionare (intendo accensione e spegnimento delle luci):


Perchè succede questo? Perchè quando arrestiamo una locomotiva (anche togliendo la modalità automatica a tutto il sistema) il comando di 'stop' viene inviato alle locomotive quando attivano il sensore 'enter' del blocco. Ricordo che se la locomotiva è in movimento e togliamo l'automazione questa comunque raggiungerà il blocco di destinazione.

Ma pur avendo ricevuto il comando di stop (in pratica Rocrail 'avverte' la locomotiva che quando si ferma al sensore 'in' dovra andare in modalità 'stop' la locomotiva non è in stop ma ancora in 'auto' ovvero in modalità automatica. Quando la locomotiva attiva il sensore 'in' viene dato il comando di velocità = 0 (still) ma la locomotiva non è ancora in 'stop', quindi l'azione viene ignorata perchè la condizione che abbiamo messo prevede che sia in modalità 'stop'.

Quindi anche se la nostra 'logica' di funzionamento ci dice che l'azione dovrebbe spegnere le luci, la 'logica' di funzionamento di Rocrail può differire da quanto ci aspettiamo.
Possiamo però ovviare a qusti problemi usando soluzioni più elaborate come l'uso delle variabili che vedremo nel prossimo esempio ma applicata ad altra situazione. Tanto è il concetto di uso che importa.

Per concludere con l'azione delle luci...
Quando la locomotiva inverte la direzione:


Comportamente del tutto normale. Siamo in condizione di locomotiva in 'stop' ma comandata manualmente. Le luci sono accese (nella direzione opposta).
La locomotiva si ferma perchè riceve il comando arresta (still). Parte l'aazione per spegnere le luci con i soliti 4 secondi di ritardo. Invertiamo la direzione di marcia ed ecco che le luci (che sono ancora accese perchè sono passati meno di 4 secondi) si accendo nel senso di direzione di marcia, per poi spegnersi perchè l'azione viene eseguita (4 secondi dal still).

Analizziamo ora il comportamnto delle azioni.
Torniamo sui suoni (fischio della Litra) per correggere i problemi che ci possono essere.

Le azioni vengono eseguite ogni qualvolta che l'oggetto interessato le attiva.
Nel caso dei sensori le azioni che abbiamo assegnato vengono eseguite ad ogni attivazione del sensore.

Premessa: nei video seguenti ho volutamente inserito dei vagoni al traino delle locomotive che non potrebbero essere impiegati normalmente.
I blocchi di Rocrail devono contenere il treno più lungo e non possono essere usati con treni più lunghi.
Nel caso specifico la locomotiva Litra traina una serie di vagoni corti e 2 vagoni lunghi che 'fuoriescono' dai blocchi. Nel normale uso di Rocrail questo provocherebbe 'incidenti sicuri' in quanto i vagoni occupano non solo il blocco ma anche deviatoi fuori dal blocco......

Detto questo vediamo cosa succede (ovviamente attiva l'audio del video):
La nostra Litra fischia quando attiva il sensore 'fb6' e quando attiva il sensore 'fb4'. Se vedete i paragrafi precedenti sulle azioni troverete la configurazione usata.
Normalmente la locomotiva una sola volta, quando attiva il sensore, ma vediamo...


Il fischio viene ripetuto perchè i sensori sono riattivati dai carri che in qualche occasione non fanno contatto oppure dai carri lunghi che sono più lunghi della zona del sensore.
Inoltre, anche se la loco è in 'stop' nel blocco, muovendola a mano, se si 'riattiva il sensore' viene ripetuto il fischio.

Come ovviare a questo 'problema'?
Ovviamente quanto descritto qui con i suoni può essere applicato per qualsiasi tipo di azione...

Un modo facile per eliminare il problema di fischi nel blocco è quello di non usare le azioni del sensore ma di usare le azioni del blocco stesso,come in effetti abbiamo gia visto.
Quindi basterà eliminare l'azione del fischio dal sensore 'fb4' ed applicarla al blocco 'Sta_B_1'.
Eliminiamo l'azione del sensore:
N.B. Ricordate? Prima si eliminano le condizioni e poi l'azione..... (meglio sempre procedere con questo metodo): Ora applichiamo nuovamente l'azione e le condizioni al blocco legate all'evento 'enter': Vediamo e ascoltiamo:


I fischi ripetuti sono dovuti al sensore 'fb6'. Nel blocco il fischio viene eseguito una sola volta. Anche se muoviamo il treno manualmente nel blocco ed il sensore si riattiva il fischio no nviene eseguito. Questo perchè attiviamo l'azione all'evento 'enter' che si verifica una sola volta. Non ci possono essere più eventi enter ma solo uno.

Quindi se l'azione è legata ad un blocco usando le azoini nel blocco risolviamo il problema.

Ben diverso è se l'azione è legata ad un sensore fuori da un blocco, come il sensore 'fb6'.
Come fare ad azionarlo una sola volta?
Potremmo creare una azione che 'spenga' il sensore dopo la prima attivazione (o lo tenga acceso) e poi con un altra azione riattivare il sensore in questione.
E' una soluzione ma richede l'applicazione sia sul sensore che su tutti i blocchi dopo il sensore (tutti i possibili blocchi dopo il sensore in tutte le direzioni). Sono 8 blocchi da aggionrare...

Ma possiamo usare qualcosa di diverso?
Perchè non usare le variabili?

Cosa sono le variabili?
Le variabili (semplificando al massimo) sono dei 'contenitori' che possono avere un valore numerico, alfanumerico, ecc.
Quindi, ad esempio, una varabile può contenere il numero '100'. Poi possiamo cambiare il suo valore a '200' e quindi cambiare ancora e farla 'contenre' la parola 'treno'.
In sintesi sono dei contenitori.
Noi possiamo sfruttare questi contenitori. Ad esempio possiamo controllare cosa contengono. E se contengono quello che ci aspettiamo allora possiamo usarli come condizione.
Ed è quello che faremo. Useremo una variabile come condizione per eseguire l'azione.

Per prima cosa creiamo una variabile.
Il pannello 'Variabili' si apre dal solito menù dei 'Pannelli': Quando apriamo il pannello 'Variabili' troviamo gia delle variabili. Sono predefinite ed usate da Rocrail. Ovviamente quanto mostrato in queste immagini sarà differente nel vostro sistema, ma comunque troverete 2 variabili dal nome 'bk******' e 'lc******' con un numero. Ma noi.... 'non ci curiam di loro ... (cit.)'

Creiamo la nostra variabile.
Premiamo su 'Nuovo': Viene crata una bnuova variabile dal nome 'NEW'.
Selezioniamola ed andiamo nella scheda 'Generale': Cambiamo il nome (ID) della variabile. Come al solito: niente spazi e nomi univoci. Io la chiamo 'var_fischio_Litra': Ora per questo esempio useremo la variabile come 'contenitore' numerico, quindi usiamo il campo 'Valore' per assegnare un valore. N.B. il valore 0 (zero) è un valore. 0 non signicia vuoto ma proprio il numero zero. Noi gli assegnamo il valore 1: Confermiamo con il tasto 'OK' e poi chidiamo il pannello delle variabili.

Ora la nostra varibile con il nome (ID) 'var_fischio_Litra' contiene il valore di 1 (uno).

Andiamo nelle azioni del sensore 'fb6': Troviamo l'azione che fa fischiare la litra. Andiamo nelle codizioni dell'azione: Troviamo le due condizioni: deve essere la Litra ed il pulsante del suono deve essere 'on' (vedi paragrafi delle azioni precedenti).

Aggiungiamo una condizione. Vogliamo usare la nostra variabile quindi il tipo sarà 'Variabile'. Nel campo 'ID' troveremo l'elenco delle variabili. Seleioniamo la nostra variabile: Perchè prima ho dato il valore 1 alla variabile. Perchè voglio che se la variabile ha il valore 1 allora la condizione sia soddisfatta, altrimenti no.
E' lo stesso principio delle condizioni. Deve eseere la locomotiva Litra. Il pulsante deve essere su on.
Nel caso delle variabili possiamo valutare il contenuto.

Per controllare il contenuto scriviamo nel campo stato '=1': '=1' significa: il valore della variabile deve essere '1'

Aggiungiamo la condizione:
Quindi ora l'azione del fischio sarà eseguita solamente se:
1) la locomotiva che lo attiva è la Litra
2) il pulsante del suono è in 'on'
3) la variabile ha il valore di 1

Nel video ho messo manualmente la locomotiva a velocità zero. Ma l'itinerario è attivato e Rocrail si aspetta che la Litra passi sopra al sensore.
Attivo il sensore manulamente ed il fischio si ripete ad ogni attivazione, simulando un carro che non faccia contatto.
Poi, tramite il pannello delle variabili, cambio il valore della nostra variabile. da 1 a 0.
Ora l'azione non viene più eseguita perche non soddisfa tutte le condizioni (la variabile non ha valore 1).



Ora non ci resta che cambiare il contenuto della nostra variabile per far fischiare o non far fischiare.
Ma ovviamente dovrà essere fatto in automatico....

Come facciamo a cambiare il valore di una variabile?
Con le azioni ad esempio.

Apriamo il pannello della azioni e creiamo una nuova azione che chiamiamo 'var_Litra_suoni_on': Il tipo sarà 'Variabile': ID sarà la nostra variabile: Il comando sarà 'value'. Perchè con questa azione assegniamo un valore alla variabile: Nel campo parametro mettiamo '1' (uno): Quindi questa azione assegnerà il valore '1' alla variabile con ID 'var_fischio_Litra'.

Creiamo una nuova azione che chiamiamo 'var_fischio_Litra_off': La cosa che la differenzia dalla precedente è che nel campo 'Paramtero' mettiamo lo 0 (zero): Quindi questa azione assegnerà il valore '0' alla variabile con ID 'var_fischio_Litra'.

Ora apriamo le azioni del sensore 'fb6' ed aggiungiamo l'azione 'var_Litra_suoni_off' sullo stato 'on': Inseriamo però un ritardo di esecuzione della azione di 100 tramite il campo timer: Aggiungiamo l'azione: Aggiungiamo una condizione a questa azione: Analizziamo cosa abbiamo fatto.
Abbiamo aggiunto una azione che si attiva solo se è locomotiva Litra (condizione).

Il sensore ora ha due azioni: La prima esegue il fischio (se sono rispettate le condizioni).
La seconda (eseguita con un ritardo minimo) mette il valore della variabile a 0 (se sono rispettate le condizioni)

Quindi se la locomotiva Litra attiva il sensore eseguirà il fischio e subito dopo cambiera il valore alla variabile. Se il sensore si riattiva la locmotiva non fischierà perchè non sono più rispettate le condizioni.
Lo stesso sensore attiva il fischio e poi lo inibisce quando si attiva. E se si riattiva eseguirà solo la seconda azione, ovvero metterà nuovamente il valore 0 alla variabile.

Ora però, se la locomotiva Litra passa sul sensore fischia una volta e poi mai più fino a quando il valore della variabile non torna a 1.
Abbiamo creato l'azione che mette il valore a 1 ma dove la applichiamo?

Possiamo usare i blocchi, i sensori precedenti ma perchè non usiamo gli itinerari?
Usiamo gli itinerari!
Apriamo il pannello degli itinerari e selezioniamo l'itinerario che stiamo usando per questo demo: Nella scheda 'Generale' troviamo il pulsante per associare azioni all'itinerario: Aggiungiamo l'azione: Le opzioni per lo 'Stato' degli itinerari sono: Selezioniamo 'lock'. Quando l'itinerario è in stato di 'lock' (bloccato) l'azione viene eseguita. Come detto precedentemente quando Rocrail attiva un itinerario quest viene messo in stato 'bloccato' fino a quando il blocco di destinazipone dell'itinerario non viene 'occupato'. Solo allora Rocrail 'sblocca' l'itinerario.

Aggiungiamo l'azione: Ora però dobbiamo agguingere una condizione. Che questa azione sia attivata solo quando è la Litra ad usare l'itinerario: Ed ora vediamo cosa succede:


Ora la nostra Litra fischia una sola volta quando si attiva il sensore 'fb6' e quando entra nel blocco 'Sta_B_1'. Eventuali attivazioni dei sensori non ripetono l'azione.

Ovviamente dobbiamo applicare l'azione che varia la variabile a 1 anche agli altri itinerari che utilizzano il sensore 'fb6' per ottenre lo stesso riusultato.

Le azioni possono essere usate anche come 'sistema di emergenza' per evitare collisioni.

Vediamo questo esempio.
Rocrail imposta l'itinerario che va da 'Est' a 'Sta_B_2' per la locmotiva nel blocco 'Est'.
Poniamo che per un qualsiasi motivo un deviatoio non si metta nella corretta posizione.
In questo esempio il deviatoio 'sw1'. Anche se Rocrail lo muove in posizione corretta io lo sposto 'manualmente' (agendo sulla CS) per simulare il 'malfunzionamento'.



In questo caso il locomotore invece che andare nel blocco 'Sta_B_2', dove Rocrail 'aspetta' che si attivino i sensori del blocco, il 'malfunzionamento' del deviatoio manda il locomotore nel blocco 'Sta_B_1'. Rocrail non 'aspetta' nessun locomotore nel blocco e quando si attiva un sensore del blocco questo mette in 'allarme' Rocrail.
Rocrail dice: 'non mi aspetto nessuna attivazione di questo blocco ---- qualcosa non torna ---- meglio fermare tutto!'
Ovviamente Rocrail non ci dice quanto detto la riga sopra, però esegue il comando. Nello specifico si attiva la condizione 'GHOST'.
La condizione 'GHOST' (fantasma) indica che Rocrail rileva un treno fantasma (GHOST appunto) in un blocco dove non dovrebbe esserci nulla. Per sicurezza Rocrail toglie corrente ai binari, ovvero mette in stato di 'STOP' la CS collegata.

E' una sicurezza importante. Però non funziona se il blocco è invece occupato.

Vediamo. Stessa situazione di prima ma questa volta il blocco è occupato:


Se il blocco è occupato allora Rocrail 'ignora' l'attivazione dei sensori del blocco. Lo abbiamo visto prima con l'esempio di suoni. Il suono legato all'evento 'Enter' viene eseguit solo la prima volta che si attiva il sensore. Ogni altra attivazione del sensore viene ignorata.

Quindi la condizione di 'GHOST' non viene attivata.

Il risultato è un bel tamponamento!

Però possiamo cercare di ovviare a questa situazione con una azione.

Apriamo il nostro pannello delle azioni ed aggiungiamo una azione che chiameremo (ID) 'blocco_emergenza': Questa azione agirà sul 'sistema': Il 'sistema' non ha alcun ID, quindi lasciamo il campo vuoto: Il 'Comando' di questa azione sarà lo 'stop': Le azioni del tipo 'Sstema' agiscono su Rocrail ed hanno influenza su tutto. Nel caso specifico i comand 'stop' oppure 'go' equivalgono ad agire sull'icona che alimenta o toglie l'alimentazione alla CS.

Ora applichiamo l'azione al sensor 'fb4', quello chein questo esempio è il primo sensore del blocco 'Sta_B_1': Questo è l'eggetto della azione quando si attiva il sensore. Toglie la corrente ai binari (ovvero mette in 'STOP' la CS).


Naturalmente non possiamo lasciare l'azione così, altrimenti ad ogni attivazione verrebbe tolta la corrente ai binari.

Aggiungiamo una condizione: Ora l'azione si attiverà solo se il blocco 'Sta_B_1' è occupato.
Nel video seguente vediamo che se il blocco è in uno stato che non è 'occupato' (in questo caso e libero) l'azione non toglie corrente ai binari:


Quindi vediamo cosa succede ora se invece abbiamo un treno nel blocco a differenza di prima:


Ora evitiamo il tamponamento perchè scatta l'azione che toglie corrente ai binari e quindi 'blocca' la circolazione.

Abbiamo quindi implementato la sicurezza nel nostro plastico.

Però dobbiamo fare alcune considerazioni:
La prima è che se il sensore e 'normalmente' occupato da un treno fermo nel blocco (quindi è sempre attivato) l'azione non sarà eseguita:

In questa immagine abbiamo un treno con i vagoni che occupano tutto il blocco, sensori compresi: Il sensore quindi non potrà essere usato come sitema di 'emergenza' perchè è in uso.

Seconda considerazione: Se aplichiamo la stessa azione all'altro sensore del blocco per 'proteggere' il blocco dal lato 'ovest' non otterremo la protezione perchè, come sopra, il sensore è gia attivo (in questo caso è il sensore 'in').

Terza è più importante considerazione:
Se una locomotiva parte dal blocco e si attiva il sensore (perchè un carro lo attiva) l'azione sarà eseguita e Rocrail togliera corrente ai binari.
Perche?
Perchè per Rocrail il blocco resta occupato fino a quando la locomotiva non raggiunge il blocco di destinazione.

Vediamo il problema e come risolverlo. Nei video seguenti ho aggiunto alcune carrozze per visualizzare il problema, come per i suoni ripetuti. In fondo il problema è analogo.

Quando la locmotiva parte dal blocco e si attiva il sensore viene eseguita l'azione e quindi la corrente ai binari viene tolta.
Anche se ridiamo corrente ai binari, ogni attivazione del sensore esegue l'azione:


Come risolvere?
Certo, basterebbe (come dovrebbe essere!) che il treno che occupa il blocco non usi il sensore 'enter', quindi sia più corto.

Invece noi usiamo di nuovo una variabile.
Apriamo il pannello delle variabili e aggiungiamo una nuova variabile che chiameremo 'var_emergenza' a qui daremi il valore 10 come 'contenuto': Ora apriamo le azioni del sensore 'fb4' e nelle condizioni dell'azione del blocco_emergenza aggiungiamo una condizione: Quindi l'azione sarà eseguita solo se il blocco 'Sta_b_1' è occupato ed il valore della variabile 'var_emergenza' è di 10 (dieci).

Ora creiamo due azioni per far variare il valore della variabile.
Creiamo l'azione 'var_emergenza_on' che darà il valore di 10 (dieci) alla variabile: Ed una seconda azione chiamata 'var_emergenza_off' che invece varierà il valore della variabile: In questo caso non ho usato il camondo 'value' che assegna un valore ma il comando 'add' (aggiungi). Nel campo parametro ho messo il numero 5 (cinque).
Il comando 'add' aggiunge (somma) il valore 5 (campo paramtero) al valore della variabile stessa. Giusto per usare un comando nuovo, ma il risultato è lo stesso. Il valore della variabile passerà da 10 a 15.

Dove applichiamo queste azioni?
Nel blocco.
Apriamo le azioni del blocco: Abbiamo la nostra azione del fischio, aggiungiamo le azioni che ci servono. Selezioniamo l'azione 'var_emergenza_off' e come 'Stato' selezioniamo il 'depart': Il 'depart' è lo stato che il blocco assume quando una locomotiva 'parte' dal blocco.
Sebbene graficamente il blocco risulti 'occupato' (colore rosso) quando una locomotiva parte assume lo stato di 'depart'.

Quindi abbiamo aggiunto l'azione 'var_emergenza_off' che aggiunge il valore di 5 al valore della variabile quando il blocco si trova nello stato di 'depart'.

Ora aggiungiamo un'altra azione. L'azione 'var_emergenza_on' quando il blocco si trova nello stato 'free' (libero):
Abbiamo aggiunto l'azione 'var_emergenza_on' che mette il valore di 10 alla variabile quando il blocco si trova nello stato di 'free'.
Lo stato di 'free' (libero) avviene quando il blocco 'lascia' la locomotiva che lo occupava. Avviene quando la locomotiva ha raggiunto il blocco di destinazione ad esempio.

Vediamo il frutto del lavoro:


Ora, anche se il sensore 'fb4' si attiva molte volte, l'azione di togliere corrente ai binari non viene attivata. Se guardate la finestra 'Server' di Rocrail, cedrete che il valore della variabile 'var_emergenza' viene cambiato in 15 quando il blocco viene posto nello stato di 'depart' da Rocrail.
Il valore della variabile viene 'rimesso' a 10 quando il blocco diventa 'free'.

Quindi ora abbiamo il nostro sistema aggiuntivo di 'sicurezza' che protegge il blocco quando occupato ma ovviamente solo da lato 'est'.

Analizziamo cosa succede in questo caso:


Qui non c'entrano le azioni che abbiamo fatto ma come detto prima il 'GHOST'.
Quanda la lococomotiva attiva il sensore 'in' del blocco di destinazine (blocco 'ovest' in questo caso) libera il blocco di partenza. Ma dei carri sono ancora nel blocco di partenza... quindi si attiva il sensore e per rocrailo, come spiegatp prima, avviene la condizione di 'GHOST'. Se il sensore si spegne (mancato contatto) la condizione di 'GHOST' si annulla ma non viene ripristinata la corrente ai binari automaticamente.

Per concludere questo lungo paragrafo vediamo come utilizzare le azioni, oltre che per 'emergenza' nei blocchi anche per il controllo degli itinerari.

Questo esempio è significativo perchè utilizzremo una modalità di applicazione delle azioni differente.

Il presupposto è che un deviatoio non funzioni (non si muove) è che quindi la locmotiva non segua l'itineraio stabilito.
In questo esempio il 'colpevole' sarà il deviatoio 'sw2' (sopra l'inglese) e lo muovero manualmente agendo sulla CS dopo che Rocrail ha impotato l'itinerario simulando il fatto che il deviatoio sia 'guasto'.

Vediamo:


La locomotiva OBB riceve l'itinerario per il blocco 'Diagonale' ma il deviatoio 'sw2' non 'ha funzionato' è la locomotiva si dirige vero i tronchini... Solo l'intervento manuale nel togliere corrente ai binari evita disastri peggiori....

Cosa possiamo fare? Possiamo usare un sensore (in questo caso 'fb1') per controllare che la locomotiva sia sul corretto itinerario. Nella pratica controlleremo che se la locomotiva ha come destinazione il blocco 'Diagonale', se si attiva il sensore 'fb1' (che non è nel corretto itinerario) fermiamo tutto. Perchè se si attiva il sensore allora la locomotiva non è nel corretto itinerario.
Il controllo però deve avvenire su tutti i possibili itinerari che passano su questo deviatoio.

Abbiamo già una azione che toglie corrente ai binari. La abbiamo usata nell'esempio precedente nella 'protezione' del blocco quando occupato.
Possiamo usare la stessa. Aggiungiamola alle azioni del sensore 'fb1': Aggiungiamo le condizioni di attivazione: Perchè 3 itinerari?
Semplice, usiamo un unico controllo. Se si attiva il sensore mentre la loco doveva andare nel blocco 'Diagonale' (indiferentemente se partiva dal blocco 'Sta_A_1' o 'Sta_A_2' o 'Est' che sono gli unici itinerari che possono arrivare a 'Diagonale' per questo controllo) vuol dire che qualcosa di sbagliato c'è e togliamo la corrente.

Vediamo se funziona (ma anticipo che non funzionerà così come impostato):


Solo un provvidenziale stato di 'GHOST' nel blocco 'T2' (per fortuna libero da locomotive) ha evitato danni....

Ma perchè il sensore 'fb1' che doveva togleire la corrente con l'azione non ha funzionato?
Lo scopriamo analizzando le condizioni: L'azione si attiverà quando saranno rispettate le condizioni che abbiamo messo. Se guardiamo le opzioni abbiamo il segna di spunta su 'Tutte le condizioni devono essere vere'.

Vediamo le condizioni: Abbiamo messo che le tre condizioni devono essere vere.
Ma questo è impossibile!
Rocrail potrà usare un solo itinerario alla volta per andare al blocco 'Diagonale'. Non potrà mai usare due o tre itinerari contemporaneamente per andare a 'Diagonale'. Usera quello da 'Sta_A_1' oppure quello da 'Sta_A_2' oppure quello da 'Est' ma ma assieme. Non è possibile.

Quindi non avremo mai i tre itinerari nello stato 'locked' (in uso). Solo uno potrà esserlo.

L'azione non viene eseguita proprio perchè le condiizioni non sono attuabili.

Qui entra in gioco quanto dicevo all'inzio, ovvero una diversa applicazione delle condizioni per far eseguire l'azione.

Se basta che sia solo una condizione a far eseguire l'azione cambiamo l'esecuzine delle azioni: Togliamo il segno di spunta a 'Tutte le condizion devono essere vere': Ora l'azione sara eseguita senza la verifica che tutte le condizione devono rispondere al vero.
Non basta, andiamo nelle condizioni.
Per ogni condizione togliamo la spunta da 'Deve essere vero'. Per ogni azione la selezioniamo, togliamo la spunta e premiamo 'Modifica'.
Alla fine avremo: Se guardat rispetto le immagini pria, ora non c'è piu la 'X' nella colonna 'Deve e..'.

Quindi ora l'azione sarà eseguita se solo una delle condizioni inserite si verificherà. Non importa quale delle tre, basta che una si verifichi.

Vediamo con questo cambiamento cosa succede:


Adesso l'azione viene eseguita. Quando si attiva il sensore 'fb1' una delle condizioni inserite è soddisfatta (in questo caso l'itinerario '[Sta_A_1-]-[Diagonale-] è in stasto 'locked'. Tanto basta per attivare l'azione.

Possiamo ora fare la stessa cosa per controllare se la locomotiva doveva andare ad uno tronchini ed invece il deviatoio la manda verso il blocco 'Diagonale'....

Usiamo il sensore 'fb2'. Il sensore è legato al blocco 'Diagonale' (enter o in a seconda del lato di infresso) ma nulla vieta di usarlo per altri utilizzi.

Quindi apriamo le azioni del sensore 'fb2', aggiungiamo l'azione 'blocco_emergenza' sulla stato 'on' ma togliamo la spunta a 'Tutte le condizioni devono essere vere': Aggiungiamo le condizioni. Tutti i possibili itinerari che arrivano ai vari tronchini ('T1', 'T2', 'T3') dai blocchi.
Tutte le condizioni devono essere inserite senza la spunta su 'Deve essere vero': Ora, se il deviatoio 'sw2' non si muove nella coretta direzione e manda la locomotiva verso 'Diagonale' invece che a un tornchino l'azione fermerà tutto:


Ovviamente questo è solo un esempio. Se ad esempio, sempre nell'esempio sopra, non si muoveva correttamente il deviatoio inglese ('sw3') quanto fatto sopra non sarà mai controllato perchè la locomotiva sarebbe andata nel blocco 'Sta_B_2' quindi nessuno dei due sensori sarebbe stato coinvolto.