Railyplan - Automazione stazione nascosta

Messaggio

greenant

Bisogna pensare: "serve potere avere più persone che operano contemporaneamete sul sinottico?"
Si, se ci sono più stazioni e quindi più capistazione.
Però la cosa migliore è che ci sia 1 capo per ogni stazione e quindi il plastico è diviso in modo logico in distretti comandati ognuno da una persona.

Quindi la cosa migliore è mettere un client per regione con la sua parte di sinottico.
Ogni client poi parla col server srcp (ddw o altri).

Automatismi: ogni automatismo è legato solo ad un particolare distretto. Quindi l'insieme degli automatismi può essere diviso nello stesso modo dei sinottici. Visto che l'automatismo e il sinottico vivono in simbiosi (l'uno modifica l'altro e viceversa) la cosa migliore credo sia metterli all'interno dello stesso programma (quindi dello stesso processo --sotto windows--).

La parte script e la parte sinottico possono essere sviluppate da due gruppi indipendenti di persone, magari a mo di plugin, in modo che si possa cambiare il motore di scripting (cosa bellissima

) e quindi il principio KISS è rispettato. In comune i due moduli hanno solo il processo che li ospita.

Il mio metodo non prevede la comunicazione tra stazioni (tra distetti). Ce ne è forse bisogno? Io non mi immagino nessun tipo di comunicazione, ma se nel plastico potrebbe essercene bisogno, ditemela.

Proporrei di discutere tutto questo anche in chat (sarà la buona volta per entrarci

) ma tra qualche giorno, perchè adesso non ho tempo

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.

Esatto, l'interfaccia utente

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

Nei software esistenti sono inclusi nel client.

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

L'automatismo non prende le decisioni solo in a base agli s88 (questo lo fa gia railyplan) ma anche in base allo stato dei gli scambi.
Es: mettiamo che un treno arriva dalla piena liena e deve entrare in una stazione di transito a soli 2 binari.
1o livello di automazione. Il capostazione vede il binario libero ed instrada il treno su quello. Il sistema in automatico deve avvisare il macchinista impostando correttamente i segnali di avviso e protezione (dipende dall'itinerario).
2o livello di automazione. Il capostazione vede che c'è un treno in arrivo da un consenso all'ingresso in stazione. Il sistema da solo predispone l'itineraio libero e l'opportuna combinazione dei semafori.

IMPORTANE! L?automatismo non agisce direttamente sulla marcia dei treni!

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.

Per me un sistema leggermente + complesso di quello usato del railyplan andrebbe bene.

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

Devono interagire.

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.

Infatti è quello che dicevo l'automatismo non deve dipendere solo dallo stato degli s88 ma anche dallo stato degli scambi. I semafori sono una conseguenza dello stato degli s88 e degli scambi. Eccezzione per i semafori di partenza che cambiano stato solo con l'intervento dell'operatore.

Bisogna pensare: "serve potere avere più persone che operano contemporaneamete sul sinottico?"
Si, se ci sono più stazioni e quindi più capistazione.
Però la cosa migliore è che ci sia 1 capo per ogni stazione e quindi il plastico è diviso in modo logico in distretti comandati ognuno da una persona.

Esatto il plastico (come al vero) è suddiviso in più distretti ed ogni capostazione è responsabile dl suo. Ad ogni capostazione corrisponde un client e quindi un PC.

Quindi la cosa migliore è mettere un client per regione con la sua parte di sinottico.
Ogni client poi parla col server srcp (ddw o altri).

Automatismi: ogni automatismo è legato solo ad un particolare distretto. Quindi l'insieme degli automatismi può essere diviso nello stesso modo dei sinottici. Visto che l'automatismo e il sinottico vivono in simbiosi (l'uno modifica l'altro e viceversa) la cosa migliore credo sia metterli all'interno dello stesso programma (quindi dello stesso processo --sotto windows--).

Esatto.

Il mio metodo non prevede la comunicazione tra stazioni (tra distetti). Ce ne è forse bisogno? Io non mi immagino nessun tipo di comunicazione, ma se nel plastico potrebbe essercene bisogno, ditemela.

Si ogni distretto deve poter avvisaare quelli limitrofi dell'arivo di un treno.
Quindi c'è bisogno ho di un blocco o telefonico o telegraico o elettrico. COsi su due piedi basterebeb una chat irc

:evvai: :evvai: :evvai: :evvai: :evvai: :evvai:

Mettiamo di avere una stazione cosi:
xxxxxxxxxxxxxxxxxxxx/------d-----
|--a--|--b--S1--c--S2---T1------e-----

Dove:
a,b,c,d,e sono delle tratte
S1 semaforo di avviso
S2 semaforo di protezione
T1 scambio

Ammettendo di avvere un treno in arrivo su "a" e gestendo le sole tratte quindi gli S88 poso dire:

se "e" è libera:

T1 : corretto tracciato se "e" è libera;
in coseguenza a questo posso dire:
S1 : giallo verde se "e" è libera;
S2 : rosso verde se "e" è libera;

se "e" è occupata:

T1 : deviata se "e" è occupata e "d" libera;
in coseguenza a questo posso dire:
S1 : giallo verde se "e" è occupata e "d" libera;
S2 : rosso giallo se "e" è occupata e "d" libera;

infine:

se "e" e "d" sono occupati posso dire:

S1 : rosso se "e" è occupata e "d" è occupata;

Morale della favola (salvo qualche mio errore nell'essermi dimenticato qualche condizione) : Railyplan va bene cosi è solo più complicato fare i vari automatismi.
In caso di stazioni con più scambi e binari basta impostare le condizioni sugli itinerari invece che sui singoli scambi.
W il software..alla faccia degli analogici che per far euna cosa cosi devono pigliare diodi eporcate varie ed hanno una flessibilità alle modifiche pari a quella di una trave senza ferro.

:evvai: :evvai: :evvai: :evvai: :evvai: :evvai:

saint

Buddace: ottima architettura.

Green: 1) ti manca un'istruzione di salto. GOTO ? Il goto è considered harmful, usarlo bene richiede che "la forza scorra vigorosa in te". 2) Python è un interprete che si genera il suo bytecode 3) Un interprete Python non lo devi scrivere, lo devi linkare (quando dico che Pithon c'è intendevo questo, altrimenti proponevo il LISP di cui scrivi un interprete in un paio di settimane o meno, visto che non lo devi più fare in assembler come il primo). Le sole cose che devi scrivere sono le interfaccie che esportano verso Python quello che vuoi fare utilizzare dallo script. Anche semplice, uno scripting language efficente non è una bazzeccola, e a naso si deve rimanere efficienti.

