ma tu intendi CPU=PLC ??? se si sono decisamente sovradimensionato per il meschino compito da fare sui plastici i trenini come ad esempio le centraline automotive sono implementate con microntrollori e via...

Coi trenini non lo fanno di sicuro al 100% ... va beh anche nell'idustria ho scoperto magne nel FW, ababstanza pericolose, solo che: no! no è vero! OK ecco la dimostarzione. A si, davvero, ma no, sarà colpa del malefici del pisello ... 3 mesi dopo esce la nuova versione FW.

Esatto PLC, esistono per tutti i gusti e le tasche, è se prendi un plastico come il vostro, la CPU necessaria non costa più di un PC medio nuovo, (e non ha windows).
CPU più sceda di conversione protocollo, bastano, le perifirechie possono essere quelle del mondo dei trenini, e per comunicare con il mondo esterno le porte sono già a bordo.
Certo se poi vuoi fare il DCO ti ci vuole anche un PC o dei terminali, però il sistema funziona anche senza PC o/e terminali, volendo, fai conto di riprodurre degli ACEI telecomandati come al reale: in remoto PC, in locale pulsanteria tradizionale. Di fatto gli unici limiti sono la menoria interna o installabile, o/e la mappatura delle variabili: con una CPU medio piccola gestire 4000 I/O fisici e 65000 variabili interne di vario tipo, è normale. Con le CPU più moderne in verità a parte gli I/O fisici direttamente collegabli su bus proprietario, gli I/O remoti via rete e le variabili interne dipendono solo dalla memoria installata o installabile.
Il limite massimo, attualmente mi pare 4 GB per le CPU intel, per le Motorola non so, ma dovremmo essere lì, è per via del fatto che il pocessore indirizza direttamente fino lì, però si aggira l'ostacolo utilizzando file di archivio su memoria specifica. In effetti prima di arrivare a 4 GB di variabili ce né vuole. La memoria programma è un altra cosa, tipicamente è limitata per via di non superare i 50 ms di tempo di ciclo per una gestione ON/OFF, se devi fare degli impianti di processo, dove la maggior parte sono calcoli o/e lavorazioni lente si viaggia anche a 150 ms. Poi ci sono i limiti dei singoli processori, ma con il multitasking e un buon programmatore, il problema non esiste.

I 50 ms di tempo di ciclo, sono assimiliti ai tempi di risposta di un sistema d'automazione elettromeccanico alimentato in corrente alternata.

Mmm secondo me con un plc non riesci ne a generare dcc e nemmeno leggere il loconet troppo lento...l'xpressnet si perché è un rs485 e dovrebbe andarci a nozze

Troppo lento il loconet o il PLC: 5/6 ms per leggere ed eseguire circa 1 MB di programma (istruzioni utente circa 64 KB), compreso comunicazione con periferiche e altro (1200 I/O locali e remote, e 5 porte di comunicazione), e tutte le condizioni di sicurezza non presenti in PC o DCC, non mi pare lento: le ultime costruite dopo il 2010 sona anche più veloci.
Un PC, all'atto pratico è ben più lento e meno affidabile. Per l'occhio ed il cervello umano tempi inferiori ai 40 ns pari sono (se fosse luce sotto ai 25 Hz si vede lo sfarfallio).

Giusto per informare su cosa esite.

I vari RS sono solo il supporto fisico, il CAN è di uso normale, la ethernet ormai è in ogni dove, il 232 c'è ma ... lasciamolo perdere.
Gli integrati per la comunicazione di un PLC sono gli stessi di un PC, che magari sono gli stessi di quello delle centraline DDC, magari capita che viste le dimensioni delle apparecchiature, il tutto sia contenuto dentro un cip custom. Bisogna anche considerare che l'affidabilità richiesta alle varie categorie di prodotto è ben diversa.
Già il fatto che, spesso un PLC invia un comando una sola volta, e il DCC necessariamente in continuo, la dice lunga.
Quello che oggi esiste nei PLC solo come porta di programmazione è la USB, però con qualche decina di € si trovano dei convertori affidabili per uso industriale (che poi sono gli stessi usati nelle reti LAN di uffici e consimili), alcuni modelli li ho già usati. Da ethernet a qualcosa di altro trovi di tutto. Il protocollo, ciè le stringhe che viaggiano sono un altra cosa.
La USB, intesa come supporto fisico, per la comunicazione con apprecchiature in campo, o/e per comando e controllo, ha caratteristiche non idonee; va bene in laboratorio o per strumenti di misura portatili.
Va da se che per generare il DCC ti ci vuole la giusta interfaccia, ma non è così complicato costruirla, in definitiva ed elettricamente, è sempre un segnale bipolare come quello della 485 (o 422) a 16/18 V piuttosto che 5 V.
Poi è chiaro lato DCC hai bisogno del booster, magari uno costruito anche per leggere le CV, ma con riferimento, ad es. al comando di un motore, questa è la necessaria parte di potenza.
Alla fine in un PLC comanda il sw che è stato scritto, ciè le equazioni che il programmatore ha scritto (non dimentichiamo che tutti i sw sono di fatto un modello matematico). Nel caso del DCC il FW del decoder, contiene già del SW di logica. Caricando le CV non si fa altro che dare dei valori a delle variabili usate in equazioni non modificabili. Per questa ragione ogni uscita del decoder, motore o funzioni che sia, funziona in modo abbastanza rigido a seconda del decoder.
******
Di fatto un booster serio e completo, a mero titolo di esempio, assomiglia a un inverter, che è una scatola unica con un pò di morsetti e connettori, al suo interno è diviso in più sezioni che comunicano via bus seriale, magari ottico:
1) CPU
2) interfacce di I/O per comandi e segnalazioni
3) terminale di bordo
4) porte per comunicazione con l'esterno
5) I/O per il comando ed il controllo del motore
6) parte di potenza per il comando del motore ed la lettura dei suoi stati
7) slot per contenere ulterioni interfacce per comunicazione o funzioni spacifiche
slot per memoria di espansione per eventuale programmazione interna di funzioni.

