Homeplc: Eventi? - HomePLC... eventi in modbus rtu come in XComm... ??

[del_user_56966]

è poi valuta il consiglio...

dato che ultimamente di Sviluppatori che si appoggiano al Framwork ABS e di applicazioni discrete che vengono fuori da questa unione...

ne stanno nascendo di molto potenti...

fare un software che abbia meno potenzialità nella gestione dei dati non è consigliabile...

prossimamente non sarà più come accade oggi che basta mettere un pulsante su qualche tablet e scambiare qualche variabile per apparire innovativi...

quello sarà anzi visto come obsolescenza...

se il tuo software non ha di base quelle potenzialità richieste dalle nuove generazioni di software per quel che vedo nasce già in difetto!...

[fiaful]

anche sniffando il protocollo (qualcuno mi diceva che ci ha provato varie volte...) il risultato è che non si riesce a comprenderne il meccanismo a fondo...

beh... non mi meraviglia... mi è già capitato in passato di dover sniffare altri tipi di protocollo (solo a scopo di debugging) ed è quasi sempre un bagno di sangue... quindi l'idea, sinceramente, non mi aveva neanche sfiorato !!

il problema nell'uso del Modbus RTU è che essendo uno standard se lo modifichi non è più il Modbus originale...

giustissimo... infatti la mia idea era quella di tenere il protocollo modbus standard (per poter continuare a colloquiare in maniera standard con gli altri eventuali plc) ed estendere (non modificare) il set dei messaggi aggiungendo i miei... in modo che la mia libreria continuasse a gestire i messaggi standard nella maniera canonica per poi, all'accorgersi di qualche messaggio diverso, trattare i nuovi messaggi secondo il *mio* standard... una sorta di modbus++ ... (modbus plus plus... ammazza come suona bene )

muahaha (risata diabolica)

per fare questo dovrei scrivere chiaramente un qualcosa sul plc che, al succedere di qualche *evento* monitorato, impacchetti un nuovo messaggio in simil-modbus e lo spari verso l'host...

prossimamente non sarà più come accade oggi che basta mettere un pulsante su qualche tablet e scambiare qualche variabile per apparire innovativi...

quello sarà anzi visto come obsolescenza...

se il tuo software non ha di base quelle potenzialità richieste dalle nuove generazioni di software per quel che vedo nasce già in difetto!...

giustissimo anche questo... infatti l'idea alla base del mio progetto è totalmente diversa (in realtà integra anche il comando manuale su tablet per ragioni di flessibilità... meglio dare *anche* qualcosa che già si conosce... ma la modalità di funzionamento di default è totalmente diversa... e forse anche innovativa ) ... ed è infatti per questo che sto tentando di fare qualcosa di diverso... e nel frattempo ne approfitto per giocare un po' (si, anche con il modbus e l'homeplc) dato che il mio modello di comunicazione è un mock che posso sostituire in qualsiasi momento con il minimo sforzo (quindi passare da un protocollo ad un altro per me non sarebbe un problema... se non quello di legarmi ad una specifica architettura - ovvero - potrei utilizzare l'homeplc solo con un host windows mentre la mia applicazione nasce cross-platform)

così, giocando giocando, avevo pensato di fare qualcosa di simile a xcomm ma basato su una piccola estensione di modbus...

se devi fare qualcosa su questi sistemi l'unica alternativa valida se ti conoscono è che ne parli col gruppo di sviluppo!....

partendo dal fatto che (ovviamente) non mi conoscono (anche perchè se mi conoscessero probabilmente mi eviterebbero )... credi che se provassi a contattarli mi darebbero udienza?

intanto ne approfitto ancora per ringraziarti del dialogo che stai perpetuando con me... dato che non sei tenuto a farlo

a presto

[del_user_56966]

anche perchè se mi conoscessero probabilmente mi eviterebbero

che fai ti rispondi da solo...

Un ipotesi valida è già in uso potrebbe essere questa...

se tu gestisci tutto puoi passare facilmente da XComm a Modbus RTU visto che su HomePLC non devi impostare nulla per farlo...

in questo caso la tua applicazione rimane multi-piattaforma e usi quello che ritieni più opportuno volta volta...

