SW di gestione plastico e segnalamento FS

[Marco Fornaciari]

Sto verificando quale SW eventualmente utilizzare per controllare il plastico, consideranto sia i gratuiti sia quelli a pagamento.
Ma veniamo al dunque, condizione fondamentale e che sia possibile gestire il segnalamento FS, quindi tutte la combianzioni di: rosso, verde, giallo e pure lampeggianti.
Da tutte le letture che ho fatto fin'ora sembra che nessun SW sia in grado di fare questa gestione, ma mi pare che qualcuno ci sia riuscito.
Quindi la domanda è: qualcuno è in grado di darmi qualche indicazione in proposito, o/e indicarmi documentazione utile allo scopo.
Grazie

P.S.
Di fatto automatizzare il plastico non mi interessa, e non avrebbe senso dato il layout.
Magari potrebbe essermi utile imporre la bassa velocità in presenza del giallo, ma se non riesco a gestire appunto il giallo il problema decade.

[Senialas]

Scusa Marco, quali softwares hai valutato finora per affermare quanto asserisci?

[Marco Fornaciari]

La risposta più pertinente è: tutti e nessuno.
Ho solo letto informazioni generali e recensioni, sicuramente non aggiornate.
Di mettermi lì a legegre i manuali o meglio ancora instalalre le versioni trial, manco a pensarci; non pegrizia ma perchè dovrei leggere tanta roba schamtica e tradurla, non tanto in italiano, ma in concetti e principi di programmazione per me ben diversi e con i necessari paragoni a linguaggi più potenti: installare altri trial sul PC non se parla neanche: già troppi e ultimanente i programmi sono troppo spesso scritti quasi coi piedi (pure quelli professionali) e quindi mi creano problemi ai SW professionali che ancora utilizzo.

Quindi la richesta di informazioni è giusto per saltare questi passaggi e verificare se qualcuno ha già messo in atto le suluzioni che intendo applicare, quindi scartare a priori ciò che non fa al caso mio, va da se che se tutti si limitano la rosso/verde, a beh allora ...

Va de se che considerato che sul mio plastico:
- che la gestione del blocco in linea riproduce il BEM
- guida manuale dei treni
- mi interessa riprodurre un ACELI in una stazione
- mi interessa riprodurre un ACEI semplice nell'altra stazione
- mi interessa riprodurre il segnalamento che utilizza il giallo lampeggiante
attraverso un SW faccio prima.
Se non riesco a farlo con un SW dedicato al mondo dei treni, così da lasciare agli eredi qualcosa di facilmente gestibile da tanti appassionati: procedo con HW professionale e PLC, mi costa meno è faccio quello che voglio.

[Senialas]

Io uso TrainController e, come puoi vedere, puoi fare (in associazione ad un decoder per segnali italiani) tutti gli aspetti che vuoi.
Qui sotto il link ad un'immagine che mostra l'impostazione del segnale con i vari aspetti (Rosso, Verde, Giallo e Giallo lampeggiante).
La freccia blu indica la conficurazione del segnale da scegliere: in questo caso 4 aspetti.
https://drive.google.com/file/d/1W4HUMF ... sp=sharing

[Marco Fornaciari]

Mi sa tanto che nessun SW faccia al caso mio.
Ho trovato qualche manuale e spiegazione semplificata, e se ho inteso bene l'itinerario appartiene al treno, cioè a quell 'indirizzo di decoder: non ci siamo, la ferrovia vera non funziona così, quindi non fa al caso mio.
Nel mio plastico come al vero, una cosa è la via con gli itinerarri e gli instradamenti, ben diverso è il treno: solo il DM sa che quell'itinerario è destinato a quel treno, e non viceversa.
E tra l'altro un tempo esisteva un modulo per dare dei comandi indipendenti ad una tratta di binario, un comando DCC broadcasting destinato a chi c'è nella tratta senza sapere chi è.
Nel mio plastico il treno si muove seguendo le indicazioni dei segnali e comandato a mano dal macchinista, il segnalamento rispetta il reale a prescindere dal treno in quanto tale, è il DM ch deve sapere fare il suo mestiere.
Quindi un SW che come base usa il treno e il percorso che si vuole che faccia non han nessun senso. Concettualmente va be per una linea o/e servizio metroplitano su linea a doppio binario, ragion per cui non ha ragione spenderci soldi e tempo.