greenant

Bud, lo stato degli scambi come lo conosci? con un finecorsa sui binari.
Il finecorsa come lo leggi? con gli s88.
Altra soluzione al problema scambi?

saint ha scritto:Buddace: ottima architettura.

Green: 1) ti manca un'istruzione di salto. GOTO ? Il goto è considered harmful, usarlo bene richiede che "la forza scorra vigorosa in te". 2) Python è un interprete che si genera il suo bytecode 3) Un interprete Python non lo devi scrivere, lo devi linkare (quando dico che Pithon c'è intendevo questo, altrimenti proponevo il LISP di cui scrivi un interprete in un paio di settimane o meno, visto che non lo devi più fare in assembler come il primo). Le sole cose che devi scrivere sono le interfaccie che esportano verso Python quello che vuoi fare utilizzare dallo script. Anche semplice, uno scripting language efficente non è una bazzeccola, e a naso si deve rimanere efficienti.

La mia idea del linguaggio di scripting era event driven.
Come in VisualBasic, quando succede qualcosa hai una procedura del tipo OnButtonclick.
Sia chiaro. A me non piace il visual basic e programmo principalmente in asm, però fare una cosa tipo SWITCH per gestire tutti i messaggi non mi piace. In una architettura event driven, il goto non serve assolutamente, semmai una CALL.

Questa è la mia idea. --------------

Gli automatismi entrano in gioco quando succede qualocosa (quindi cambia un flag). Gli oggetti che scatenano il cambiamento di un flag sono principalmente 4:
a) una locomotiva attraversa una barriera ad infrarossi, oppure un sensore ad assorbimento, oppure qualocsa di simile
b) uno scambio si scambia
c) un semaforo cambia colore
d) arriva un messaggio via telegrafo

Quindi si possono creare delle funzioni del tipo
OnSwitchChange oppure OnLightChange.

Ipotizzo il caso di Buddace

A è un sensore di passaggio.
L'utente, sul suo sinottico, clicca su A col destro e compare un menu a tendina. Tra le varie cose c'è la scelta automatismo
Gli compare un editbox con qualche fronzolo.
Inizia a scrivere nel suo editbox, che non è nientaltro che il corpo della funzione OnSomething()

Versione OOP

Codice: Seleziona tutto

IF (e.free())
{
   ti.Switch(RIGHT);
   s1.SetLight(GIALLO | VERDE);
   s2.SetLight(ROSSO | VERDE);
}
ELSE
{
   IF(d.free())
   {
      t1.switch(WRONG);
      s1.SetLight(GIALLO | VERDE);
      s1.SetLight(ROSSO | GIALLO);
   }
   ELSE
   {
      s1.SetLight(ROSSO);
   }
}

Non scrivo la versione non OOP perchè è banale.

Capito la mia idea?[/b]

saint

Capito benissimo quale è la tua idea, era una di quelle cose che sono così ovvie che ci si dimentica di specificare.

