Un digitale italiano aperto

[Poggy50]

Ben trovati a tutti.
Come ho avuto modo di scrivere nella mia presentazione sto da tempo sviluppando una mia idea per un digitale aperto e italiano che ci permetta di gestire da PC i nostri tracciati, stazioni e linee in BA anche banalizzabili senza dover usare moduli e centraline costose che non rispettano il segnalamento italiano e sono spesso carenti sotto il profilo della sicurezza nella gestione dei movimenti e delle manovre, particolarmente nelle stazioni.
Il progetto è basato su software sviluppato in Java/Processing e si interfaccia con l’impianto mediante schede Arduino Mega.
Non voglio dilungarmi ma, per chi fosse interessato, allego un pdf che descrive più in dettaglio questa mia idea. Le vostre opinioni saranno sempre gradite e mi aiuteranno a capire se quanto ho fin qui realizzato potrà concretizzarsi in un vero progetto o dovrà diventare un altro sogno da mettere nel cassetto.

[Senialas]

Ciao Gabriele,
nell'allegato leggo quanto segue:

La prima considerazione deriva dal costo non indifferente dei sistemi digitali commerciali, tutti di produzione estera e spesso vincolati a protocolli e specifiche proprietarie che ne limitano l’utilizzazione
alle caratteristiche e alle prestazioni imposte dal costruttore.
Seconda considerazione la difficoltà di disporre di un sinottico dell’impianto che si avvicini, con realismo accettabile, a quelli delle ferrovie reali.
Terza considerazione, forse quella più cara a noi fermodellisti italiani, il fatto che nessuno proponga soluzioni digitali che implementino il nostro segnalamento alto a tre vele, per non parlare dei segnali bassi e delle manovre che sono quasi inesistenti nel panorama digitale commerciale

Ti posso dire che esistono anche realtà italiane a costi contenuti che funzionano bene.
Esistono anche decoders italiani con il firmware per il segnalamento italiano per gli aspetti di segnali a 1, 2 e anche 3 vele. E anche per i segnali bassi di manovra.
Per il sinottico dell'impianto io uso un software di gestione (questo tedesco) con il quale ho disegnato lo schema del mio tracciato e che ritengo abbastanza simile a quelli delle ferrovie reali. Mi da anche l'immagine (o il numero) del treno che si trova sul binario occupato.
Un saluto
Roberto

[Poggy50]

Ciao Roberto,
anzitutto grazie per il tuo parere.

Sono d'accordo che possano esserci soluzioni a costi contenuti per impianti semplici ma non sono stato capace di trovare una soluzione che permetta di realizzare un plastico con stazioni (di testa e passanti) che gestisca itinerari, manovre e linee in BA (banalizzabili) col rigoroso rispetto delle condizioni di via libera e di non interferenza dei movimenti; col reale controllo della posizione assunta dai deviatoi e con la liberazione elastica dei CB interessati dal percorso; col segnalamento alto e basso effettivamente concatenato (nel caso di quello alto) all'aspetto del segnale successivo e alla tipologia del percorso (retto tracciato o deviata).

Come ho detto nella mia presentazione mi sono sempre dedicato soprattutto alla fedele simulazione della movimentazione dei treni, non trovando soddisfacente l'accontentarmi delle simulazioni "di parata", dove i treni si muovono lungo il tracciato e nelle stazioni, con impeccabile regolarità e sicurezza certo ma pur sempre alquanto ripetitiva. La possibilità di ricevere un treno in una stazione di testa, sganciare la locomotiva, far arrivare la loco di manovra che porta le carrozze nel fascio e movimentare la loco che raggiunge il proprio deposito o cambiare la loco al treno per farlo ripartire, il tutto in modalità assolutamente aderente alle condizioni di sicurezza degli ACEI reali, è sempre stato il mio sogno fin da adolescente.

Il mio plastico degli anni 70 rispondeva a tutto questo ma non era riproponibile oggi. Ecco perché ho provato a elaborare questa soluzione che realizza la mia "vecchia" idea in digitale, a un costo decisamente inferiore a quello di mercato. Saprai bene quanto poco costino le schede Arduino Mega e i moduli relè multipli necessari per la gestione dell'impianto. Se guardi la simulazione dell'impianto Faenza, nel pdf che ho proposto, noterai che sono necessari 51CB per gestire correttamente manovre e itinerari. Senza contare il segnalamento che gestisce fino a 9 aspetti diversi per i segnali a tre vele (non ho implementato le segnalazioni a luci lampeggianti per non complicare troppo lo sviluppo del software).

Capisco anche che forse non sono molti coloro che condividono il mio interesse per la gestione reale degli itinerari, delle manovre e del segnalamento ma, come ho detto nel mio messaggio precedente, sarà il tempo a dirmi se è soltanto un sogno da mettere nel cassetto.