Probabilmente, anzi, scrivendo delle macro si riesce a comandare i segnali in modo indipendente e a non inviare comandi ai decoder, ma a questo punto il gioco non vale la cendela con quei tipi di SW.

[Senialas]

Mi sa tanto che nessun SW faccia al caso mio.
Ho trovato qualche manuale e spiegazione semplificata, e se ho inteso bene l'itinerario appartiene al treno, cioè a quell 'indirizzo di decoder: non ci siamo, la ferrovia vera non funziona così, quindi non fa al caso mio.

Non è vero. L'itinerario appartiene a chi decidi tu: al singolo treno, a più treni (es. ai treni passeggeri) o a tutti i treni. Basta solo decidere e programmarlo.

Per il resto il tuo è un parere del tutto personale che però non condivido. Seconde me il sw, nella versione completa, funziona egregiamente e ha tutte le flessibilità che servono.
Se poi non ti piace scrivi pure tutte le macro che vuoi. Ognuno è libero di giocare come vuole.

[Marco Fornaciari]

C'è qualcosa che secondo me sfugge, salvo manuali che ho letto incompleti o/e imprecisi nella traduzione.
Ogni treno deve avere i suoi itinerari, quindi teoricamente, e mi sa pure di fatto, se voglio gestire tutta la movimentazione in modo libero mi devo complicare la vita: compilare tabelle e scrivere scrit in lingaggi non matematici non è la mia massima aspirazione, anzi.
Diversamente, e come ripeto, volendo comadare tutto in manuale, e considerato che non ho nessun blocco automatico, tanto meno concatenato, quei SW usati solo per gestire gli aspetti dei segnali in coerenza con la posizione degli aghi degli scambi, e al limite per lo stato di occupato di 10 metri di linea scaramente visibile, non ha nessun senso.
In concreto l'unico automatismo che mi serve è la distruzione dell'itinerario, cioè il ritorno in posizione normale o/e di via impedita dei segnali: che è quello che fanno ACELI e ACEI di piccole stazioni.

Siccome non si tratta della stazione Centrale di Milano, posso farlo anche con una manciata di relè (uno per ogni itinerario possibile, una decina) e qualche matrice di diodi: non è tecnologicamente avanzato, ma queste tecnologie sono ancora in uso su tanti impianti e macchine utensili, e a scasarli ci devi mettere tanta buona volontà. E per la regola di Ford: quello che non c'è non si guasta, potrebbe anche andarmi bene.
In manovra poi tutto ciò non mi serve, quindi è escluso, come al vero.

