Railyplan - Automazione stazione nascosta

[Buddace]

Mentre stavo scrivendo tutorial su Railyplan mi sono accorto che gli automatismi impostabili permettono di automatizzare facilmente una stazione nascosta.
Prendiamo ad esempio una satzione nascosta di testa di 4 binari. Ad ogni binario è collegato un sensore ad assorbimento e al gruppo scambi di ingresso è ce ne sta un altro. I sensori ad assorbimento sono collegati agli S88. Gli scambi sono ovviametne comandati da decoder. Ed un decoder tramite un relè può togliere corrente ad una tratta di sicurezza posta all'ingresso della stazione.
Facciamo 4 itinerari, uno per ogni binario.
Impostiamo gli automatismi cosi:

- L'itinerario verso il binario 1 si deve attivare se e solo se questo è libero.
- L'itinerario verso il binario 2 si deve attivare se e solo se questo è libero ed il binario 1 è occupato.
- L'itinerario verso il binario 3 si deve attivare se e solo se questo è libero ed il binario 1 e 2 sono occupati.
- L'itinerario verso il binario 4 si deve attivare se e solo se questo è libero ed i binari 1,2 e 3 sono occupati.
- Se i binari 1,2,3 e 4 sono occupati ed un treno è inarrivo dentro la stazione nascosta la tratta di protezione d'emergenza viene disabilitata.

Cosi come è fatto i treni devono essere fermati manualmente dentro i binari di stazione.

Per chi non ha capito un H qualche giorno di pasienza che sto preparando un tutorial su Railyprog.

[Luca]

Ciao
magari con un relè invece che togliere corrente mandi una frenata
comunque questi decoder per automatismi vanno pensati perché sono utilissimi... peccato che RailyPlan non abbia (ancora?) qualche linguaggio di script per automatizzare condizioni più complesse...
bye

[BuddaceDCC]

Ciao
magari con un relè invece che togliere corrente mandi una frenata

Visto che si tratta di una parte nascosta puoi evitare le complicazioni di un generatore di frenata.

comunque questi decoder per automatismi vanno pensati perché sono utilissimi... peccato che RailyPlan non abbia (ancora?) qualche linguaggio di script per automatizzare condizioni più complesse...
bye

Qualche programmatore del forum potrebbe ovviare alla cosa, SAINT ?

[cicocri]

Ciao
magari con un relè invece che togliere corrente mandi una frenata
comunque questi decoder per automatismi vanno pensati perché sono utilissimi... peccato che RailyPlan non abbia (ancora?) qualche linguaggio di script per automatizzare condizioni più complesse...
bye

in effetti nelle stazioni nascoste si puo fare a meno del generatore di frenata.... a meno che non la si voglia lasciare parzialmente a vista.... (per far capire come funziona il riciclo convogli)

[Luca]

Metti che poi uno si abbassa proprio per guardare come hai fatto la stazione nascosta?
Abbiamo un programmatore che si offre per fare un client migliore?
bye

[greenant]

Abbiamo un programmatore che si offre per fare un client migliore?

Servirebbe proprio. In quanto ad aspetto devo dire che i 2 sw gratuiti che conosco (railyplan e gplan) non sono molto belli. In quanto ad utilizzabilità , non lo so.

Io per ora sto facendo la mia parte
http://www.dccworld.it/forum/viewtopic.php?t=272

Se qualcuno vorrà  aiutarmi a testare le librerie, non appena saranno utilizzabili, gli sarò molto grato.
Adesso sto lavorando sulle centraline marklin

[Buddace]

Metti che poi uno si abbassa proprio per guardare come hai fatto la stazione nascosta?
Abbiamo un programmatore che si offre per fare un client migliore?
bye

[saint]

comunque questi decoder per automatismi vanno pensati perché sono utilissimi... peccato che RailyPlan non abbia (ancora?) qualche linguaggio di script per automatizzare condizioni più complesse...
bye

Qualche programmatore del forum potrebbe ovviare alla cosa, SAINT ?

Si può fare perché il codice originale del client è distribuito sotto GPL (attenti, da buon Moncaco Emacsita potrei parlare per ore sulla differenza tra libero e gratuito ) e non penso che inserire un interprete Python possa essere tanto difficile.

D'altro canto, se gli automatismi devono agire "indipendentemente" dall'interfaccia utente, allora è possibile parlare al daemon direttamente
da uno script senza che lo script venga interpretato all'interno del programma client.