PS Se ritieni di voler dare un'occhiata più da vicino alla mia idea posso inviare a te o chi lo desiderasse il kit software per valutare sul tuo PC lo sviluppo attuale del progetto e per un vostro sempre gradito parere.

Gabriele

[Senialas]

Gabriele, ti ringrazio per l’offerta del sw, ma il mio plastico (italiano) è già gestito tramite un sw (TrainController) che controlla i treni, gli itinerari con la relativa predisposizione sequenziale dei deviatoi, con le precedenze e con l’adeguata impostazione degli aspetti dei segnali (incluso il reset appena passata la locomotiva) tramite decoders specifici (fino a 16 aspetti). Ho segnali di protezione preceduti da segnali di avviso (anche se le distanze non sono in scala per ovvii motivi) e segnali di partenza a 1 e 2 vele nelle stazioni (ho 2 stazioni passanti + 1 nascosta senza segnali).
Inoltre ho anche segnali bassi di manovra per il segnalamento durante, appunto, le manovre.
Ti allego un paio di links per darti un'idea.
Come dicevo, sul monitor ho il sinottico del tracciato dal quale è possibile controllare ogni elemento tramite il mouse o la tastiera.
Grazie ancora e ti seguo.
Roberto

[eroncelli]

Altra soluzione possibile è RocRail: ha forse più funzioni di TC ed è gratuito.
Volendo, si può scrivere in codice xml, per attivare funzioni particolari.
Gestisce tutti i protocolli delle comuni CS (incluso applicazioni con Arduino), lavora su Windows, iOS, Linux, Ubuntu e derivati.
Trova interessante l'idea (e molti anni fà la presi in considerazione anche io), ma troppo complessa da sviluppare: dai un occhio a che cosa può fare RocRail.

[Senialas]

