Bè, intanto dovrò perdere un pò di tempo ad imparare come funziona, dovrò forzatamente imparare qualcosa del C, o similari.... vorrei provare a fare lo stesso lavoro che avevo iniziato con il gruppo, trasferendo il tutto su Arduino. Inoltre ho anche qualche altra idea, sia modellistica si extra, ma non ho ancora le idee chiare, quindi... non mi sbilancio!

Tutto sommato utilizzare processori o sistemi preconfezionati è assolutamente consigliabile, anche se si tratta di oggetti complessi che controllano oggetti semplici... se si guarda il vantaggio che se ne ha in termini di risparmio di tempo, semplicità, costo (che potrebbe voler dire anche risparmio!) io non mi farei grossi problemi...

Cercando di spiegare un pò meglio le differenze tra i vari programmi, ogni microcontrollore (che differisce dal microprocessore per essere completamente autonomo, il microprocessore da solo non funzionerebbe....) funziona con un proprio linguaggio-macchina, che è costituito da un set di codici binari, a ciascuno dei quali corrisponde una certa operazione: ogni programma scaricato nel microcontrollore è composto esclusivamente da serie di operazioni, tra quelle appartenenti al set di cui sopra. L'origine di questa successione di operazioni può essere varia: essendo poco pratico scrivere direttamente questi codici binari (come scritto sopra da Stefano), sono stati 'inventati' i compilatori, a partire dall'assembler (che è di più basso livello) per arrivare ai C, C++, Visual Basic, ecc.... la differenza tra questi è che ognuno di questi 'traduce' a suo modo ciò che si vuole fare.
Nell'assembler, ogni riga di programma corrisponde ad una operazione fatta dal micro.
Gli altri compilatori traducono ciascuna riga con una serie di istruzioni-macchina, dipendente dall'efficienza del compilatore (la quale dà la possibilità di mettere in commercio compilatori con vari livelli di efficienza, a costi diversi, vedasi MPLAB XC...): si ha quindi la minima complessità del programma utente, che però si paga con una traduzione in codice macchina che spesso ha un numero di istruzioni maggiore rispetto alla stessa funzione scritta in assembler, e quindi viene eseguita in maggior tempo.
Per quanto sopra ad es., per introdurre un ritardo, mentre nei C, Basic ecc. questo è semplicemente scritto come DELAY = x, in assembler va scritto con più istruzioni che devono definire un ciclo di conteggio: questo si traduce in maggiore complessità del listato in assembler, ma dato che il risultato è sempre di 1 riga = 1 istruzione, l'efficienza è massima.

saluti

Max

Come non essere d'accordo!!!!!

Max

Nei ritagli di tempo dovrei a prepararmi a farlo anch' io.
Il processorino del mio ACEI ha una 30ina di anni e non è più in commercio da più di 20.
Il giorno in cui dovesse passare a miglior vita ... sarei disposto a pagarlo 100 Euro piuttosto che fare un sistema nuovo.

Non è che non mi divertirebbe. Ma è che il lavoro da fare sarà grande ed anche sommando i vari microsecondi liberi, non sò quando lo potrei fare.

Poi, quando succederà (penso al personaggio dello jettatore della trasmissione di Bonolis che mi dice " Come và il tuo processore ? Stà bene ?"), passerà a livello prioritario e mi toccherà farlo.

Quanto a te, Tz, non vedo vantaggi nella ricostruzione dell' ACEI.

Ma se hai voglia di lavorare, un' ideuzza te la darei.
Potresti aggiungere delle schede di I/O per acquisire con un computer la posizione di tutti gli enti del tuo plastico (CdB, deviatoi, bloccamenti, etc.).
Con un opportuno programma potresti visualizzare tutto questo e quindi, disponendo dei dati, scrivere un algoritmo di circolazione che decida momento per momento quali itinerari richiedere.
Il programma potrebbe essere scritto in Basic che come linguaggio è abbastanza intuitivo.
Il linguaggio Basic lo si può trovare in commercio in due tipi di somministrazione (come dicono i medici) :
- ci sono ditte che vendono schede proprie e che vendono anche il linguaggi Basic da applicare ad esse (p.es. la GRIFO di Bologna, ma anche altre)
- c' è il VB della Microsoft che, essendo professionale, costicchia ed ha qualche formalismo in più

A che servirebbe ? A lavorare un po'.


Stefano Minghetti

p.s. : come schede di I/O ne esistono sia RS232 (poche) sia con USB. La prima che ho trovato http://electronics-diy.com/USB_IO_Board.php a $23 potrebbe essere usata per pilotare una serie di shift registers con cui leggere lo stato. Ma ce ne sono che hanno più I/O di questa.

