DCCWorld.it DCCWorld.com

Ciao a tutti!

come forse sapete la NMRA (National Model Railroad Association), associazione che ha definito lo standard DCC, sta lavorando alla definizione e alla evoluzione di un bus di comunicazione per il controllo degli elementi attivi di un plastico ferroviario in digitale, chiamato LCC (Layout Command Control).

Proprio per decidere le future scelte, è stato da poco pubblicato un sondaggio aperto a tutti i modellisti che vogliano esprimere la loro opinione e le loro preferenze, vi lascio il link:
https://lp.constantcontactpages.com/sv/ ... /LCCSurvey

Sarebbe curioso capire se il sistema Lcc é usato anche qui in Italia e nel caso avere feedback in merito.
D'altronde il bus CAN é già usato da molti produttori: ESU, Zimo, Marklin e anche Roco se non erro, questo a riprova delle sua bontà.

Si va ben il CAN, ha tanti pregi (e limitazioni) e nell'automazione di ogni tipo è usato da decenni sotto varie forme per la sua affidabilità, però ...
Però ormai, a parte l'automotive e consimili per ragioni di cablaggio, per il tutto il resto si è ormai passati a sistemi basati sull'Ethernet: che bastano 4 fili come per il CAN più performante e ovviamnte l'alimentazione delle apparecchiature.
Tutto quanto non è a bordo dei veicoli può tranquillamente essere mutuato dall'automazione (come d'altra parte è già ora), se proprio insistiamo diamo all'hardware una forma esteriore diversa e cambiano un parametro per giustificare che è un sistema per giocare, ma quello è.
Nel 2021 sviluppare nuovi sistemi basati ancora sul CAN o su trasmissioni seriali limitate nelle possibilità, denota solo che chi ci lavora è rimasto alla preistoria del settore. Tra l'altro è tutto già pronto e utilizzato quotidinamente in qualche milione d'impianti da circa 15 anni.
In ogni caso per utilizzare il CAN e i suoi derivati così come per utilizzare la Ethernet bisogna partecipare ai vari consorzi e pagare le royalty.

Non penso, esiste uno standard libero chiamato CANopen sul quale é basato il LCC proprio evitare royalty.
Inoltre oggi il supporto can é ottenibile con tutti i micro e ciò permette anche agli hobbysti di sviluppare i propri moduli.

Il LCC usa un solo cavo RJ45, per alimentazione e dati, usare ethernet servirebbero un cavo per ogni dispositivo, con il can si va in chain.
Sul bus di comunicazione, invece altro mondo.

Dubito seriamente che LCC sia usato in Italia ma anche in Europa (felice di essere smentito). In America solo un paio di produttori hanno sviluppato qualcosa (ma la centrale DCC con LCC integrato ancora non si vede), mentre in Europa nulla. Tams ha da poco rilasciato la nuova centrale mc2 con tutto e di più, ma niente LCC. So solo che Digikeijs ha messo in roadmap l'intenzione di sondare il mercato sulla possibilità di supportare tale protocollo, ma la DR5000 non ha il CAN e quindi potrebbe sfruttarlo solo in WIFI (cosa prevista dallo standard LCC).

Zimo e Roco (che nella Z21 implementa il protocollo Zcan2) hanno il CAN su porta RJ45, ma i segnali CANH e CANL sono su pin diversi rispetto a quanto previsto per LCC, quindi richiederebbero un adattatore, che ovviamente servirebbe anche a ESU/Marklin e tams.

Fidax ha scritto:Non penso, esiste uno standard libero chiamato CANopen sul quale é basato il LCC proprio evitare royalty.
Inoltre oggi il supporto can é ottenibile con tutti i micro e ciò permette anche agli hobbysti di sviluppare i propri moduli.

Il LCC usa un solo cavo RJ45, per alimentazione e dati, usare ethernet servirebbero un cavo per ogni dispositivo, con il can si va in chain.
Sul bus di comunicazione, invece altro mondo.

Non esattamente, anche in Ethernet poi fare l'entra esci: c'e l'apposito integrato che fa da switch a due porte. Quindi sul cavo puoi farci viaggiare l'alimentazione per la rete, videosorveglianza docet. L''Eternet di fatto usa due coppini = 4 fili, gli altri 4 essendosi resi inutili sono rimasti per usi futuri, ma ci sono reti in Ehernet cablate a 4 fili: mi hanno fatto mangiare per gli ultimi 12 anni.
Spudoratamente nel 2021 inventarsi una nuova rete ancora basata sul CAN mi fa cadere anche i pochi capelli che mi sono rimasti.
E per i modellisti usare una rete o l'altra alla fine non cambia la quantità e la qualità delle cose da imparare/sapere, ma cambiano di tanto le prestazioni.

Sono abbastanza convinto che lo scopo del LCC non sia inventarsi qualcosa di nuovo, come giustamente avete detto le reti can nel modellismo esistono dal almeno 20 anni.
Credo piuttosto che il presupposto fosse avere uno standard libero e uniforme per tutti.
In modo tale da permettere sia ad aziende che a privati smanettoni / sviluppatori di proporre soluzioni per i plastici, con la possibilità che tutto funzioni con tutto senza essere legati ad un marchio specifico