RocRail non ha la calibrazione delle velocità e conseguentemente una minor accuratezza sui punti d'arresto.
Questo porta ad avere almeno due sensori (è consigliato sul manuale di RocRail) per ogni tratta, mentre con TrainController (e con Windigipet - che ha anch'esso la calibrazione delle velocità) ne basta uno con notevole risparmio di costi (funzione del numero di tratte).

[eroncelli]

RR ha la calibrazione della velocità, proprio per fermare correttamente le loco: non so dove tu abbia letto che non esiste.
I sensori è meglio che siano 2, perché con uno solo la fermata dipende da un temporizzatore e questo non è un sistema affidabile (regola generale di tutti i sistemi automatici): in RR si usa un solo sensore quando non importa l'arresto preciso (ad esempio stazioni nascoste).
Il sistema permette di calcolare automaticamente la diminuzione di velocità per avere un arresto preciso: il secondo sensore è solo di conferma, perché dovrebbe essere raggiunto solo a velocità prossima allo 0.
So che questo è una supposta limitazione di RR che circola in rete, ma non è vera.
Questo per dire che partire da zero per un SW di controllo treni è una impresa molto, ma molto complessa: tu hai indicato alcuni componenti per i sensori ed i comandi, ma in commercio ve ne sono una infinità e dovresti prevederli tutti.
Ovviamente, mia considerazione personale che non tiene conto della "soddisfazione personale" di realizzare un SW proprio.

[Senialas]

Eugenio, non vorrei ti confondessi tra calibrazione della velocità e delle velocità, fatta con una quindicina di andirivieni per allineare i livelli di velocità del controllo (tipicamente 28) con le velocità in scala calcolate come spazio/tempo.
Non mi dilungo, allego un paio di risposte date da chi ha anche scritto un libro sui softwares per la gestione del plastico.

" ....... Così pure il software conosce velocità e posizione della loco grazie a una calibrazione preventiva con la quale rileva esattamente la velocità reale della loco a fronte di una data velocità impostata.
Questa calibrazione preventiva è presente in WinDigipet e TrainController, non in RocRail e JMRI che invece, a posteriori, durante la circolazione dei treni, calcolano la velocità in funzione del tempo impiegato a percorrere una sezione di lunghezza nota.
Mentre i primi due software sono più indicati per uso personale, dato che non è un problema calibrare preventivamente le proprie loco (ma si possono anche non calibrare, perdendo però alcuni vantaggi di questi due software) e impostare funzioni varie e profili personalizzati per ogni treno, gli ultimi due sono più indicati per uso presso associazioni, dato che questa calibrazione non è richiesta e viene aggiustata per approssimazioni successive man mano che la loco circola (per ora non ho riscontri riguardo alla bontà del metodo) e anche le personalizzazioni di funzionamento attese sono inferiori. "

e ancora:

" ........... Una delle principali differenze tra i sw a pagamento e quelli gratuiti è che i primi offrono la possibilità di "calibrare" le locomotive e ottenere un rallentamento progressivo e fermata in punti diversi (inizio, fine, centro banchina, al segnale, ecc) a seconda del tipo di treno, mentre i sw gratuiti si basano sul rallentamento con CV4 e punti prestabiliti (ad esempio Enter e In).
RocRail ha introdotto il BBT (con autoapprendimento o con introduzione manuale dei valori) o SBT (un po' più brutale) per il rallentamento progressivo, e BAT per l'accelerazione, ma consiglia comunque di usare le CV3 e CV4."

Quindi, di fatto, il raddoppio dei sensori di retroazione costituisce un costo da tenere in considerazione se si opta per RR o JMRI. Poi ognuno è libero di fare la propria scelta.

[eroncelli]

Non conosco l'estensore del libro, ma non ha una conoscenza completa dei sistemi e commette errori clamorosi, dando interpretazioni personali.
Non voglio difendere RR, ma riconfermo che esistono principi di funzionamento di tutti i sistemi logici di automazione e quello di basarsi sui "tempi" è un errore di base.
Ogni sistema ha pregi e difetti: dipende da ciò che si vuole ottenere e, da qui, si evidenzia ciò che serve allo scopo; è difficile confrontare i diversi sistemi e quello del costo non è certo il migliore.
Poi, ognuno pensa come vuole: io, personalmente, non do il supporto ad un progetto che non ha sbocco, mentre altri lo daranno (ma vedo che pochi scrivono su questo argomento).
Comunque, auguri di buon lavoro.

[Senialas]

Non conosco l'estensore del libro, ma non ha una conoscenza completa dei sistemi e commette errori clamorosi, dando interpretazioni personali.

Non sono interpretazioni personali. I limiti di RR sono conosciuti.

Non voglio difendere RR, ma riconfermo che esistono principi di funzionamento di tutti i sistemi logici di automazione e quello di basarsi sui "tempi" è un errore di base.

Non capisco cosa vuoi dire

Ogni sistema ha pregi e difetti: dipende da ciò che si vuole ottenere e, da qui, si evidenzia ciò che serve allo scopo; è difficile confrontare i diversi sistemi e quello del costo non è certo il migliore.
Poi, ognuno pensa come vuole: io, personalmente, non do il supporto ad un progetto che non ha sbocco, mentre altri lo daranno (ma vedo che pochi scrivono su questo argomento).
Comunque, auguri di buon lavoro.

Vero. Ma RR oltre ad avere un'interfaccia utente abbastanza complicata che nasconde costi per i sensori aggiuntivi che invece vanno sostenuti. Poi capisco che chi impara ad usare un sw fa molta fatica ad abbandonarlo e impararne un altro

[Poggy50]

Ciao Seniales.
Non mi dispiace avere suscitato un piccolo dibattito sul tema dei software commerciali per il controllo dei plastici poiché nel confronto e nello scambio di idee, gestito in modo costruttivo, c'è sempre da guadagnarci.

Nel nostro caso condivido il tuo pensiero sulla necessità di essere sempre disponibili a valutare proposte nuove per non rischiare di perdere l'occasione di fare qualche passo avanti.

Seguendo la nostra piccola discussione e altre del forum ho come l'impressione che per tanti amici la cosa più importante sia la fedeltà nelle marcia del treno nelle accelerazioni, nei rallentamenti, nei suoni e nelle luci. Tutte cose belle e opportune ma la riproduzione del traffico ferroviario non può trascurare l'aspetto della sicurezza e del realismo nella gestione degli itinerari, delle manovre e del segnalamento italiano.

Non posso affermare di essere un profondo conoscitore di tutti i sistemi proposti ma non ho ancora trovato (forse per mia mancanza) un sistema in grado di gestire un tracciato come quello denominato Faenza che ho proposto nel pdf che ha aperto questo dibattito.

Nel mio progetto ho potuto gestire tutti gli aspetti della sicurezza e il concatenamento dinamico degli aspetti dei segnali di stazione (alti e bassi) e di linea, con la possibilità di gestire le linee in BA banalizzate.

Il tutto con software che immagino aperto, semplici schede Arduino e moduli relè standard.

Non mi illudo di aver proposto nulla di rivoluzionario ma, vista la ricchezza di proposte circa l'impiego di schede Arduino, in molte discussioni del forum, mi sembrava opportuno.proporre la sviluppo di un sistema che possa essere gestito in totale autonomia da chi condivide la nostra passione per le ferrovie in miniatura.

Sempre grazie per la vostra attenzione e la vostra pazienza.

[Docdelburg]

Caro Gabriele, alias "Poggy50", trovo molto interessante quello che stai cercando di fare e in buona parte hai già realizzato. Se non altro perché quello che stai facendo risponde a un principio a me caro, e cioè sapere dove intervenire perché quello su cui si interviene l'hai fatto tu, e quindi lo conosci nel bene e nel male.
Sono stato per un pò moderatore dell'area digitale di questo bellissimo forum, molto interessato all'argomento e ai suoi sviluppi, sempre con la consapevolezza che un conto era applicare una digitalizzazione più o meno spinta ai plastici e un conto era avere sicurezza nella circolazione. Almeno e soprattutto dal punto di vista di un esperto elettronico quale io non sono.
Avevo utilizzato (uso il passato perché ho abbandonato il fermodellismo attivo per emigrazione all'estero) principalmente Rocrail come programma, (con vari accessori anche autocostruiti con Arduino) suggerendone anche alcune modifiche e implementazioni, ma poi ho finito per constatare come la maggior parte degli appassionati "digitali" si accontentasse di quanto c'era in commercio.
Quasi tutti i programmi o le centrali evolute sono in grado di gestire con dovizia di particolari la circolazione di plastici consentendo al contempo di limitare al massimo i rischi di incidenti. Ma le logiche e i feedback usati sono ancora in parte insufficienti a garantire un vera sicurezza. Si potrebbe ovviare sovrapponendo diversi sistemi, come sensori Railcom, contatori di assi, segnalamento posizione degli aghi dei deviatoi e stato del segnalamento e, sommando il tutto, dare quante più informazioni possibili al programma. Ma come dicevo, di programmi buoni e sufficienti alle esigenze anche dei più pignoli già ce ne sono.
Un esempio è Roberto, alias "Senialas", che ha scelto e usa felicemente un ottimo programma, tanto contento che a volte sembra sfiorare il conflitto di interesse per quanto lo pubblicizza.
Ecco, per quanto ottimo programma, anche quello, sempre dal punto d vista di un esperto di elettronica, ha dei limiti per quanto riguarda la sicurezza della circolazione per come dovrebbe essere intesa. Chiaro che, per un plastico, per quanto complesso, tale programma basta e avanza (e sicuramente Roberto lo affermerà con veemenza....) ma la tua ricerca non può che farmi fare il tifo per te. In bocca al lupo quindi e, rimango nei paraggi, aspettando tue nuove e, magari, la presenza di qualche altro fermodellista interessato.

[Poggy50]

A proposito di sicurezza guardate cosa hanno combinato a Milano Centrale

https://www.lastampa.it/cronaca/2023/01 ... ?ref=LSHLN

Scherzi a parte ovvio che siamo di fronte a un clamoroso errore in fase di manovra contro il quale non c'è molto da fare; però è una conferma di quanto sia complesso gestire la sicurezza nella circolazione ferroviaria e di quanto siano un po "matti" coloro fra di noi che si ostinano a volerla riprodurre anche nelle nostre simulazioni.

[Senialas]

La scelta di un software per la gestione di un plastico è molte volte fatta su fattori che non tengono conto i reali fabbisogni o desideri di chi lo va poi ad usare.
In pochi si prendono la briga di scaricarsi i programmi in demo per un confronto e ancora meno di leggersi i manuali, che per chi non conosce almeno l'inglese, restano inesplorati.
Nel momento in cui si impara un programma per la gestione del plastico, dopo mesi di prove e tentativi, e si acquisiscono conoscenze su quella modalità, diventa poi difficile abbandonarlo e serve un sacco di buona volontà per passare ad un altro. Questa conoscenza selettiva spinge poi anche a trovare vantaggi di quel programma e consigliarlo conseguentemente.
E' vero che io sono un sostenitore di TrainController (TC), come dice Mauro, ma solo perché lo trovo molto più semplice e user-friendly di altri e con una grafica intuitiva (oltre ad avere ottime performances dal punto di vista funzionale). E' una valutazione soggettiva, certo.
Devo però dire che con l'ultima versione, la 10, il costo di TC è salito un po' troppo e ultimamente a qualche mio amico ho suggerito di valutare anche iTrain, che, dopo aver letto il manuale e averlo usato in prova per un mese mi pare faccia tutto quello che si può chiedere per uno dei nostri plastici.

La gestione di un plastico con un software e relativo Pc non è paragonabile a quella con solo la centrale. Chi non ha provato, secondo me, fa fatica a rendersene conto.

Per la sicurezza della circolazione io credo che molti dei programmi in commercio siano in grado di gestirla (leggi: abbiano le capacità intrinseche). Il limite, a mio avviso, non è il software, ma l'installazione e le correlazioni di tutti i sensori necessari per avere, ad esempio, le conferme sulle condizioni minime per aprire un itinerario o garantire una precedenza nei dovuti modi in automatico.
Io ho scelto, ad esempio, di non avere un feedback sulla posizione effettiva dei deviatoi e, senza veemenza, posso dire che in 7-8 anni di funzionamento mi è capitato un paio di volte che un deviatoio non abbia commutato correttamente (era uno degli aghi che si era dissaldato).
Il feedback attraverso i sensori di occupazione, gestito opportunamente con rotabili che hanno anche un minimo di assorbimento, fornisce già un grosso aiuto.
Poi per fin dove arrivare, secondo me, il singolo deve valutare qual'è la soglia operativa che interessa compatibilmente con il lavoro da espletare e ai costi addizionali.
Veniamo al segnalamento, che nella maggioranza dei casi non è funzionale ai fini della gestione. Gli aspetti dei segnali (e soprattutto la loro commutazione) hanno invece un discreto impatto scenico. Quasi tutti i sw lo gestiscono, ma il punto critico, per ottenere gli aspetti corretti e aggiungere ulteriore realismo, sono necessari decoders dedicati. E per il segnalamento italiano, purtroppo, ce ne sono solo un paio sul mercato.

Le tue proposte, Gabriele, rafforzate anche dal fatto che sono indirizzate allo scenario italiano (come il mio plastico), sono ben accette e mi farà sicuramente piacere imparare qualcosa di nuovo.
Un saluto.

[Poggy50]

Roberto (scusa se nel messaggio precedente mi è sfuggito Seniales...) condivido certamente il tuo ultimo messaggio quando descrivi la difficoltà che incontrano molti amici quando intraprendono la non facile strada di realizzare un plastico digitale. Muoversi in ambito tecnico con scelte differenziate, manualistica non proprio scritta per essere comprensibile (quasi sempre in inglese perché noi colpevolmente abbiamo lasciato il pallino in mano a loro...) e costi spesso elevati crea non poche difficoltà.

Ma è proprio per questo che speravo (e un poco spero ancora) di trovare, per così dire, una sponda fra tanti appassionati per provare a realizzare qualcosa che ci svincoli dalla forche caudine di un mercato che, diciamoci la verità, considera il segmento italiano come assolutamente marginale e non degno nemmeno di ricevere una manualistica tradotta correttamente!

A volte ripenso al mio vecchio plastico in cui, grazie alle rotaie Marklin, avevo CB reali e ero riuscito ad aggiungere, nel cavo degli scambi con massicciata incorporata, due sottili contatti che mi davano persino il controllo della posizione dei deviatoi...

Ma come ho detto è un tempo ormai lontano ed è per questo che mi era venuta l'idea di lasciare all'elettronica "di mercato" il solo compito di gestire trazione e effetti vari (luminosi e acustici) delle loco, limitando così credo non poco il costo della cosiddetta parte accessoria per la regolazione del traffico e per il sinottico sul quale controllare l'impianto.

Per fare un esempio concreto ho sviluppato un accoppiamento fra logica centrale Arduino Mega) e segnale a tre vele mediante un semplice Arduino Nano (dal costo quasi inesistente) che permetterebbe di gestire gli aspetti del segnale con un solo conduttore (a parte la massa...). Resta ovviamente il problema dei tre colori: non mi è ancora riuscito di trovare led di dimensioni adeguate ai nostri segnali in grado di generarli.

Ecco perché in fondo non smetto di sperare che, un passo alla volta, unendo le conoscenze e le esperienze non si possa arrivare a realizzare qualcosa di concreto da testare magari su un semplice tracciato di prova, propedeutico a una realizzazione definitiva per chi sia sul punto di intraprendere la costruzione di un nuovo plastico.

Un sogno? Chi sa...

[Senialas]

Gabriele,
un grosso in bocca al lupo per questa tua attività.
Se avessi qualche domanda chiedi pure.
Prova a guardare qui se ti può servire per i led a 3 colori: https://www.fermodellismo.it/pcita/shop ... erca&rg=49

[Poggy50]

Buona sera a tutti, premetto le mie scuse per la non breve assenza dal forum per vari motivi che hanno molto limitato il mio tempo libero.

Ho letto i vostri contributi e vi ringrazio per l'attenzione ma non posso fare a meno di notare che forse è stato sottovalutato il cuore della mia proposta.
Se infatti osservate l'immagine che allego nuovamente noterete

ad esempio l'itinerario in partenza dal binario 7 della stazione di testa verso la stazione nascosta passante che incontra il segnale alto di partenza col sottostante segnale basso (disposti a via libera) e successivamente un ulteriore segnale basso (limite di manovra) anch'esso a via libera. Forse sbaglio ma non ho trovato software che possano predisporre un itinerario gestendo una pluralità di segnali alti e bassi italiani, con aspetti correttamente impostati secondo la tipologia del percorso (retto o deviato) e con aggiornamento in tempo reale in base all'aspetto dell'eventuale segnale successivo.
Aggiungerei inoltre una piccola provocazione: ma pensiamo davvero di poter delegare la gestione delle accelerazioni e decelerazioni a uno dei tanti sistemi commerciali o liberi in circolazione?
Tento per cominciare, per ovvi motivi le manovre devono sempre e comunque essere gestite da un operatore. Ma poi è proprio impossibile ipotizzare che sia sempre l'operatore a gestire rallentamenti e accelerazioni dei propri treni?
Non credo che la cosa sia poi tanto difficile, a meno di voler simulare stazioni come Roma Termini o Milano Centrale con arrivi e partenze simultanei di 3/4 treni!
Rinunciando alla "delega" del controllo della velocità al sistema "proprietario" si potrebbe benissimo limitare l'investimento economico della componente digitale, con la soddisfazione di avere un vero realismo nella gestione della sicurezza e del segnalamento italiano dei treni e delle manovre anche in impianti complessi.
E a proposito di realismo, che dire della sicurezza nella movimentazione se ci si limita a considerare libero un binario di stazione o un tratto di BA a condizione che non vi sia sopra una loco col suo controller? Con questa logica si può benissimo ipotizzare che un treno entri in un binario di stazione occupato da soli vagoni generando così un realistico incidente.
In passato sentivo parlare del "grafitaggio" degli assi (metallici) dei vagoni. Non so se vi sia ancora chi ricorre a questa tecnica per gestire in massima sicurezza i circuiti di presenza.
Attendo con sincero interesse i vostri pareri e confido nel coraggio di qualche appassionato che sia disposto a "uscire dagli schemi" delle logiche commerciali.
In fondo i sogni sono il sale della vita

[eroncelli]

Purtroppo, io (da ex programmatore di sistemi automatici industriali, su tutte le piattaforme) la vedo molto dura: i sw personali che ho visto erano tutti "dedicati", cioè per quell'impianto e quell'hardware (e quelle funzioni definite).
Già predisporre un SW che si interfacci con "n" tipologie di apparati (CS, sensori, attuatori etc) e con vari protocolli è molto complesso: poi, se qualcuno vuole divertirsi, ne ha piena facoltà.
Forse, ma dico forse perché vedo una certa avversione ad alcuni SW già disponibili, potrebbe essere più semplice sviluppare una parte aggiuntiva di SW che meglio presenti il segnalamento italiano: RocRail lo permette, altri non so (non carico di continuo tutti gli aggiornamenti di altri SW: l'ho fatto all'inizio per decidere quale scegliere).
Personalmente, l'utilizzo completo del complicatissimo sistema di segnali italiano è limitato a pochissimi impianti, certamente non delle dimensioni di un plastico casalingo.

[Poggy50]

Buongiorno Eugenio, grazie per il tuo parere che mi ha fatto venire il dubbio di non aver chiarito bene il "perimetro" del mio software.

Il mio progetto non è assolutamente pensato per essere dedicato a un tracciato particolare. Quello che ho mostrato è solo a titolo di esempio per mostrarne le potenzialità, per quanto possibile a partire da una singola immagine.
Sono assolutamente d'accordo che è tutt'altro che facile interfacciarsi con la marea di apparati che il mercato e a volte anche tanti bravi smanettatori propongono ed è proprio per questo che ho cercato di sviluppare un software che, nelle mie intenzioni, dovrebbe diventare "aperto" e interfacciato con schede Arduino Mega che, come ben sai, sono ormai uno standard consolidato e affidabile.
Dall'immagine avrai notato che, già nell'attuale versione, itinerari, manovre, deviatoi, circuiti di binario (o circuiti di presenza che dir si voglia) e segnalamento italiano (alto e basso) sono gestiti con un realismo che mi sembra più che soddisfacente e così pure le linee in blocco automatico (anche banalizzabile) senza la necessità di ricorrere a particolari centraline o software commerciali.
Gli unici "oggetti" esterni con i quali devono interfacciarsi il software e le schede Arduino sono i deviatoi (volendo si può rinunciare al controllo di posizione), i segnali, i circuiti di presenza e i relè che interrompono la trazione davanti a un segnale a via impedita.
Come ho scritto nel mio precedente intervento la gestione digitale potrebbe essere molto semplificata lasciando la regolazione della velocità dei treni all'operatore (cosa fra l'altro necessaria per le manovre).
Se volessi approfondire anche solo per curiosità lo stato del progetto posso inviarti il software con la sua documentazione.

Gabriele

[Roberto Fainelli]

La buona riuscita di un software dipende molto anche da ciò che controlla e da ciò che lo utilizza. E non necessita di funzioni trascendentali perché tutto il trasporto ferroviario è comunque in mano ad degli agente che siano questi un macchinista o un dirigente movimento o un manovratore. Nel mondo reale ferroviario moderno, escluse le manovre, é tutto controllato da sistemi di sicurezza. Quindi quando hai un SW che ti fa gli itinerari con tutti gli annessi e connessi, vincolati tra loro che ti permettono incroci e precedenze varie, basta ed avanza. Sul mio plastico uso rocrail perché provato e non più abbandonato, come giustamente detto, per non esaurirsi in nuove esperienze che il suo sporco mestiere lo fa. Gli inconvenienti ci sono ma dipende qualche volta dagli scambi che non girano perché si incagliano. Dipende dai rotabili che deragliano senza motivo per cui va tutto in tilt per correre dietro allo svio. Le velocità dei treni le determini con le impostazioni del decoder della macchine e dagli spazi che hai nella sezione. Se hai una sezione da un metro e mezzo non puoi pretendere di fermare un treno in modo reale. Poi con il SW puoi aggiustare qualcosa.

[Senialas]

Tralasciando il discorso di Arduino, che, pur non avendo nulla in contrario, preferisco evitare (meglio una centrale chiusa con solo le interfacce e senza ulteriori fili che collegano schede con collegamenti a rischio), ti vorrei dire che io uso un sw commerciale da diversi anni e riproduco tutto il funzionamento della ferrovia italiana, con segnali alti e bassi che danno il consenso su alcune tratte condizionato al segnale successivo. Passata la prima carrozza il segnale viene resettato.
Confermo anche che non servono relé per interrompere la trazione davanti al segnale chiuso in quanto il rallentamento e l’arresto vengono controllati (anche locomotiva per locomotiva) direttamente dal sw.
Aggiungo che si può controllare anche la velocità per le manovre: io cambio la locomotiva di un treno merci sganciando la prima loco, aggiungendo due carri tramite una loco da manovra (che poi se ne va) ed agganciando poi la nuova loco - tutto in automatico.

[IpGio]

Seguo con interesse la discussione.
La proposta di un digitale italiano è di certo ecomiabile ma presenta tante sfaccetature.
I sw oggi sul mercato offrono ampie possibilità e le difficoltà sono la lingua e la disponibiltà dli punti di incontro per confrontarsi (il GAS TT ci prova).
Arduino è UNA soluzione, non è LA soluzione e per esperienza puntare il budget per una buona centrale e relativi accessori ivi compreso un buon software è la via più lastricata che oggi un ferromodellista possa trovare sul mercato.
Di un sw bisogna pur sostenere un supporto ed un costante aggiornamento che impegna risorse di tempo e ahimè di denaro e un sistema aperto necessita di una buona squadra di lavoro a sostegno.
Oggi sul mercato esistono tanti sw e basarsi su prodotti che hanno alle spalle un unico soggetto rappresenta un rischio da tenere in conto.
È pur vero che basarsi anche su aziende strutturate presenta dei rischi (ricordo il recente tracollo di una famosa azienda che produceva hd in campo modellistico, che per fortuna oggi ha ritrovato la strada del commercio sotto altre mani).
Credo che per il futuro si debba trovare un modo per rendere sempre di più "user friendly" il ferromodellismo basato su DCC per attirare quanto più possibili nuovi appassionati che si trovano a dover far i conti con budget e spazi sempre più risicati tenendo ben presente il detto "chi meno spende più spende".
Di certo questo progetto è interessante perché ci porta a conoscere più da vicino un aspetto molto interessante del nostro amato hobby che ci vede un poco progettisti, falegnami, elettricisti, informatici e sopratutto aperti a nuove proposte.
Buon ferromodellismo e per chi lo desidera appuntamento all'Hobby Model Expo 2023 a Novegro dal 22 al 24 settembre, padiglione "grandi plastici" con il nostro modulare a norma GAS TT (1:120) la "scala perfetta".

IpGio

[Poggy50]

Carissimi tutti.

Mi rendo conto che su questo forum si incontrano due scuole di pensiero che hanno in comune un solo obbiettivo: la nostra passione per il modellismo ferroviario che è uno spazio molto ampio nel quale si incontrano scelte e interessi diversi e non poco articolati.
Conosco (o conoscevo...) amici che si limitano a collezionare carrozze ferroviarie rifinite dentro e fuori in maniera splendida, in teche degne di una collezione di gioielli. Altri che costruiscono piccoli diorami con pochi o nessun movimento ma così ben fatti che quando vengono fotografati con la giusta prospettiva a prima vista possono sembrare scenari reali.
E poi ci sono quelli che costruiscono plastici destinati a contenere stazioni e linee nelle quali si muovono treni merci e passeggeri, con le relative manovre di stazione. Ed è qui che si possono individuare due tendenze. Da un lato vi sono coloro che "delegano" quasi tutta la movimentazione, arresto e partenza, regolazione della velocità e quant'altro necessario a far vivere il plastico a centraline e soluzioni commerciali, accettando dei quadri sinottici che spesso sono quanto meno essenziali e/o non in grado di mostrare il segnalamento italiano. Poi vi sono coloro che dal digitale prendono volentieri i decoder per gestire le loco, i moduli per rilevare la presenza del treno sul tracciato (spesso accettando che non vengano rilevati i vagoni isolati...), i moduli per gestire i deviatoi e il segnalamento e tutto ciò che occorre per interfacciare il "posto di comando" col plastico.
E' ben vero che i primi sono ormai la maggioranza, in un mondo che ci sta pian piano abituando a essere troppo fruitori della tecnologia e poco protagonisti, poco interessati ad andare al di là di una semplice utilizzazione del mondo digitale, senza la possibilità (o la voglia) di metterlo in discussione nei suoi aspetti economici o di soddisfazione per quanto ci restituisce.
Io appartengo alla seconda categoria, forse per via della mia storia che ha le sue radici negli anni 70/80 quando le nostre ferrovie introducevano i primi ACEI che, con l'uso esteso dei relè, cambiavano il volto della movimentazione dei treni mandando in pensione i sistemi idrodinamici, quelli a leve e chiavi, le cabine multiple per la gestione degli istradamenti (vedasi Milano Centrale) e realizzando la "liberazione elastica", una vera rivoluzione nella gestione delle stazioni in termini di flessibilità, efficienza e rapidità di esecuzione dei comandi.
Per me, in quegli anni, è stato motivo di grande soddisfazione realizzare un plastico nel quale relè, selettori e pulsanti riproducevano puntualmente itinerari e manovre come nelle ferrovie reali. Era davvero bello far entrare un treno nella stazione di testa, sganciare la loco, far arrivare la nuova loco dal deposito con movimenti di manovra governati dalle marmotte e far ripartire il treno. Per poi inviare la loco rimasta isolata al deposito. Altrettanto bello era comporre e scomporre i treni passeggeri nel fascio carrozze, grazie alle loco Marklin che (uniche in quel periodo) potevano aprire e chiudere il gancio senza decoder (!). Credo che ad oggi non esista alcun software che permetta di eseguire automaticamente manovre di questa complessità e, anche se esistesse, non mi piacerebbe, dopo tanto lavoro per costruire il mio plastico, guardarlo vivere di vita propria.
Personalmente rivendico il mio piacere e la mia soddisfazione di essere il dirigente e, perché no, il macchinista dei miei treni ed è per questo che ho cercato di sviluppare un sistema che permetta di gestire qualsiasi tipo di stazione e di percorso e, in prospettiva, anche la possibilità di avere (in un grande plastico con più di una stazione) più di un operatore. Il tutto rispettando le condizioni di sicurezza come nella realtà e gestendo i movimenti e le manovre col mouse da un sinottico intelligente e esaustivo che rifletta il segnalamento italiano.
Comprendo la riserva dell'amico IpGio che sottolinea il rischio di utilizzare un software che non abbia le "spalle" abbastanza robuste in termini di sviluppo e supporto ed è proprio per questo che quando parlo di proposta aperta intendo la messa a disposizione di tutti i sorgenti e la documentazione della mia proposta per chi sia eventualmente davvero interessato.
Buon lavoro e un sincero saluto a tutti gli appassionati.
Gabriele

[Edgardo_Rosatti]

Mi viene in mente quando quasi 10 anni fa vidi a Verona un piccolo stand nel quale c'era un ragazzo che presentava una fedele riproduzione di un banco ACEI con tanto di sala relè e quadro sinottico.
Se non ricordo male riproduceva una parte del traffico ferroviario romano.
Il funzionamento del segnalamento era impressionante ed il tutto funzionava senza software vari o protocolli digitali.
In bella mostra sopra lo stand c'era una insegna che riportava qualcosa come: "Diventa capostazione per un giorno".
C'era anche un sito che ne parlava, ma non iricordo assolutamente quale link avesse.

Sono d'accordo con te Gabriele, buon viaggio! Come diciamo noi macchinisti.

[fabio]

Mi viene in mente quando quasi 10 anni fa vidi a Verona un piccolo stand nel quale c'era un ragazzo che presentava una fedele riproduzione di un banco ACEI con tanto di sala relè e quadro sinottico.
Se non ricordo male riproduceva una parte del traffico ferroviario romano.
Il funzionamento del segnalamento era impressionante ed il tutto funzionava senza software vari o protocolli digitali.
In bella mostra sopra lo stand c'era una insegna che riportava qualcosa come: "Diventa capostazione per un giorno".
C'era anche un sito che ne parlava, ma non iricordo assolutamente quale link avesse.

Sono d'accordo con te Gabriele, buon viaggio! Come diciamo noi macchinisti.

Ricordi bene è il caro amico Salvatore Graziadio,ha ancora il banco Acei ma ora ha trasformato quella parte in moduli funzionanti casa\manifestazioni.