L'entusiasmo di pilotare trenini e accessori con sistemi computerizzati nella prospettiva di realizzare un plastico aveva assalito pure me tanti anni fa, agli albori dell'informatica "home" a metà anni '80, e (pur non avendo le conoscenze di ste.klausen21) avevo tentato anch'io esperienze con l'autocostruzione di schede e con l'allora glorioso ZX Spectrum riuscivo a comandare l'alimentatore di trazione, segnali, ingressi da reed e con semplici programmini riuscivo a realizzare qualcosa che al tempo mi entusiasmava.
La cosa funzionava, i risultati sono stati positivi ma tutto aveva il sapore di complicarsi inutilmente la vita e così 10 anni dopo quando ho iniziato effettivamente la costruzione del plastico ho optato per la più semplice logica cablata.

Quell' hardware lo conservo ancora ed è anche ancora funzionante...



Quel tipo di idea che mi suggerisci è da tempo venuta anche a me anche se tu sapresti sicuramente meglio metterla in patica.
La priorità è una sola: quella di andare al più presto in pensione per avere il tempo libero. Poi devo decidere se sfogarmi nuovamente nel rimaneggiare l'elettronica, che comunque ora è terminata e funziona regolarmente, oppure dare priorità alla realizzazione del paesaggio, ovvero terminare il plastico...

Non credo che il tuo paragone sia calzante; un qualsiasi sitema di BA (cosa di cui pressoché in ogni impianto si ha bisogno) nasce dall'esempio elementare che ho proposto.Già questa è una risposta utile: di Arduino sfrutto solo i segnali in uscita comandando tramite essi i vari dispositivi di potenza; giusto?
Il guaio, almeno per me, consiste nella programmazione effettuata ancora, sempre secondo me, in maniera poco accessibile ai non esperti del settore.
Allora, sempre con riferimento al mio schema, che riporto

dovrei fornire ad Arduino le seguenti istruzioni:
1. Se dalla tratta A non arriva alcun segnale tu non fare niente. (Il treno 2 proseguirà la sua corsa indisturbato)
1.1. Se dalla tratta A arriva un segnale (di occupato) sussistono due sottocondizioni.
1.1.1. Se dalla tratta C non arriva alcun segnale tu non fare niente.
1.1.2. Se dalla tratta C arriva un segnale allora tu emetti un segnale dall'uscita X. (Questo segnale piloterà l'alimentatore della tratta C per fargli ridurre progressivamente la tensione di alimentazione fino a zero.)
1.1.3. Se dalla tratta A, dopo che si è verificata la situazione 1.1.2., non arriva alcun segnale, tu emetti un segnale dall'uscita Y. (Questo segnale piloterà l'alimentatore della tratta C per fargli aumentare progressivamente la tensione di alimentazione fino al valore massimo impostato.)
2. Se dalla tratta B non arriva alcun segnale tu non fare niente.
Ecc., ecc. fino a chiudere il "cerchio".
Ovviamente il sistema e le istruzioni possono essere implementate per passare da impianti e tracciati elementari con tre sole tratte a situazioni ben più evolute e complesse con comando anche degli itinerari e condizioni di traffico le più svariate possibili, il tutto gestito da un solo Arduino.
Ma come tradurre tutto ciò in istruzioni per Arduino? Che tipo di Arduino (con quali potenzialità, numero di entrate/uscite) è necessario?

Continuando il discorso occorre implementare le istruzioni da fornire ad Arduino in modo che tengano conto del fatto che il treno (ad es. il 2) può marciare anche in spinta per cui la tratta A risulterà occupata (per via della captazione di corrente da parte della carrozza pilota che si trova in testa) quando la sua macchina che spinge si trova ancora nella tratta C.
Inoltre anche del fatto che pretendiamo l'arresto del treno prima e nelle immediate vicinanze del segnale.
Infine, occorre inviare ad Arduino un cavo elettrico per ogni rilevatore di presenza o possiamo servirci di un unico bus? Si può utilizzare un bus anche per le uscite?

""Ma come tradurre tutto ciò in istruzioni per Arduino? Che tipo di Arduino (con quali potenzialità, numero di entrate/uscite) è necessario?""

Per quanto ho scritto sopra credo che la minima configurazione di Arduino sia sufficiente, almeno in termini di potenzialità di calcolo: riguardo al numero di ingressi 7 uscite, basta contare ciò che si vuole mandare al controllore come segnali d'ingresso (il cui cambio di stato farà partire il controllo richiesto) e come segnali d'uscita, e verificare che i segnali necessari siano in numero minore o uguale a quello degli I/O disponibili.

Riguardo alla prima domanda, la risposta è: il listato del programma. Come ho scritto sopra, è necessario scrivere una serie di istruzioni (a cura dell'utente) che dicono al controllore di eseguire certe operazioni. Ad es. la funzione di cui al punto 1 può essere scritta così (ponendo INPUT1 come linea d'ingresso della tratta A):