mi sembra che questo sia già in uso con Scada come Movicom dove si può alternare l'uso del Modbus RTU standard all'uso di XComm

a secondo di cosa può servire... nel caso per esempio di strutture Alberghiere nel controllo di VRV-VRF XComm essendo immediato è

perfetto... mentre se si vuole garantire uno standard di base si può scegliere il Modbus RTU..

è anche vero che un domani che molti professionisti e società di sviluppo usino XComm questo è comunque da considerare alla stregua di uno standard

dato che permette a società diverse di collaborare omogeneamente ognuna nelle proprie competenze senza per questo sapere nulla di ciò che fa l'altra...

questo è forse il modello più innovativo offerto da queste tecnologie...

[del_user_56966]

Scusa la domanda ma devi usare gli HomePLC in EN61131-3?

non puoi pensare alla nuova versione OPEN?... se sei in grado come dici tu potresti svilupparti tutto lo stack in modo performante

tramite un linguaggio ad alto livello... cosi sei libero di fare quel che vuoi no?...

[fiaful]

non puoi pensare alla nuova versione OPEN?

beh... veramente ci stavo pensando... veramente in questi giorni sto pensando a tutto e al contrario di tutto...

Inizialmente, avendo intenzione di costruire un programma di supervisione multipiattaforma che potesse funzionare indipendentemente su windows e linux (addirittura va anche su osx ) mi ero lanciato a capofitto su modbus perchè era un protocollo standard anche per altri plc, riccamente documentato e relativamente semplice da implementare... ed in effetti non ci ho messo molto a realizzare il tutto...

ammetto di aver sottovalutato ingenuamente due aspetti: la gestione di possibili eventi (a cui originariamente non avevo proprio pensato), e la compatibilità dei vari plc o almeno con homeplc (pensavo che mi sarebbe bastato sviluppare su un emulatore generico per poi fasare qualcosa al momento della messa in produzione...)

per quanto riguarda il primo, essendomi accorto "tardi" della mia carenza, ho messo in piedi la gestione del polling, costruitomi un plc virtuale sull'host allineato con quello hardware, per notificare le modifiche agli stati... funziona ma chiaramente ha dei tempi di latenza da incubo... da qui la necessità di passare ad un sistema del tipo interrupt...

per il secondo, arrivato l'accrocchio (passami l'eufemismo ) e notato che aveva diversi punti di distacco con l'emulatore che stavo utilizzando, ho deciso di introdurre nel mio software il concetto di driver del plc... mi sono scritto la mia gestione, il mio driver per l'homeplc, e adesso va nuovamente tutto anche con l'hardware... però a questo punto mi vedo a tornare sulla gestione degli eventi, questa volta da implementare all'interno del driver...

tornado alla tua domanda

non puoi pensare alla nuova versione OPEN?

e a quelle che mi sono posto io tentando di darmi delle risposte...

1. Avevo deciso di non utilizzare xcomm in quanto a. fuori dal resto del mondo e b. trattandosi di un oggetto COM è necessariamente legato al mondo windows (nella speranza un giorno di riuscire a vendere il mio sistema, mi sarebbe piaciuto non gravare sul cliente finale anche del costo della licenza di windows... pertanto riuscire a fare qualcosa che funzioni bene anche su linux era un mio pre-requisito... addirittura volevo farlo andare sulla beagleboard xm... e, non ho ancora provato, ma dovrebbe andare)... è anche vero che introdotto il concetto di driver del plc, in questo momento passare a xcomm o a qualcos'altro non mi *ucciderebbe*... ma mi comporterebbe l'abbandono del mio intento...

2. Avevo deciso di non utilizzare la versione open in quanto, secondo quello che ho capito, fuori standard... e, inoltre, non sono riuscito a capire come reperirlo e se ha un costo...

3. Avendo deciso pertanto di gettarmi a capofitto sul modbus ho spedito il mio collaboratore a partecipare all'ultimo corso sul ladderhome tenutosi a cecina i primi di dicembre per prendere lo starterkit ed iniziare a fare qualche prova reale... da cui è emerso quanto sopra e fin qui descritto