Il PLC è lento per il loconet che per il DCC perchè devi generare fronti a 60uS in software.

Si ma questo per comandare l'uscita verso il booster.
Vedila in modo diverso, in una centrale DCC hai un processore che fa tutto lui. Questo per ragioni che esulano dalla tecnologia utilizzata, nel DCC prevale il concetto del prodotto consumer.
Nel mondo dei PC e dei PLC ci pensa il processore di comunicazione, che poi i cip nella scatola siano uno solo piuttosto che 1000, uno per tipo di periferica, non cambia nulla ai fini del risultato.
In fin dei conti il collegamento tra centale o booster, anche se è una scatola sola, è una comunicazione seriale bipolare; per questa ragione ho fatto l'esempio dell'inverter.
Con palmare e booster separati siamo +/- nelle stesse condizioni dei PLC: CPU + periefriche, non importa come fisicamente collegati e piazzati nello spazio.

In fin dei conti il primo 486 era un 386 con nello stesso involucro il matematico corrispettivo. Gli 8051 e 8052, di vecchia memoria, sono degli Z80 con dentro la RAM e alte cosucce, personalizzabili per il cliente; anche gli I/O, che, per essere di più di quelli a bordo del mP, usano un cip di multiplex per linterfacciamento con quelli fisici presenti lato utente. Poi è arrivato lo 8086. Visti da Motorola si inzia con il 68000.

Alla fine, con riferimento alle sezioni di logica e comando funzionale, comunque costruite e piazzate nello spazio, tra automazione industriale e DCC non c'è differenza. Così come sono minime le diffrenze tra tante altre apparecchiature. Nelle moderne lavatrici ci sono un motore triafase ed un inverter, magari di basso livello, così come li trovi nell'industria, sono costruiti in modo diverso.
Allo stesso modo vedi un ACC delle ferrovie reali, una CPU che comunica con tante interfacce di I/O periferiche collegate in rete, come in DCC e nell'industria. In DCC la rete sono le rotaie e qualche metro filo.

Giusto per riconoscere i diritti di quelli che si stanno rompendo le scatole.
Con Nuccio, e anche altri, stiamo verificando i diversi modi di utilizzo dei componenti elettrici ed elettronici, in funzione dello scopo finale, nonchè di evidenziare i punti in comune di realtà che, per chi non le conosce sono distanti. In realtà sono molto simili, quando non uguali, cambia solo la scatola, e possono stimolare noia o stupore a seconda delle persone.
Alla fine i forum a questo devono servire.
Chi conosce i radio comandi del modellismo dinamico, provi a guardere quelli delle gru o delle macchine operatrici da cantiere, sono la stessa cosa, norme di sicurezza e scatola a parte.
Attenzione tutti questi discorsi non devono servire nè al giudizio economico, né a quello di indirizzare le scelte di prodotto.
Si tenga presente che il prodotto consumer è fisicamete a disposizione di tutti, gli altri no, e a livello normativo non si possono incrociare gli ambienti d'impiego. Ma a casa sua e sotto la sua responsabilita ognuno è libero.

Riuscite sempre più a convincermi che la tecnologia old-time (neanche poi tanto) che ho adottato per automatizzare il mio impianto è stata una scelta assolutamente azzeccata...

All'epoca, anche delle tue conoscenze.
Oggi ragioneresti diverso, non dico che lo faresti.
Anch'io fino al 1981 la pensavo così, poi mi hanno fatto fare un corso ... già allora con i nmodesti pLC dell'epoca facevi centinaia di cose in più dell'elettromeccanica e con una semplicità sconosciuta, e per usarli non servono delle lauree, è più difficile prendere al patente.
Però, attento entrare nel mondo dei PLC è come entrare in pasticceria (evito altri paragoni troppo scontati ), rischi di scoprire realtà troppo attraenti.
Se dimostrassi ai Fremisti che possono gestire le loro schede veicolo e treno senza carta o PC? come la mettiamo?