Oddio, l'uso del CAN, piuttosto che del da sempre gratis Modbus, direi che è dovuto alla presenza di integrati già pronti all'uso e utilizzati in quell'ambito chiamato meccatronica che non è né carne né pesce e tanto meno vegetariano ...
Dal punto di vista commerciale, ogni ditta in ognio caso poi ci inserisce la solita "impostazione mal documentata, o connettore strano, che né limita l'uso ai veri esperti: gli smanettoni di solito ci riescono ma senza sapere il perchè, quindi poi fanno fatica a replicare.
In ogni caso il CAN e derivati prevedono un'architettura master-slave quindi rigida, mentre l'Ethernet e derivati permettono anche un architettura server-client quindi flessibile, vuoi mettere.

Per i cultori del CAN non sono proprio l'interlocutore adatto, ma in quasi 30 anni di frequentazione ho perso il conto delle imprecazioni.

Ciao

per darvi qualche insight in più, grazie alla partecipazione alle varie mailing list dedicate su groups.io (che sono aperte a tutti se vi interessa l'argomento!).

La NMRA si trova oggi un po' ad un "bivio" con LCC, se guardate i vari standard sono del 2016:
https://www.nmra.org/lcc

ma in effetti a parte qualche produttore (RR-CirKits in particolare), tale standard - soprattutto in Europa - è stato completamente ignorato dai produttori e anche dagli hobbisti. Uno dei motivi che si segnalano nei gruppi è che è "arrivato tardi": molti produttori avevano già da tempo realizzato proprie soluzioni per gli use cases indirizzati anche da LCC. Pensate ad esempio che la Personal Edition di Loconet è stata rilasciata nel 1997:
https://www.digitrax.com/static/apps/cm ... dition.pdf

Per questo - ed è il motivo del sondaggio - NMRA negli ultimi tempi sta cercando di capire, insieme ai vari produttori e consumatori, che futuro possa avere LCC (e OpenLCB che è il progetto "padre"). Se vi può interessare quindi far conoscere la vostra opinione è l'occasione giusta tramite quel sondaggio che vi ho linkato nel primo messaggio.

Personalmente a me piace molto l'approccio ad eventi che hanno scelto di utilizzare, è molto vicino al mondo IoT e microservices di cui mi occupo.
bye

Marco Fornaciari ha scritto: In ogni caso il CAN e derivati prevedono un'architettura master-slave quindi rigida, mentre l'Ethernet e derivati permettono anche un architettura server-client quindi flessibile, vuoi mettere.

Il can non è master slave, ma multimaster. Ed hai ben evidenziato l'univo vero aspetto positivo tranceiver e cella can praticamente disponibile anywhere. Ovviamente per un uso modellistico dubito che si andrebbero ad usare i tool professionale che uso ogni giorno con prezzo base di 20.000 €

Più che altro, il can é già usato molto spesso, non é un grande sforzo aggiungere dalle case proprietari il supporto allo standard.
D'altronde per fare un esempio il railcom plus funziona senza battere ciglio con il dcc.
Perché non aggiungere, dato che l'hardware già c'è, anche il supporto software? Sempre questione di volontà.

Esatto! Al momento dai contatti che NMRA ha avuto con i vari "big players" sembra che non vi sia interesse a supportare LCC per un mix di motivi:

- non favorire i competitors (l'adozione di uno standard "apre" il mercato)
- non "vanificare" i costi di licenza già pagati (ad esempio per realizzare dispositivi Loconet)
- non dover supportare i clienti nell'uso di un bus che sembra "compicato" (in effetti tutto il tema degli EventID non è proprio user-friendly)
- ...

visto che LCC come è ad oggi è in giro da ormai 5 anni, si cerca di capire se valga la pena rivedere qualcosa o trovare quella "killer application" che possa spingere il mercato ad adottarlo. Per come la vedo io i motivi per convincere utenti e produttori ad adottarlo non possono essere meramente tecnici perché si è visto che - a parte pochi layout davvero grandi - per le esigenze del ferromodellista "medio" sono largamente sufficienti le funzionalità offerte dai vari Loconet / xPressNet o addirittura da centraline con un paio di palmari proprietari e una interfaccia per collegarle al PC.

Fidax ha scritto:Più che altro, il can é già usato molto spesso, non é un grande sforzo aggiungere dalle case proprietari il supporto allo standard.
D'altronde per fare un esempio il railcom plus funziona senza battere ciglio con il dcc.
Perché non aggiungere, dato che l'hardware già c'è, anche il supporto software? Sempre questione di volontà.

Ehm no non è proprio cosi ... ci possono essere problemi hardware come il tipo di tranceiver e di timing relativi ai time quanta. Senza escludere che un standard di oggi CAN dovrebbe usare l'FD

Buddace ha scritto:

Fidax ha scritto:Più che altro, il can é già usato molto spesso, non é un grande sforzo aggiungere dalle case proprietari il supporto allo standard.
D'altronde per fare un esempio il railcom plus funziona senza battere ciglio con il dcc.
Perché non aggiungere, dato che l'hardware già c'è, anche il supporto software? Sempre questione di volontà.

Ehm no non è proprio cosi ... ci possono essere problemi hardware come il tipo di tranceiver e di timing relativi ai time quanta. Senza escludere che un standard di oggi CAN dovrebbe usare l'FD

Ci sono chip che supportano sia il 2.0 che il FD: https://www.microchip.com/wwwproducts/en/MCP2518FD
Come detto sopra, é la volontà che manca

Se usi l'FD non sei compatibile con l'esistente . Se qualcuno usa in fault tolerant e qualcun altro no non sei compatibile. Se ci sono bit rate diversi o a parità di bit rate time quanta diversi non sei compatibile.
Nota i tranceiver Microchip in ambiente auto professionale non sono usati.