del_user_56966 Inserita: 29 agosto 2014 Segnala Inserita: 29 agosto 2014 capire se vi è la possibilità di raddoppiare la logica di funzionamento del plc con una versione che giri su un sistema linux che già gestisce altri servizi. intendi il Modbus RTU sulla porta di comunicazione dell'HomePLC Ladder..? quella porta è di supervisione.... e utilizza una comunicazione al massimo a 115.2 bps... il modbus RTU per tu quanto possa andare veloce rimane un protocollo di supervisione se devi usare molteplici registri non sarà mai RealTime... al contrario sulla versione HomePLC.Linux se utilizzi la libreria Modbus TCP tramite la LAN ottieni sicuramente velocità molto più elevate... l'accesso ai registri sia dal Modbus TCP che da Java è immediato proprio perché l'accesso ai registri XComm è integrato sul kernel del Linux quindi non c'è nessun altro tipo di comunicazione o altro da implementare...
del_user_56966 Inserita: 29 agosto 2014 Segnala Inserita: 29 agosto 2014 l'HomePLC.linux si può sostituire completamente all'HomePLC ladder (nell'architettura generale del sistema) o bisogna affiancarlo? HomePLC Linux è come un HomePLC Ladder senza il processore PLCche viene sostituito da quello Linux... in pratica tramite Java, PHP, C++, Python, ecc.. ottieni le stesse perfomance su Bus di un HomePLC... nessun altro embedded Linux può ottenere queste velocità di elaborazione proprio perché non dipendono solo dalla CPU Linux.. ma anche dalla CPU Domotica, dal protocollo XComm che è RealTime e dall'hardware in campo...
smoothhands Inserita: 29 agosto 2014 Autore Segnala Inserita: 29 agosto 2014 (modificato) L'accesso ai registri XComm, per quanto riguarda Java, non è proprio integrato nel kernel linux. Ad essere proprio pignoli, la libreria standard a corredo, non è altro che una libreria dinamica (file .so) scritta in c che implementa alcune funzioni di accesso ai registri del processore domotico. Per essere ancora più pignoli va fatto notare che la classe java standard con i metodi nativi di interfaccia è stata compilata nello default package e quindi l'unico modo per utilizzarla è sbattere tutta la mia logica di controllo sempre nel default package. Così facendo si vincola molto la struttura del software sviluppato. Purtroppo questa è una finezza da programmatori Java ma prendetela così. In realtà un barbatrucco per svincolarsi da questa situazione c'è ma implica l'utilizzo della reflection (scusate ma è un altro termine del mondo Java) che non sempre è ben visto dai puristi Java ma che in questo caso a me ha aiutato. La lentezza eventualmente è da ricercare in tutto quello che accade tra la lettura dei registri e la successiva riscrittura. Se catturo l'attivazione di un input e la decisione di cosa comandare in output la faccio prendere a un server che sta in un'altra parte del mondo collegata al mio HomePLC.Linux via lan, passando da una vpn, magari con una logica scritta in un altro linguaggio (differente da Java) che però è vincolata dal verificarsi di un evento ricavato tramite interrogazione di web service ulteriore e che trasmette la sua istruzione tramite json e che quindi ne va fatto il parsing, etc. etc. etc. Leggere e scrivere i registri, anche da Java, è un attimo... è quello che viene messo in mezzo che potrebbe rallentare rispetto alla logica microprogrammata del PLC. Ma vogliamo mettere la flessibilità che se ne ottiene :-) Modificato: 29 agosto 2014 da smoothhands
Bacaezio Inserita: 11 settembre 2014 Segnala Inserita: 11 settembre 2014 Ciao tutti, eccomi qui...purtroppo ferie finite...vedo con grande piacere che la questione openHab/HomePLC è andata avanti e che smoothhands durante le ferie si è divertito io invece purtroppo ho dovuto abbandonare le varie prove per lavori urgenti ed impegnativi, ma sono pronto a ripartire...
Messaggi consigliati
Crea un account o accedi per commentare
Devi essere un utente per poter lasciare un commento
Crea un account
Registrati per un nuovo account nella nostra comunità. è facile!
Registra un nuovo accountAccedi
Hai già un account? Accedi qui.
Accedi ora