AleCchiSi

Dalla stessa intervista, ho scoperto una cosa MOLTO interessante che non sapevo... Per i non anglofili, sul battery box a pile quadrato (quello dei treni), se si tiene premuto il pulsante verde per più di tre secondi, si disabilita l'auto spegnimento dopo due ore, così i treni possono andare avanti fino ad esaurimento pile o surriscaldamento del motore 8)

Quindi, NON porto la fattoria e porto invece il Market Street: ok dovrei starci... A questo punto, due precisazioni: Il conteggio delle baseplates comprende quelle che serviranno per coprire la mia parte di diorama. Per il resto, tutto quello che avanzo è utilizzabile da altri. Porto anche le mie strade per la mia parte di diorama? Tenete conto che sono del tipo nuovo, quindi sono diverse dalle altre.

Io ho appena contato: - 2 48x48 green - 17 32x32 green - 46 16x32 old dark grey - 21 16x32 dark bluish grey - 9 16x32 green - 7 16x32 bright green Più una decina di 8x16 green se servono da tappabuchi.

Allora io perché da bambino riuscivo a montare il plotter del Control Center in un'ora scarsa e adesso divento cretino a finire il primo piano del Grand Emporium? ??? Perlomeno una volta i colori li azzeccavano... :-X

Io ne ho sia 32x32 che 16x32, dei due verdi. Però riesco a contarle solo sabato quando torno dai miei, dove sono inscatolate. Vi aggiorno.

Direi che ti sei risposto da solo con le rilevazioni che hai fatto... Puoi sempre fare una pensilina dall'altro lato, in cui nascondere il led e la sua alimentazione.

a 3 euro a binario dritto, visto che a me se n'è già rotto uno solo tirandolo via dal brick 1x8 su cui era incastrato, direi che non si può ignorare nessuna curvatura "anomala"... Provato anche io, però preferisco rendere indipendente la direzione dello scambio dalla marcia del treno, perché diventa più facile fare modifiche dopo. Poi, per il principio di indipendenza dei moduli, questi son gusti personali Considerato che il valore della soglia viene tarato solo quando si abbassa (più luce), non c'è pericolo che se ci passa il treno davanti venga tarato sbagliato, perché il valore del sensore è più alto (di parecchio), quindi la soglia non viene modificata. No falsi positivi [EDIT] Ti dirò di più, basta stoppare il task quando il treno è fermo... [/EDIT] Inoltre l'autotaratura non è in conflitto con la taratura manuale al primo colpo. Le due cose non si escludono, anzi consolidano il sistema 8) P.S. Si vede che so informatico eh....

Beh secondo me il "modulo" è bello se ha anche un po' di decorazioni attorno, per cui sono ben accetti baseplates, fondo dei binari, catenaria, eccetera, ma lascerei il tutto alla libertà dell'autore. I vincoli da rispettare secondo me devono essere i minimi per cui il singolo ovale si "chiuda" (vedi numero di flexible track da inserire in base al numero di moduli) e perché il singolo modulo non interferisca con gli altri. A questo proposito si può inserire una lunghezza minima del raccordo tra modulo ed ovale, in termini di numero di binari dritti/curvi. Un po'come per le dimensioni del cestone del GBC.