credo che adesso cambiare tecnologia passando all'open o a xcomm mi comporti (sicuramente) dover ricominciare a studiare e dover adattare diverse parti del mio codice solo al fine di renderlo compatibile con homeplc... probabilmente introducendo parti del tutto inutili con il resto del mondo (se dovesse essere necessario, ad ogni modo, non sarebbe certamente un problema, tuttavia...), e al tempo stesso credo di non essere molto lontano dalla soluzione... in quanto mi basterebbe mettere in piedi una qualche forma di comunicazione dal plc verso l'host per aver terminano la parte più onerosa della mia applicazione... (quel che rimane è tutto lo strato di alto livello dove lì, praticamente, entriamo nel campo del puro divertimento per me)

scusami se a volte non sono chiaro... non so se riesci a capire tutto quello che scrivo o quello che c'è dietro le mie parole non sapendo cosa effettivamente faccia tu nella vita... certo se fossi uno sviluppatore anche tu probabilmente sarebbe tutto più semplice... ad ogni modo se ti servono delucidazioni su quello che scrivo chiedimi pure

[del_user_56966]

Inizialmente, avendo intenzione di costruire un programma di supervisione multipiattaforma che potesse funzionare indipendentemente su windows e linux (addirittura va anche su osx smile.gif ) mi ero lanciato a capofitto su modbus perchè era un protocollo standard anche per altri plc, riccamente documentato e relativamente semplice da implementare... ed in effetti non ci ho messo molto a realizzare il tutto...

Come si dice chi troppo vuol nulla stringe

ammetto di aver sottovalutato ingenuamente due aspetti: la gestione di possibili eventi (a cui originariamente non avevo proprio pensato), e la compatibilità dei vari plc o almeno con homeplc (pensavo che mi sarebbe bastato sviluppare su un emulatore generico per poi fasare qualcosa al momento della messa in produzione...)

HomePLC non è emulabile quindi il problema è risolto all'origine... distante anni luce dai normali PLC si adatta a soluzioni dove anche il miglior

PLC Industriale dall'alto della sua potenzialità d'elaborazione al confronto sembra fa veramente molto poco...

per il secondo, arrivato l'accrocchio (passami l'eufemismo smile.gif ) e notato che aveva diversi punti di distacco con l'emulatore che stavo utilizzando, ho deciso di introdurre nel mio software il concetto di driver del plc... mi sono scritto la mia gestione, il mio driver per l'homeplc, e adesso va nuovamente tutto anche con l'hardware... però a questo punto mi vedo a tornare sulla gestione degli eventi, questa volta da implementare all'interno del driver...

Mi ricordo che anni fa ilmio pensiero era molto simile al tuo... ma da una statistica e un idea che mi sono fatto negli anni posso garantirti che software

generici come gli Scada e similari ne è pieno il mercato, programmi che hanno la pretesa di parlare con tutto e di più ma sempre in modo astratto e senza

particolari performance... anche perché è difficile che un hardware non performato per uno specifico scopo possa rendere più di altri anche nell'abbinamento

con software specialistici di supervisione... da li la mia idea di "generico" è svanita del tutto...

Oggi parlare con 100 PLC non serve a nulla se non hai l'idea di vendere per applicazioni industriali dove però hai una forte concorrenza e

in un settore che sta andando a picco!.... quindi se devi fare un investimento del genere direi che è alquanto sconsigliato...

inoltre che se ne dica ci sono già degli standard per cui neppure chi sviluppa Scada si preoccupa più di sviluppare drive appositi.... lavoro

in più cosi come costi di sviluppo e mantenimento considerevoli...

Un consiglio che mi fece poi cambiare idea del tutto fu questo...

Ma pensi davvero che il costo di una licenza Windows per l'utente finale che deve fare un Building Automation sia rilevante?

In effetti se la si vede dal lato commerciale ti assicuro che nessuno quando arriva a spendere decine migliaia di euro per fare un impianto

si preoccupa di questo... ancora meno oggi se invece di una licenza Desktop ti prendi una licenza XPe...

quindi il tuo pensiero che era anche il mio ex pensiero anche se del tutto corretto giusto è del tutto ingiustificato e fuori mercato...