(per i puristi: non conoscendo altro che l'assembler mi sono inventato alcune istruzioni comunemente scritte così... )

Nell'esempio sopra, se INPUT1=0, il sistema aspetta 50 millisecondi e poi torna ad eseguire la riga XXX: nel momento in cui INPUT1 diventa = 1 il programma esegue la riga GOTO SEQ1.1 e passa al successivo ciclo di istruzioni: nella sezione con etichetta SEQ1.1 ci saranno tutte le istruzioni necessarie ad eseguire la sequenza di ciò che intendi fare al punto 1.1. E così via... alla fine il cerchio si chiuderà con un 'salto' al punto di partenza, come hai giustamente indicato.

saluti

Max

p.s. quanto sopra va poi compilato ed inviato al controller attraverso ciò che il costruttore rende disponibile x la programmazione.

Ti ringrazio; il tuo inervento incoraggia a proseguire e studiarlo meglio (semmai ti scoccerò in MP).
E circa l'uso del bus? Sarebbe importante per ridurre il numero di cavi e collegamenti elettrici.
Se nel frattempo impari come funziona, me lo segnali in MP?

Come ho già scritto se da una parte semplifica dall'altra si tende a perdere il controllo della propria applicazione...il quale può non essere un problema sino a quando non si incontrano intoppi.
E a quel punto, per esperienza, è necessario ristudiarsi tutto da 0....e alla fine si tende a rifare tutto da 0 e non usare prelavorati

Non è proprio cosi. Se i dispositivi vuoi pilotarli con un pulsante, di arduino devi usare un pin in ingresso (a cui arrivano gli impulsi del pulsante) e un pin in uscita (che va al dispositivo).



Mai provi, mai lo saprai...perche non ti scarichi l'IDE e non provi a fare quello che ti ho detto qualche post fa? Non serve ancora arduino per questo passo.



Dovrei caprie una cosa: i segnali di presenza di treno sulle tratte vuoi inviarli tu da pulsante? Immagino di no....
Se è no, basterebbe mettere dei microswitch in ogni tratta. Se il microswitch viene attivato, vuol dire che c'è un treno; arduino lo sa e allora fai inviare automaticamente alle altre due tratte un abbassamento di tensione dell'alimentazione, a patto che ovviamente l'alimentatore sia anch'esso collegato ad (un'uscita) di arduino.

Ti trovi?

ps. ci sto ragionando con te.

Per tradurre in istruzioni, basta sapere bene cosa fare nel linguaggio "uomo". Una volta che hai ben chiaro questo, prendi un esempio di codice di arduino e inizia a giocarci in modo da tramutare il linguaggio uomo in C. Se non hai base di nulla, ti consiglio prima di tutto di capire cosa è il C:
http://it.wikipedia.org/wiki/C_%28linguaggio%29

Se riesci a capire quello che sta scritto qua, puoi iniziare!!

Infatti non ho mai pensato al rifacimento dei miei 2 ACEI anche perchè una versione programmabile non apporterebbe alcun miglioramento mentre ho sempre ipotizzato fin dal suo concepimento una sua possibile espansione, o meglio "telecomando" nell'ottica di un CTC che veda globalmente la circolazione oltre le 8 sezioni di BA limitrofe all'ACEI e gestica più fluidamente la circolazione. A tal fine ho installato subito un connettore di espansione sul quale poter inserire un scheda programmabile e già anni fa ho messo gli occhi su quelle della Grifo confidando soprattutto nell'aiuto, per la parte sw, di mio figlio che a quel tempo faceva dei programmi nel corso di informatica al Poli ma purtroppo si è sempre rifiutato di impegnarsi a... "giocare con i trenini" e oggi men che meno perchè non ha alcuna intenzione di giocare con quelli in 1/87 visto che ci deve già giocare con quelli in 1/1...
Comunque va a finire che uno di quei telaietti della Grifo con il loro ambiente di sviluppo me lo faccio e vedremo cosa riuscirò a combinarci... magari poi riesco a coinvolgerlo quando non riesco più a venirne fuori...

Cosa ha in più/meno la scheda di Grifo rispetto ad un Arduino?
(chiedo per ignoranza)

grazie...

Ho visto che sono in vendita schede di interfaccia per potenza (interfacce a relé) pronte per il collegamento con Arduino. 16 relé a circa 20 euro, indeed. Peccato solo si tratti di relé ad una sola via: a due vie sarebbe stato molto meglio.
Qualcuno le ha mai utilizzate?
La cosa è piuttosto intrigante, e l'idea di provare mi prende assai.
Esiste un simulatore di Arduino, tanto per capire se quanto ho in mente funzioni....prima di spendere, poco per poco, 60 euro?

Antonio

ciao antonio, potresti gentilmente ricordami il post a cui fai riferimento circa quello che hai in mente?

A cosa ti occorrerebbero le schede di interfaccia per potenza?

ciao!

Il modulo di potenza, ossia l'interfaccia relè, mi servirebbe a comandare i motori degli scambi e dei segnali.
Intendo realizzare un apparato centrale con serratura elettrica, liberazione ed immobilizzazione degli enti mediante arduino.

Antonio