Immangino che invece tu abbia presente cosa c'è dietro l'apparente e mal riuscita semplicità di VB: Sotto sotto, nel tuo event driven, c'è una message pump (un loop da cui si esce solo col messaggio di termine) e dentro il loop un bello switch o se ti va bene un lookup tabellare.

Non è comunque detto che un semplice blocco if-then-else copra tutte le esigenze, di programmazione. Se hai bisogno di iterare una certa cosa hai bisogno di un GOTO (da buon programmatore assembler sai che si fanno solo dei salti, assoluti o relativi, sinceraemente la devo ancora vedere una architetura col ciclo while

) o di uno dei fratellini più eleganti (cicli while o repeat-until per dirla alla pascalese).

Se vuoi farti un linguaggio, liberissimo. E' una cosa formativa. Ma sinceramente lo vedo uno spreco di risorse. Meglio usarne uno già ptonto che è nato per fare quello.

O ti sei riscritto anche l'editor

(joke!) ?

Bud: quella del controllo dello stato sarebbe una cosa a favore del gestore di automatismi integrato nel client. Però io lo vedrei meglio sul server. Dove trovo la documentazione su come si parlano client e server ? Non in tedesco, per favore!

greenant

http://srcpd.sourceforge.net/srcp/index.html

greenant

Non conoscendo bene il python, ti faccio una domanda che ti potrebbe sembrare ovvia.
Come si può sfruttare il python nel nostro caso?
Potresti esporre l'esempio pratico visto con gli occhi del programmatore?
Grazie

saint · #25 Messaggio da **saint** » lunedì 24 gennaio 2005, 0:05

http://docs.python.org/ext/ext.html

Scusa se rispondo così brevemente, ma in questa pagina si parla di embedding python (anni fa, quando guardai per la prima volta il sito di python, aveva un importanza maggiore, ma adesso Python è un linguaggio che vive di vita propria, anche se l'embedding rimane.

saint · #26 Messaggio da **saint** » lunedì 24 gennaio 2005, 0:06

Dimenticavo, grazie del link.

greenant ha scritto:Bud, lo stato degli scambi come lo conosci? con un finecorsa sui binari.
Il finecorsa come lo leggi? con gli s88.
Altra soluzione al problema scambi?

Tecnicamente sarebbe più valido posizionare un contatto di retroazione sullo scambio, ma questo comporterebbe una complicazione del circuito.
Io farei una semplice stima basata sull'ultima manovra effettuata sullo scambio.

Ipotizzo il caso di Buddace

Ho sbagliato una composizione dei semafori che adesso ho corretto, correggi anche tu.

saint ha scritto:Bud: quella del controllo dello stato sarebbe una cosa a favore del gestore di automatismi integrato nel client. Però io lo vedrei meglio sul server.

Infatti è il server a controllare lo stato degli S88. Poi questo se viene interrogato credo comunichi tramite SRCP lo stato ai client .

greenant

saint ha scritto:http://docs.python.org/ext/ext.html

Scusa se rispondo così brevemente, ma in questa pagina si parla di embedding python (anni fa, quando guardai per la prima volta il sito di python, aveva un importanza maggiore, ma adesso Python è un linguaggio che vive di vita propria, anche se l'embedding rimane.

Ho letto il piccolo tutorial. Non sapevo che python avesse queste potenzialità .
Quindi,per via della modularità , credo che sia giusto scrivere un motore di scripting basato su python e che dialoghi con il client che lo ospita attraverso alcune api da definire, in modo che il client e il motore siano 2 entità logicamente separate, quindi si possono scrivere diversi client che utilizzano lo stesso motore.

greenant

saint ha scritto: Bud: quella del controllo dello stato sarebbe una cosa a favore del gestore di automatismi integrato nel client. Però io lo vedrei meglio sul server. Dove trovo la documentazione su come si parlano client e server ? Non in tedesco, per favore!

Cosa intendi per controllo dello stato?
Ricorda che il server srcp è fatto per fare solo da gateway. Ovvero prende le info (comandi) dai client srcp e le manda alla centralina, e vice versa.
Il server non prende decisioni autonome.

greenant ha scritto:
saint ha scritto: Bud: quella del controllo dello stato sarebbe una cosa a favore del gestore di automatismi integrato nel client. Però io lo vedrei meglio sul server. Dove trovo la documentazione su come si parlano client e server ? Non in tedesco, per favore!
Cosa intendi per controllo dello stato?
Ricorda che il server srcp è fatto per fare solo da gateway. Ovvero prende le info (comandi) dai client srcp e le manda alla centralina, e vice versa.
Il server non prende decisioni autonome.

Studia bus S88

Per il controllo dello stato si intende verificare se un interuttore o tratta o altro è chiuso o aperto.