BuddaceDCC ha scritto:
marco_58 ha scritto:
Quello che, ora, non riesci a capire, è che non serve riconoscere il treno, ma un treno.
Esattamente il contrario, per fare una fermata come si deve, serve riconoscere esattamente il treno, per mandargli i giusti comandi di velocità e fermata. E' la strategia che usano i pc appoggiandosi alla retroazione tradizionale, che data una posizione iniziale, seguendo le occupazioni e gli itinerari possono seguire i treni quindi individuarli per fermarli al punto giusto.
Il lissy o il railcom invece non hanno bisogno di seguirli in quando sono in grado di riconoscere i treni
Mi hai frainteso.
Per il BA non interessa il treno XY con loco ZW, ma un treno anonimo che è entrato sulla tratta, ho già detto in diservi interveni anche sull'altro tread, che è importante il punto nel quale riconoscere il treno. Come lo riconoschi non ha importanza ai fini del funzionamento. Al PC/centralina non interessa quale tipo di sensore usi, lui riconosce solo gli stati 0-1 dell'ingresso digitale, sei tu che sai cosa significa, e che quindi programmi tutto il sistema per fargli fare quello che ti pare.
Poi siccome comanda il decoder, la programnmazione del medesimo sarà in funzione di: treno lento = tempo di decelerazione lungo, treno veloce = tempo di decelerazione corto, ma questa è una considerazione diversa dal mero funzionamento del BA. Come al reale non comanda la loco ma la categoria del treno, quindi a treno diverso diversa programmazione del decoder.
... Beh, ci sono anche i sistemi che posso programamre i decoder con loco in corsa.
Completamente diverso il discorso, se al PC fai fare anche tutto il lavoro del machinista.
Le sequenze di oggetti, trasportare da qualsiasi sistema di trasporti meccanici, e con qualsiai lay-out, negli impianti industriali, e non riconosciute da bar code o da RFID, sono una delle mie specialità.
Pari pari come sarebbe su un plastico.