1. Avevo deciso di non utilizzare xcomm in quanto a. fuori dal resto del mondo e b. trattandosi di un oggetto COM è necessariamente legato al mondo windows (nella speranza un giorno di riuscire a vendere il mio sistema, mi sarebbe piaciuto non gravare sul cliente finale anche del costo della licenza di windows... pertanto riuscire a fare qualcosa che funzioni bene anche su linux era un mio pre-requisito... addirittura volevo farlo andare sulla beagleboard xm... e, non ho ancora provato, ma dovrebbe andare)... è anche vero che introdotto il concetto di driver del plc, in questo momento passare a xcomm o a qualcos'altro non mi *ucciderebbe*... ma mi comporterebbe l'abbandono del mio intento...

Si ma vedi c'è solo un piccolo particolare il mondo dell'automazione è in Standard OLE/COM tutti i software più famosi e venduti sono basati su questa tecnologia...

il resto dei software se non per applicazioni chiuse a se e gestite direttamente dalle aziende che le propongono in realtà è come non esistesse!

credo che adesso cambiare tecnologia passando all'open o a xcomm mi comporti (sicuramente) dover ricominciare a studiare e dover adattare diverse parti del mio codice solo al fine di renderlo compatibile con homeplc... probabilmente introducendo parti del tutto inutili con il resto del mondo (se dovesse essere necessario, ad ogni modo, non sarebbe certamente un problema, tuttavia...), e al tempo stesso credo di non essere molto lontano dalla soluzione... in quanto mi basterebbe mettere in piedi una qualche forma di comunicazione dal plc verso l'host per aver terminano la parte più onerosa della mia applicazione... (quel che rimane è tutto lo strato di alto livello dove lì, praticamente, entriamo nel campo del puro divertimento per me)

cercare di essere compatibili con tutto costa sicuramente molto e non so sinceramente se fare concorrenza a software che sono gratuiti

sia molto furbo commercialmente parlando!?....

scusami se a volte non sono chiaro... non so se riesci a capire tutto quello che scrivo o quello che c'è dietro le mie parole non sapendo cosa effettivamente faccia tu nella vita... certo se fossi uno sviluppatore anche tu probabilmente sarebbe tutto più semplice... ad ogni modo se ti servono delucidazioni su quello che scrivo chiedimi pure

Come già detto in alcune scelte ci sono già passato.. e ti posso assicurare che oggi presa una decisione e dedicandomi solo a quella che

porta il miglior guadagno al minor investimento (sia economico che di tempo impiegato) sicuramente mi sembra al scelta più opportuna

per chi vuol vivere tranquillo senza dover rincorrere il mercato e dover sviluppare fino alla pensione... (che oggi è lontana lontana...)

[fiaful]

hai ragione... la pensione è sempre più lontana e lo sarà sempre di più...

mi vedi d'accordo in linea di massima con tutto quello che hai detto nell'ultimo post...

a questo punto, una valida alternativa per me potrebbe essere quello di abbandonare i miei intenti e passare a xcomm... ma mi sorge una domanda...

come se la cava con la gestione degli eventi? o meglio... quanti e quali posso gestire? facciamo un esempio quasi concreto...

mettiamo che io voglia ricevere un evento alla pressione di un interruttore... anzi... di 60 interruttori, 30 sensori di movimento, allarmi intrusione su tutte le porte e finestre, ed un altro centinaio di varie ed eventuali... riuscirei a gestirli tutti con la gestione eventi di xcomm... perchè mi sembra di aver letto che solleva solo alcuni eventi per alcuni registri... e con una certa frequenza minima altrimenti perde in performance tutto il sistema... o sbaglio?

[del_user_56966]

come se la cava con la gestione degli eventi? o meglio... quanti e quali posso gestire? facciamo un esempio quasi concreto...

XComm gestisce eventi di ogni genere, Termoregolazione, Antincendio, Controllo Accessi, Centrali Sicurezza, Logica, ricezione SMS e moltissimi altri...

per capirne di più forse dovresti aprire un form e inserendo un oggetto andare a visionare la lista degli eventi disponibile...

quello che va notato è che questi eventi non sono gestiti solo sulla macchina principale ma anche dalle postazioni remote!....

Infatti il Framework permette di sviluppare usando il Debug a codice anche in remoto come se tu fossi direttamente sull'impianto...