Poi se riesco a recuperare HW non ingombrante e a costo prossimo a nulla (sul costo ci siamo, ma sull'ingombrante ancora no) allore un SW faccio prima a scriverlo che a pensare di farlo, e faccio pure di più che con i SW commerciali dedicati.

Si tratta solo ci conoscere i vari sistemi disponibili, in fin dei conti nelle ferrovie reali usano gli stessi sistemi dell'automazione industriale, unica differenza è che sono costruiti per resistere a condizioni climatiche limite: -50/+70 °C, 95% umidità, quindi quelli a bordo dei veicoli devono anche resistere ad alcuni G di accelerazione e parecchi Hz di vibrazioni.

[Luca]

Ciao Marco

mi sfugge una cosa: stai valutando l'uso di un software anche per "simulare" i banchi ACEI o solo per la coerenza dei segnali?

Parlando ad esempio di Train Controller, non sei "obbligato" ad usarlo anche per il movimento automatico dei treni o per la gestione dei blocchi. Hai la completa libertà ad esempio di costruire il tuo layout e definire degli "itinerari" attivabili tramite pulsanti. Train Controller si occuperebbe in tal caso "soltanto" di attivare scambi e segnali in coerenza con l'itinerario e poi saresti tu comunque a muovere il treno... volendo puoi anche evitare la definizione dei blocchi e quindi il fatto che TC "segua" il treno mentre lo muovi (comunque a mano). Oppure puoi inserire i blocchi solo per avere l'informazione della posizione attuale del treno o ancora per attivare, all'ingresso di un qualsiasi treno in un blocco, una macro o un automatismo (es. simulare il simbolo A.T. sul banco ACEI) oppure in uscita per "distruggere" l'itinerario.

Infine avendo un secondo "grado di libertà" lato configurazione decoder, molto spesso puoi usare questa ulteriore flessibilità (es. per il "lampeggio", che non è comandato direttamente da TC invando periodicamente ON/OFF ma è una configurazione dell'uscita del decoder quando TC la imposta semplicemente ad ON).

Dalla mia esperienza ho sempre visto grande flessibilità in questi software e quindi la possibilità di "adattarli" al grado di realismo e di "giocabilità" che ognuno vuole ottenere.
Comprendo il tuo discorso che tutto questo possa essere anche rifatto "custom", sviluppandosi in casa un sistema di automazione magari meno complesso di quello che può fare TC ma più "tagliato" sulle esigenze specifiche... alla fine è una valutazione personale di tempo da spendere, "divertimento" nel farlo e - come dicevi all'inizio - anche di prospettive di manutenibilità futura.

[Marco Fornaciari]

Luca hai fatto centro.
Io poi ragiono da progettista e costruttore di sistemi di automazione a livello di stabilimento intero, quindi prendo in esame prima ogni aspetto dove alla fine il costo deve essere giustificato da tanti fattori (anche da chi deve pulire le macchine a fine turno).
A livello di tecnologo, un sistema come i SW commerciali per plastici sono una manna, a livello di programmatore di funzionamenti reali no, sono rigidi e dispersivi: con alcune logiche con 4 istrusioni risolvi un problema, con altre non ne bastano 20, e io sono per le 4 sempre e comunque, e questi SW vanno verso le 20.
Quindi è solo una questione di esperienza e conoscenze.
Nel mio caso le parti più complesse sono due gruppi da 4 scambi e due + 1 segnali a candeliere (ACELI e ACEI semplici di prima installazione, quindi anni '50/'60) e nessuna influenza diretta sui treni, pertanto un SW a pagamento come quelli è sempre troppo costoso, e Rocrail usa un sistema per gli script che non ho nessuna voglia di imparare e mi sta pure antipatico, ** e tra l'altro è pure molto lento nell'elaborazione (8 ms per eseguire 1 Mb di programma per me sono già tanti).
Certo se uno nasce informatico o elettronico puri quei SW piacciono, me se uno ha le mie esperienze fa di tutto per evitarli. Sono proprio due mondi diversi di approccio e soluzione dei problemi; che tra l'altro chi fa il mio mestiere deve conoscere entrambi.

Che poi il mio vero problema è avere un gateway sicuramente funzionante d'interfacciamento tra mondo DCC e tutto il resto, a "rompere le scatole" sono i famosi 16666,6666666 baud del mondo DCC. Fino ad ora non ho trovato nessuno che abbia voglia di farlo, ovvero un tempo c'era un produttore industriale che faceva un apparecchiatura utilizzabile, ma poi qualcuno si è accorto che così potevi mischiare i prodotti di diversi produttori, quindi commercialmente non va bene, se ne avessi "imboscato" uno, ora sarei a cavallo.

**
Alla prima occasione sono andato in pensione anche perché con i PLC moderni bisogna scrivere i programmi in modo assurdo e dispendioso di risorse e tempo: per la stessa automazione repplicata mi si è raddopiato il tempo solo per dovere pigiare di più sulla tastiera e pure obbligato a passare continuamente le mani da mouse a tastiera, e in alcuni casi certi funzionamenti son diventato matto per farli.

[Luca]

Ciao Marco

non sono molto d'accordo con qualche tua affermazione ma come scrivi anche tu alla fine sta alla "voglia" che ciascuno ha di seguire una o l'altra strada
Buon divertimento!

[Marco Fornaciari]

Proseguono i mie studi per riprodurre ACELI o ACEI dei primi tempi.
Premessa importante:
1- ho intenzione di riprodurre un sinottico reale FS, quindi pannello nero e simboli FS
2- va da se che prima di spendere 1/100 voglio avere certezza di riuscire negli intenti con HW e SV commerciale di tipo DCC
3- il segnale DCCintendo usarlo solo per comandare i treni, niente scambi o quant'altro (la quantità di uscite/comandi da gestire è tale da manadre nel pallone il sistema, o/e di renderlo eccessivamente lento).

Quindi domande e scambio di esperienze

4- Da letture dei manuali dei vari SW (JMRI compreso) non mi pare sia possibile sviluppare (senza scrivere di nuovo Guerra e Pace) un sinottico come sopra, giusto?
(Va da se che con altri SW è possibile e li faccio/evo abitualmente per diverse situazioni)

5- Stando ai cataloghi dei produttori di HW reperibile in Unione Europea (i costi di trasporto e dogani diversamente fanno cadere il discorso) ho trovato che solo Uhlenbrock ha moduli di comando di accessori anche gestiti tramite Loconet, giusto?

6- Per chi come ma ha la DR5000, c'è chi usa il suo script? E se si, sa se a parte l'esempio allegato al SW proprietario se ne trovano altri, io ne ho trovato uno ma di fatto mi serve a ben poco (anzi forse è il video dell'esempio, poi verificherò meglio).

7- Sempre in tema di DR5000, oltre leggere i moduli di Feedback riesce a comandare i moduli di uscita, sul manuale e dal suo SW pare di no, e anche Digikeijs non faceva HW di uscita per Loconet.

8- Sto verificando anche la possibilità di utilizzare altri SW diversi da quelli DCC, e forse riesco a costruire i driver di comunicazione DCC e Loconet, utilizzando solo la centralina come gateway, es. la DR5000 di fatto è solo un gateway così come la Z21 (e altre centraline senza terminale operatore), chi comanda è sempre: un palmare, una App su telefonino o tablet, un SW su PC.

Il resto alla prossima puntata.

[Luca]

Ciao Marco

non capisco una cosa di base: perché vuoi comandare gli accessori (scambi / segnali) via Loconet e non tramite DCC, complicandoti la vita e restringendo di molto i dispositivi a tua disposizione (come scrivi non esistono molti decoder accessori Loconet, mentre la scelta sul DCC è ampissima)?

Comunque, realizzare un "gateway" PC -> Loconet è abbastanza banale e ne trovi di già fatti (il "locobuffer" in tutte le sue declinazioni e vendor fa proprio questo). Tu costruisci (con il sw che vuoi) il comando secondo il protocollo Loconet (qui le specifiche: https://www.digitrax.com/static/apps/cm ... dition.pdf) e lo invii alla seriale a cui è collegato il Locobuffer, il quale lo invierà sul bus e viceversa (ti "restituirà" sulla seriale tutti i pacchetti ricevuti dal bus).

Mi sembra più semplice che usare la centralina come gateway: in questo caso:

- dovresti implementare il protocollo di comunicazione PC -> centralina
- potendo avere un solo software che dialoga con la centralina, il tuo software dovrebbe SIA implementare logica e comandi x banco ACEI, SIA eventualmente comandare i treni (mentre avendo un gateway Loconet separato ti tieni aperta la possibilità di avere due software distinti, uno per il movimento treni e uno per la parte Loconet)

bye

[Marco Fornaciari]

Allora, il problema di fondo è che in 4x 2,2 metri, voglio tentare di riprodurre la reale gestione tra due stazioni passanti ed entrambe di diramazione: da una parte entra una linea dall'altra ne entrano due.
Blocco automatico no, ma BEM si, e qui è banale.

Però per gestire un ACELI e un ACEI completi, o quasi, mi occorrono:
- soluzione 1 senza segnali di protezione e avviso in campo, solo gestiti nella logica, 256 ingressi e 128 uscite dal sistema
- soluzione 2 con anche segnali di protezione e avviso passiamo a 384 ingressi e 192 uscite.
Gli I/O non sono usati tutti e il calcolo è fatto con moduli a 16 vie, o in ogni caso a multipli di 8, se uso HW per automazione industriale posso arrivare fino a 64 vie, quindi in meno di 50 cm ho tutto lo HW.
Solo per comandare gli scami ho bisogno di un relè, uno per scambio: servo modificati senza elettronica, alimentati in PWM (se poi veramente funziona) e tensione duale, poi rendo pubblica la soluzione se otengo i risultati che mi aspetto, anche gli scambi commerciali sono modificati.
Bisogna considerare che la vero, a prescindere dal fatto che i circuiti siano in CC o in CA i tempi di risposta dei relè elettromeccanici sono max 20 ms, ma essendo ogni circuito fine a se stesso questo tempo è nel complesso insignificante. Forse sono più lenti i tipici relè FS che lavorano solo in verticale e aprono i contati anche per peso proprio.

Tutta questa roba e il programma di gestione con una CPU specializzata (PLC) lo gestisco in meno di 5 ms (anzi forse sono già tanti, 10 ms con HW molto economico), con un PC va già bene se riesco in 1 sec: lettura e scrittura degli I/O sono compresi nei 5 ms.
Il protocollo Loconet in quelle CPU è semplice da implemetare, e poi con un locobufer o la centralina cambi il supporto fisico (gateway), il protocollo DCC è più complesso da implementare.

E come dicevo, c'è la particolarità di voler riprodurre un tipico sinottico FS di quei tempi. Solo la pulsanteria del pulpito di comando sarà diversa sia per ragioni di spazio, sia perché avere quella di fatto è quasi impossibile.


Come ho già scritto i treni non sono comandati attravervo nessun automatismo e connession con la gestione degli instradamenti, forse ma ribadisco il forse, un minimo di sicurezza per evitare collisioni se il macchinista si distrae, ma qui prima devo verificare bene i sezionamenti per via della corretta fermata di ogni singolo treno davanti al FV: treno lungo max circa 2 m, o automotrice singola.

Gestioni a tempo o sulla fiducia che il comando sia stato eseguito, manco a pensarlo, solo FB reali come al vero. Anche perché in alcune situazioni e durante la manovra degli apparati le spie di stato lampeggiano.

Insomma è una cosa che in pochi pensano di realizzare, voi per i costi, vuoi per la non reale e approfondita conoscenza della ferrovia vera: che in ogni rete/mazione è diversa.
Anche il mondo Fremo mi pare che di questi aspetti non ne tenga conto più di tanto, e anche la guida delle locomotive è prettamente manuale.

Per la logica sul PC ho rispolverato le vecchie conoscenze del C e scitto una routine banale (4I + 4O) con SO che conosco a bene, ad occhio è lenta, ma non avendo HW da testare ho solo simulato gli ingressi e verificato a video.

Tutta la documentazione relativa a DCC e Loconet la conosco, e appunto il protocollo Loconet è il più semplice da utilizzare.
Certo è che la presenza di poco HW è un limite.

Va da se che poi quanto ho in mente di fare si deve poter trasportare su altri HW e SW, con le varianti indispensabili dovute ai diversi linguaggi di programmazione.

[Luca]

Ciao Marco

ammetto di fare fatica a seguirti... parli di hw commerciale (decoder accessori Loconet) ma poi citi relay e schede industriali di I/O (che quindi penso siano "in alternativa" visto che di fatto svolgono lo stesso compito), poi PLC vs PC (anche qui immagino siano in alternativa)...

[Marco Fornaciari]

Allora , i relè servono come interfaccia per pilotare carichi a tensioni diverse, e qui ci siamo.
Per CPU si intende una qualsiasi HW che contenga un microprocessore e gli si possa caricare un SW, quindi anche un PC o un telefonino o un PLC e puere tanta srumentazione, e anche Arduino è una CPU.

Ora do più informazioni sul perchè parlo di cose che sembrano incompatibili e fuori logica.

Luca direi che ti mancano delle informazioni basiche si vari mondi dei microprocessori, dell'autoamazione in generale, e dell'informatica nota a tutti.
Di fatto la differenza tra un PLC e un PC da 35 anni sono solo le periferche collegabili e il SW che gli puoi caricare al fine di fare le gestioni necessarie all'uso ( ma se monti le schede ...): ad es. ad un PLC non serve Office, e a un PC non serve un finecorsa o una fotocellula.
Di fatto la divisione è più commerciale che tecnica, sorvolando su norme specifiche tipo direttiva macchine o/e quella nel settore dei trasporti.

Un PLC può avere come memoria di massa un HD, ormai da decenni.
Oggi esistono HW grandi come pacchetti di sigarette che svolgono entrambe le funzioni con una capacità di calcolo non immaginabile dai più, il limite in verità c'è, ma è solo ai fini commerciali tradotti in gestionali attraverso un HW non espandibile in certe direzioni.
I microprocessori all'interno sono spesso gli stessi dei PC, anche se alcuni produttori preferiscono utilizzare dei derivati customizzati e limitati.
I PLC con gli Intel 386/486 li usavo già nalla fine degli anni '80 (anzi uno dei primi con il 486 me lo hanno assemblato appositamente, la scheda madre era la stessa del 386 già pronta), così come altri marchi usavano i Motorola della famiglia 68000, e ho utilizzato anche HW con processori RISC.
Nei PLC i processori a 64 bit sono stati usati prima che nei PC per tutti.

Quindi l'uso e la coesistenza di vari HW e SW è presente da decenni, unico vincolo farli parlare assieme.
Va da se che per ragioni commerciali HW e SW per uso professionale sono spacciati diversamente per uso casalingo e ludico. Di fatto sono la stessa cosa, per bloccarne l'uso sono poi inseriti blocci HW e SW, ovvero sono riscritti con un ordine diverso della scrittura.

Nell'ambiente DCC per evitare che chiunque lo potesse replicare con il Commodor 64 fin da subito hanno fatto l'unica cosa possibile: utilizzare un valore in baud rate diverso dagli altri usi, la UART è la stessa ma con un clock diverso gestito dal firmware dell'HW di sistema, e altre cosucce secondarie.
Poi però per avere le reti sono dovuti passare dal CAN prima e dall'Ethernet in tempi più recenti, anche perchè i processori di comunicazione prodotti quelli sono.

A livello SW, fino alla fine degli anni '90 nei meri PLC si potevano inserire parti scritte in Basic o C, poi è arrivata la norma internazionale e oggi esiste un linguaggio chiamato ST (testo strutturato in italiano, e itruzioni basiche comuni a tutti i linguaggi) che poi ogni produttore inserisce nel suo SO con delle varianti, giusto per evitare il copia incolla. Anche se poi la norma dice diverso.
Nel modo DCC sono chiamati script, e Arduino li chiama diversamente, ma sempre zuppa sono.