È vero, ma così perdo meno corrente. Ho notato che se gli scambi sono entrambi "girati" ho meno resistenza sul circuito elettrico e la velocità del treno è più controllabile. Non so se è solo un problema dei miei scambi (li ho comprati tutti usati) o se la cosa sia vera in generale... La differenza principale sta nel fatto che io uso anche una soglia per la luce minima, che viene molto utile per usare i due sensori collegati sullo stesso ingresso. La tua idea comunque idea è buona, però la taratura è sempre dipendente dal resto del codice, perché è nello stesso task. Secondo me si può notevolmente migliorare, usando un task separato, che così gira in parallelo e mantiene sempre al meglio il valore di soglia per la luce. Una roba del genere: /* NOTA: La variabile di soglia deve diventare globale, perché possa essere aggiornata anche nel main task */ int light_th_upper; task sensor_tuning() { while (true) int luce=SENSOR_1; // regolazione automatica della soglia per la luce // varia con la luce ambiente e le macchine fotografiche in giro light_th_upper++; if (luce < light_th_upper) light_th_upper = luce; } task main() { /* SNIP - Inizializzazione variabili */ start sensor_tuning; /* SNIP - Codice principale stazione */ }

Io le specifiche non le sapevo, ho settato la misurazione dei sensori come SENSOR_RAW, per avere una precisione maggiore nella misura ed ha funzionato tutto...

Alura, Ho appena messo in rete un [EDIT] di un primo studio per l'Automazione Treni Modulare ItLUG (che roba altisonante!) Il "modulo" dovrebbe essere una stazione: c'è un ovale principale ed uno scambio interno, che rappresenta la stazione. Il treno fa X giri dell'ovale, dopodiché al quarto scambia verso la stazione, rallenta e si ferma. Resta in stazione Y secondi, dopodiché riparte, riaccelera e torna a fare X giri dell'ovale. Prime riflessioni sulla realizzazione del modulo: Ho usato un ovale molto piccolo, per cercare di capire come si comportava il treno in condizioni "minime" di funzionamento, per rispettare i vincoli richiesti dal modulo (vedi post precedenti, non sto a ripetermi) Come fatto già notare, per poter chiudere l'ovale ho dovuto usare due pezzi di flexible track, uno per isolare il modulo in ingresso ed un altro per "chiudere il circuito". Risultato: il modulo è isolato completamente dal resto del circuito, ma questo non crea grossi problemi se il modulo è uno solo. Bisogna però prevedere il problema nel circuito finale, se i moduli presenti non sono multipli di 4. Una soluzione ce l'ho, ma ve la illustro in un altro post. La parte di circuito che non fa parte del modulo, per il motivo di sopra, è alimentata autonomamente da un trasformatore. All'inizio del codice dell'algoritmo di controllo ho inserito una routine di "taratura" dei sensori di luce e di "reset" degli scambi. La prima permette di configurare una soglia per i due sensori, semplicemente coprendo ciascun sensore, premendo un "tasto"(touch sensor), togliendo la copertura e ri-premendo il tasto. La seconda fa girare in entrambi i sensi i motori degli scambi una volta, in modo da avere la posizione di partenza sempre predefinita. Non sono stato a testare il senso di marcia dei motori, controllo banalmente la prima volta che faccio partire la routine se li ho collegati giusti, se no giro di 90 gradi il cavetto di connessione e via andare I sensori di luce sono collegati ad una sola porta di input dell'RCX. Con un treno corto, i sensori vengono sollecitati uno alla volta (quello di prossimità alla stazione e quello di arrivo in stazione), per cui si possono controllare uno per volta e non ci sono problemi. Non ho fatto test con un treno che coprisse entrambi i sensori, ma credo che l'RCX misuri il valore del light sensor in termini di "resistenza alla luce", quindi se entrambi i sensori sono coperti, il valore dovrebbe essere più alto che se ne si copre solo uno. A questo punto, basta fare la taratura dei sensori correttamente all'inizio e i due sensori vengono rilevati nell'ordine giusto. Perché le cose siano più chiare, vi allego il codice in NQC: /* CONNESSIONI RCX : // OUT_A = circuito treno // SENSOR_1 = Stack Sensori luce // SENSOR_3 = Touch sensor (taratura) */ /* Imposta la soglia per il sensore di luce */ void set_threshold (int sensor_number, int &light_up, int &light_down) { int touch = 0; /* Soglia superiore - Meno luce*/ while (touch == false) { touch = SENSOR_3; } light_up = SENSOR_1; PlaySound(SOUND_DOUBLE_BEEP); /* Soglia Inferiore - Più luce */ touch = 0; Wait(200); while (touch == false) { touch = SENSOR_3; } light_down = SENSOR_1; PlaySound(SOUND_DOUBLE_BEEP); Wait(200); } void train_start (int speed) { SetPower(OUT_A, speed); OnFwd(OUT_A); } void train_accelerate (int &speed, int delta) { speed = speed + delta; SetPower(OUT_A,speed); } void train_decelerate (int &speed, int delta) { speed = speed - delta; SetPower(OUT_A,speed); } void train_stop () { Rev(OUT_A); Off(OUT_A); } void switch_reset() { SetPower (OUT_C,3); OnFwd (OUT_C); Wait(50); Off(OUT_C); OnRev (OUT_C); Wait (50); Off(OUT_C); } void switch_station() { SetPower (OUT_C,3); OnFwd (OUT_C); Wait(50); Off(OUT_C); } void switch_main () { SetPower (OUT_C,3); OnRev (OUT_C); Wait (50); Off(OUT_C); } int current_speed; /* Programma principale */ task main (){ /* Numero giri prima del fermo in stazione */ int round_numbers = 3; int round_counter = 0; /* Sensore 3 - tocco */ SetSensor (SENSOR_3, SENSOR_TOUCH); SetSensorMode (SENSOR_3, SENSOR_MODE_BOOL); /* Sensore 1 - Luce */ SetSensor(SENSOR_1,SENSOR_LIGHT); SetSensorMode(SENSOR_1,SENSOR_MODE_RAW); //Soglie ingresso int up_th_in; int down_th_in; //Soglie Uscita int up_th_out; int down_th_out; //Taratura soglie ingresso PlaySound (SOUND_UP); /* Controllo Soglia sensore ingresso */ set_threshold(SENSOR_1,up_th_in,down_th_in); Wait (100); PlaySound (SOUND_UP); /* Controllo soglia sensore uscita */ set_threshold(SENSOR_1,up_th_out,down_th_out); /* Reset Scambi */ switch_reset(); // Valori correnti dei sensori di luce int pre_station; int in_station; int delta_light = 5; // Modificatori velocità del treno int base_speed = 2; int current_speed = base_speed; int delta_speed = 1; Wait (100); train_start(base_speed); Wait(100); train_accelerate(base_speed,delta_speed); current_speed = base_speed; //Inizio ciclo controllo treno while (true){ //Lettura sensore ingresso pre_station = SENSOR_1; while (pre_station < (up_th_in - delta_light)) { pre_station = SENSOR_1; } // Non ho raggiunto il numero massimo di giri per entrare in stazione if (round_counter < round_numbers) { round_counter ++ ; Wait(100); } else { // Ho raggiunto il numero di giri per entrare in stazione round_counter = 0; //scambio train_decelerate(current_speed, delta_speed); switch_station(); in_station = SENSOR_1; while (in_station < (up_th_in - delta_light)) { in_station = SENSOR_1; } //Sensore_stazione - STOP treno train_stop(); Wait (500); train_start(current_speed); Wait (50); train_accelerate (current_speed, delta_speed); Wait (300); switch_main(); } } }

Potevi presentarla al creator contest, ora invece la presento io (DOH!)

Secondo te perché mi son costruito il legoPC?

Il primo è la parte superiore, senza il coperchio batterie... Il brick RCX alimentato è solo la versione 1.0.

Su questo punto bisognerebbe solo verificare una cosa: che alla fine si riesca a chiudere il circuito fisicamente, soprattutto se ci sono degli scambi in giro. Assicuro che la cosa non è da prendere sottogamba e di rileggervi l'articolo di Bill Ward riguardo la geometria dei binari... http://www.brickpile.com/track-layout-geometry/ Aggiungerei una clausa sull'"automatico". Il modulo deve essere "non bloccante", ossia non posso fare un modulo che ferma il treno e per qualche motivo non lo fa mai più ripartire. Perlomeno, se quel treno non riparte, che venga sostituito con un altro sullo stesso ovale. Es. un disaccoppiatore di vagoni So che sto facendo esempi complessi, ma se no finisce che ci ritroviamo con un ovale e venti stazioni che fanno fermare il treno per dieci secondi e lo fanno ripartire... Non mi pare molto divertente Io sto sperimentando l'uso delle luci led PF come alternativa, perché sono direzionali e in casi di illuminazione problematica "dovrebbero" essere più efficaci della lampadina.

Ma la vendi? ;D Se la vendi, mi dai anche una bicicletta col cambio shimano assieme?

Preferirei evitare di buttare motori, switch e motori di treni ad ogni esposizione

... E se invece di uno switch ne piloti due, su due trasformatori, settati uno a media velocità ed il secondo a velocità completa, nella stessa direzione? In questa maniera non si può ottenere una specie di "cambio di velocità", combinando le direzioni degli switch?

Credo che in questo aspetto vada presa a nostro uso e consumo l'esperienza del GBC: ciascuna automazione va provata e resa funzionante per proprio conto, collegandola possibilmente ad un circuito di base e vedendo come si comporta. Se resta nelle specifiche che saranno definite, va bene, qualunque sia la sua complessità. Esattamente come nel GBC, se un modulo non funziona, si scarta e si rimanda a settembre Secondo me, no, anzi... Se ciascuno alimenta la sua sezione il numero di tratti alimentati aumenta ed il circuito ha più probabilità di essere alimentato in tutti i suoi tratti senza problemi. Si deve prevedere isolamento per le sezioni solo se pensiamo di aggiungere un'alimentazione continua "esterna" alle automazioni (un trasformatore), per garantire eventualmente la corrente in tratti dove il circuito non dovesse essere raggiunto dalla corrente degli RCX. Vedi sopra... Credo tu stia parlando di BlueBrick, che si scarica qui: http://bluebrick.lswproject.com/

La seconda tutta la vita . La MOC di Kim a Cavallino ha molto da insegnare in questo senso... Forse non sono stato chiaro: il mio "quanti treni girano" va inteso in parallelo, nel senso che se vogliamo vedere tre treni girare, bisogna prevedere tre circuiti. Non che se abbiamo dieci treni da far girare dobbiamo prevedere dieci ovali Quanti treni ha la gente è indifferente, possiamo portarne anche 100 e alternarli a girare sui tre circuiti L'idea era di fare in modo di avere un certo numero di circuiti indipendenti, in modo da creare meno deragliamenti, casini, mancanze di corrente ecc. Allo stesso tempo più circuiti = più movimento = più divertimento per il pubblico! Anche qui mi son spiegato male. Mettiamola in questi termini: prevediamo di avere automazioni "a binario morto", ossia che possano essere eseguite indipendentemente dal circuito principale, vedi l'esempio della piattaforma girevole: voglio poter parcheggiare in deposito un locomotore e farne uscire un altro. È chiaro che il deposito può essere considerato un "binario morto", oppure un punto di ingresso/uscita. In questo caso, chiaramente l'ovale deve continuare a funzionare, indipendentemente dallo stato della piattaforma girevole. Non pensavo certo a circuiti a cappio, che come dici tu sono cortocircuitati per natura. Poi, se vogliamo mantenere ferma la specifica del diorama, basta prevedere che il treno in parcheggio entri sempre dallo stesso binario ed il treno di uscita esca da un altro binario, ciascuno col suo scambio di ingresso/uscita verso l'ovale di competenza.

Argh... In sostanza non è molto diverso da quello che voleva fare Pix, ma la mia versione include l'uso degli scambi. In sostanza, si tratta di far fermare il treno in una stazione, alla pressione di un pulsante (simulato da un touch sensor). Circuito di base 9V ed RCX per la parte di automazione. Il treno gira per i fatti suoi su un ovale. La stazione si trova su un secondo binario, con scambi in entrata/uscita. Quando si preme il pulsante, un light sensor controlla la posizione del treno in prossimità dello scambio di entrata. L'RCX aziona lo scambio, rallenta il treno e lo ferma sul binario della stazione non appena raggiunge un secondo light sensor. Per far ripartire il treno si ripreme il pulsante. L'RCX aziona lo scambio in uscita, fa ripartire il treno gradualmente e lo riporta sul binario principale. L'uso dello scambio anche in uscita serve a diminuire la resistenza in corrente quando il treno si trova sul binario della stazione. L'RCX non è molto potente in uscita, per cui con circuiti lunghi e/o treni pesanti le cose si fanno difficili. Uno dei motivi per cui l'integrazione non ha funzionato è proprio quello della lunghezza del circuito e della corrente coinvolta. Ciascun tratto "automatizzato" probabilmente dovrebbe essere autonomo in corrente nel tratto di binario di propria competenza, che non può essere molto lungo. Un altro problema è banalmente il fatto che l'automazione di base non era prevista inizialmente nel diorama City, che è pensato più per un display statico che per il lato ferroviario. I treni sono un compendio per far vedere qualcosa in movimento, ma non sono mai stati la vera attrazione principale del circuito. Io invece nell'ottica precedente, se vogliamo adottare 9v, proporrei una cosa leggermente diversa. Decidere quanti treni si vogliono far girare sul circuito contemporaneamente. In base al numero di treni contemporanei, prevedere un numero di ovali concentrici pari al numero di treni contemporanei. Per ciascun ovale, ciascuna automazione viene prevista come "alterazione" rispetto al circuito iniziale (anche perché si suppone che il treno faccia qualcosa di diverso rispetto al girare in tondo) Se l'automazione contiene una deviazione rispetto al circuito, debba prevedere SEMPRE un punto di ingresso ed uno di uscita verso il circuito principale. NOTA BENE: Il punto di ingresso e di uscita dell'automazione può essere lo stesso, attraverso il cambio di senso di marcia del treno. Es: una turntable che sostituisca il treno che sta girando sul circuito. Ciascuna automazione deve essere indipendente in alimentazione della propria parte di circuito coinvolta Questo è più o meno ciò che comincia a frullarmi per la testa. Sarebbe poi il caso che il "gruppo di lavoro" si riunisse una volta, davanti ad un po' di cibo e di alcool, che le idee fluiscono meglio ;D

Anche io ho questa soluzione testata e funzionante (almeno da Ballabio 2010), con tanto di scambi automatizzati. Purtroppo non riesco mai a farla lavorare a pieno alle esposizioni, perché integrandomi nel Diorama City i circuiti non sono proprietà di un'unica persona, quindi se non ci si coordina anche sull'automazione si rischia la fine di Trenitalia... 8) Propongo un gruppo di lavoro per scrivere le specifiche e mi ci butto dentro a pesce! Ci sei Rudy?

Beh se li metti su cusoo io li voto

... Questa è roba tua http://lego.cuusoo.com/ideas/view/2674

L'auto è molto carina. In dark green somiglierebbe molto ad una MG o ad una Morris Morgan. Prova a vedere se trovi i pezzi in quel colore e magari il radiatore in nero (secondo me sta meglio, non mi ricordo se quel brick esiste in chrome o silver).