Come linguaggi di scripting, visto che si deve andare a parlare con un daemon, direi Python che ha di sicuro più risorse in questo caso della vecchia cara shell.

Come programmatore ho due problemi, uno sormontabile ed uno no.
Quello sormontabile e che devo ancora iniziare col digitale, sto acquisendo informazioni.

Quello insormontabile si chiama Windows. Lo devo forzosamente usare sul lavoro e potete chiedere ai miei colleghi come apprezzi detto prodotto (non c'è un icona armata di cannoncino gatling?) .

[Luca]

Ciao!
Per quanto riguarda Windows si potrebbe pensare di fare il client in Java (Swing)... così sarebbe automaticamente anche multipiattaforma (c'è già  un software Open JPlan...)
Per il linguaggio di scripting pensavo a qualcosa di semplice, senza chiamare in causa l'ottimo Python... un linguaggio "nostro" che ti consenta facilmente di accedere allo stato dei vari sensori e di impostare delle condizioni con operatori logici un po' più complesse di quelle che ti consente ora RailPlan o altri.
Non so ad es. Windigipet etc che sistema adottano...
bye

[greenant]

Lo scopo di questo nuovo programma quale sarebbe esattamente?
Essere un sostituto completo a programmi del tipo Windigipet, railyplan e gplan, oppure solo un programma che permette, attraverso una serie di script, di automatizzare delle operazioni sul plastico?

Come linguaggi si possono usare benissimo anche python o c++ assieme a wxWindow (o comunque gtk+ che è l'unico toolkit gratutito abbastanza maturo sia su win che su linux).

[Buddace]

Io ragiono come l'utente finale (da non confodenre con utonto) e sorvolerei sulla piatatforma di programmazione da usare ma penserei più allo scopo.

Perchè ho lanciato il sasso degli automatismi ?
Come sapete tutti ormai stiamo iniziando l'avventura della costruzione di un plastico modulare completamente digitale.
La gestione che mi sono immagginato è quella che secondo me è più fedele alla realtà . Ovvero avere i macchinisti che con il proprio palmare seguono i propi treni rispettando semafori rallentamenti e quantaltro. Mentre le stazioni sono gestite manualmente tramite PC dai capistazione.
Compito di ques'tultimi è quella di dirigere il traffico ferroviario.
Fin qui niente di nuovo.
Il problema nasce quando si vuol fare questo con la tecnologia a disposizione.
Da una parte ci sono i programmi commerciali completi tipo Windigipet che offrono svariate funzionalita che però hanno la pesante limitazione di
non prevedere una logica client server. In parole povere con Windigipet et simili si può gestire un impianto stile D.C.O. ma non si può gestire in modo capillare.
Dall'altra parte ci sono i programmi stile DDW e Railyplan che grazie alla logica client-server permettono una gestione capillare. Ovvero usando un unica centrale digitale e più PC connessi tramite LAN TCP/IP ognuno può gestire singolarmente (in manuale) la propria stazione. Il problema di tutti i client è quello di offrire funzioni limitate.
Ad esempio tornando ad i nostri automatismi non è possibile impostare lo stato di un segnanle (che non vuol dire controllare in automatico una tratta) in base allo stasto degli scambi e delle tratte successive. Inoltre su nessuno sono presenti semafori di tipo italiano.

Perchè ho scritto tutto sto poema ? Perchè non avevo niente da fare...cmq qualsiasi funzione di programma o centrale digitale secondo me dovrebbe sempre essere dettata dalle propie necessità 

[Luca]

Ciao
quindi le possibili filosofie sono due:
- un programma completo che controlli tutto, sia gli automatismi sia le loco;
- sfruttare il fatto che DDW accetta più connessioni e focalizzare più programmi verso aspetti diversi (quindi uno controlla le loco, uno gli automatismi...)
In un'ottica di bidirezionalità  futura io sarei per un programma completo: in futuro gli script che ora controllano solo i decoder accessori potranno andare a controllare anche le loco (es. frena solo la loco 1 etc...)
bye

[saint]

Io muovevo Python non perché mi piaccia particolarmente, ma è nato per
fare quella cosa.

Fare un linguaggio è impossibile ma non banale, farlo bene è difficile. Python c'è già  (mai risolvere un problema già  risolto, motore primo della nascita del software libero)

Fare un solo programma ? Meglio di no, se possibile.

A me insegnarono il principio KISS (Keep It Simple Stupid) risposta che i più esperti elargiscono insieme a RTFM (Read The F(ine|ucking) Manual).

Un solo programma ha il difetto di dover fare due cose, da una parte eseguire gli script, dall'altro inseguire gli input degli utenti, oltre a diventare grosso, il che, salvo rare eccezioni, è male.

Se il primo difetto non vi è chiaro, ricordate che un programma con GUI è formato da un ciclo che preleva i messaggi giunti al programma e attiva di conseguenza le varie parti di codice preposte a reagire al messaggio. Per coloro per i quali parlo ancora un dialetto raro dell'aramaico antico: quando premete un bottone su una finestra mandate (per semplificare) il messaggio "Premuto il bottone X", al che il programma va a chiamare la parte che deve rispondere al messaggio, la esegue e poi si rimette ad attendere un messaggio.

Gestire in un programma come questo l'esecuzione di script attivati da eventi esterni alla macchina non è impossibile, ma è una noce immane oltre ad essere poco portabile tra vari sistemi.

Già  scrivere un programma che esegua degli script a comando e nel contempo lasci l'interfaccia utente pronta a riprendere ordini non è proprio la cosa più banale del pianeta.

Trovo molto sensata la questione dei capistazione e dei macchinisti di Buddace, la penso così anche io - solo che penso a robomacchinisti o robocapistazione, hanno un difetto, non sanno sparare cazzate che ti pieghino in due dal ridere come accade tra amici.

Java ha un grosso difetto, pesa, non lo porti su macchinine vecchie, ed io non ci vedo bene i forni a microonde delle ultime generazioni a gestire il plastico. Poi non ha dei problemi col fatto di essere libero, e almeno per me, per il programmi che scrivo per il mio piacere, la cosa conta.

[Buddace]

Dunque se dovssi scrivere unr pogramma da 0 (cosa che non farei mai per vari motivi) Lo struttuterei cosi:

- il Server che fa da HUB fra i vari client (TCP/IP) e pensa a dialogare con la centrale digitale.

- i client in mano ai capistazione (secondo la mia logica i teni non devono essere guitati in automatico da nessuno).

Poi strutturerei i client cosi:

- file di configurazione che contiente la definiziione del tracciato con tutti gli indirzzi sdei vari dispositivi, moduli di retroazione etc.

- interfaccia di esercizio dove è visibile una riproduzione schematica di tutto il tracciato con i vari componenti (scambi,semafori,etc) su cui il capostazione può agire.

- una parte dedicata agli atumatismi che agisce su scambi semafori e altro in base allos tato delel trate e alo stato degli scambi.

Ovviamente l'interfaccia deve aggiornare lo stato dei dispositivi. Esempio se una utomatismo mi gira uno scambio devo accorgemene sull'interfaccia grafica.

[greenant]

in questo periodo ho la mania del modulare che non è altro l'applicazione, fino a volte all'esasperazione, del principio KISS

Un buon sistema per la gestione di un plastico è diviso in 2 parti, Hardware e Software.

Trattiamo adesso il software, visto che si può usare hardware esistente.

Come software serve un sinottico che mostra lo stato del plastico, in realtime se possibile (attraverso s88).
Attraverso il sinottico è possibile anche operare direttamente su sistemi semplici come i deviatori e i semafori.

Apparecchi più complessi, come locomotive e piattaforme girevoli (e magari anche gru) normalmente hanno una loro finestra dedicata che emula un palmare hardware.

Infine c'è tutto l'automatismo, ovvero prendere decisoni in base ai feedback ricevuti dal plastico attraverso gli s88.
Quindi attivare scambi, semafori, locomotive.

Io gli automatismi li farei con un semplice linguaggio di scripting (intepretato quindi) inventato ex novo. Basta una sintassi semplice con pesante uso di IF-THEN-ELSE e operatori booleani.

Scrivere la parte di scripting in python vorrrebbe dire ricompilare tutto lo script ogni volta che si fa una modifica, quindi c'è anche bisogno di avere un compilatore python con il programma.



Il dilemma principale, secondo me, è la relazione che ci deve essere tra lo script e il sinottico.

Ovviamente lo script ha bisogno di conoscere la parte statica del sinottico, ovvero layout del plastico.
Lo script deve anche sapere però anche il colore dei semafori e lo stato dei scambi.