Al SAFRE siamo in 4 + 1 appena diplomato (quasi nostro allievo), che siamo in grado di fare queste cose in un modo o nell'altro.
Per semplicità anche nei confronti degli altri, il BA è elettromeccanico con relè bistabile a due contatti: 2 €.
Mentre per il raddoppio concatenato con il BA, in ns. bravo ing., anni fa, ha usato quello che aveva gratis: un PIC con alcuni relè d'interfaccia, in elettromeccanica era troppo complesso e ingombrante (e non era gratis )
Stiamo proseguendo su questa strada, anche se per i due raddoppi della stazione abbiamo dei piccoli PLC a disposizione, sempre gratis.
In fin dei conti è un plastico passerella modulare e a osso di cane.

Diverso è il discorso che stiamo facendo per un plastico con linea a binario unico e cappi di ritorno, che andrà a riprodurre delle ex stazioni ACT (ora FER), potra funzionare anche in digitale ed in automatico. A fronte di ciò stiamo verificando come gestire il BA e i raddoppi nelle stazioni, dovrà funzionare montando da una a n stazioni infilando solo delle spine nelle prese.

Considerando il comando delle loco.
Nel modo digitale ci basta gestire i raddoppi ed il BA, in analogico occorre invertire le polarità delle tratte tra una stazione e l'altra; in elettromeccanica diventa più ingombrante la logica del plastico.

Marco, magari ci vediamo al Modelgame se confermano l'invito noi di CV19 dovremmo esserci.

Beh, se riesco a smettere di "tirare accidenti con un impianto che è impazzito" e se poi ci sei ci troviamo anche a Novegro. A Bologna c'è sicuramente più tempo, sarò lì con il plastico.
A noi hanno confermato due giorni fa.

@ marco 58

No, oggi ragiono nello stesso modo anche perché a differenza tua l'elettronica e la programmazione non sono mai stati miei campi di studio e/o di lavoro e quello che so fare di elettronica l'ho imparato sulla rivista "nuova elettronica"...



Cos'è il "raddoppio concatenato col BA" ? Non mi pare abbia fatto granchè il "bravo ing." se io che non sono ing. ho messo su questa schedina un sistema di "BA banalizzato con segnali concatenati, rilevazione di presenza ad assorbimento e alimentatore di trazione ad accelerazione e frenatura progressive e regolabili".





E' tutto da dimostrare che in questo mio pannello dove ci sono installate 35 sezioni di BA banalizzato con relativi 35 alimentatori e due impianti ACEI per un totale di 34 itinerari sia poi più ingombrante di un impianto digitale con PC, centraline, interfacce e moduli vari anche realizzati da "bravi ing."...

Veramente lo facciamo già......

ciao

Con le stesse apparecchiature che intendo io?
Alex, dammi gli articoli a catalogo del produttore che confronto.
Se intendi i tablet e consimili, sei distante come l'ultima galassia ai confini dell'universo

Anch'io l'elttronica pratica l'ho imparata lì, dopo la lettura dei due canonici mattoni del secolo scorso (se vuoi te li tiro )
Ma, attento, mi sa che stò anche convincendo Nuccio

Vedi, stai ragionando da elettrico puro, cioè, se non attacco i fili non ho fatto niente, come fanno gli elettronici puri, se non saldo ... questo ragionamento va bene se si tratta di impiantistica, o schede prototipo, ma nei casi su cui stiamo divagando qui è diverso. Si tratta di utizzare apparecchiature che da sole non servono ad un bel niente, abbinate al resto risolvono con rapidità problemi che altrimenti ti obbligano a spendere tempo per inventarti o/e costruirti "l'acqua calda".
Di diverso c'è fondamentalmente l'approccio al problema, anch'io, quando ho cominciato o così o niente, ma una volta conosciuto il "diverso" mi sono reso conto che non c'è paragone.
Vedi il banale esempio dei costi che ho fatto nell'altro tread, ho smontato in pochissime parole la tesi che fatto "all'antica " è più semplice ed economico: il rapporto è 3:1, ed è qualcosa di tecnicamente semplice.
Quando fai uno schena di cablaggio, e dopo attacchi fisicamente i fili, hai creato un modello matematico, che tra l'altro è rigido, se non va bene devi rifare schema e cablaggio, e tenere fermo il sistema durante le modifiche. Con PLC, PC, e tutto quello gli gravita attorno è completamente diverso, schemi e cablaggi li tocchi solo per ampliare l'hardware, il modello matematico è un software, che lo modifichi anche mentre il sistema sta funzionando.
In pratica scindi il sistema in tanti sottosistemi specializzati, che lavorano in sinergia con tutti gli altri, le capacità di un relè dipendo esclusivamente da quanti contatti possiede. Senza dimenticare che un relè non ti può dare i fronti e altre cose.
Alla fine sviluppare un sw è come fare uno schema, con la differenza che se sbagli non devi intervenire con la cassetta dei ferri e le matasse di filo, e magari tenere fermo il sistema per giorni perchè ti ci vuole un'apparecchiatura specifica.