Vai al contenuto
PLC Forum

Partecipa anche tu alla Live su Youtube martedì 28/01/2025 per festeggiare i 24 anni di PLC Forum

Per ulteriori informazioni leggi questa discussione: https://www.plcforum.it/f/topic/326513-28012025




Supervisione - Integrazione Tra Diverse Sedi E Diverse Tecnologie


Messaggi consigliati

Inserita:

Vediamo un pò...

Con il Modbus TCP inserisci la stringa di comando all'interno

di un frame tcp e lo spedisci sfruttando il protocollo tcp/ip.

Non saprei se è l'approccio più standard ma in automazione

moltipe comunicazioni tra master e slave lavorano

sfruttando il protocollo modbus.

Utilizzando linguaggi di alto livello si tratta di creare una

connessione tra due dispositivi e scambiare dati tra loro.

In Java il metodo di base è quello di creare una connessione

tra due dispositivi "aprendo dei sockets" e trasferire dati

tramite di essi.

Poi sono stati introdotte librerie di più alto livello che tentano

di semplificare le cose e aggiungere caratteristiche ma che

si appoggiano sempre sui sockets.

Poi si passa ai protocolli web dei quali però a noi interessa

come vengono applicati per il trasferimento di dati tra

client e server.

Allora si può usare direttamente il protocollo http e si parla

di servizi restful, oppure si utilizza Javascript e quindi inizialmente

è nato Ajax, fino ad arrivare all'html5 e i websockets attuali.

La buona notizia è che grazie a librerie già pronte in Java

tutti i tipi di comunicazione precedenti possono essere realizzate

mentre quella brutta è che per far funzionare tutto bisogna

studiarsi bene un pò di roba.

Solitamente infatti tutto fila liscio in contesti controllati poi quando si

va su applicazioni reali c'è sempre l'evento strano che ti butta

giù tutto... ne più ne meno come coi sistemi d'automazione.


  • Risposte 72
  • Created
  • Ultima risposta

Top Posters In This Topic

  • smoothhands

    30

  • del_user_56966

    24

  • Bacaezio

    11

  • Andrea Ghensi

    8

del_user_56966
Inserita:
La buona notizia è che grazie a librerie già pronte in Java

tutti i tipi di comunicazione precedenti possono essere realizzate

questo era il minimo per iniziare...

mentre quella brutta è che per far funzionare tutto bisogna

studiarsi bene un pò di roba.

e perché è brutta?

se sai programmare ti puoi fare una comunicazione ad hoc... senza appoggiarti a prodotti creati da terzi che poi in caso di problemi tutto ciò che non fai prima...

dovrai fare dopo con gli interessi.... :lol:

Inserita:
e perché è brutta?

Brutta nel senso che per diventare produttivo c'è un ovvia fase di apprendimento

che non è a tempo nullo :smile: moltiplicata per ogni tipo di tecnologia.

E come al solito sarebbe bello averle pronte per ieri.

se sai programmare ti puoi fare una comunicazione ad hoc... senza appoggiarti a prodotti creati da terzi che poi in caso di problemi tutto ciò che non fai prima...

dovrai fare dopo con gli interessi.

Bisogna ovviamente vedere di quali librerie stiamo parlando.

In generale le librerie sviluppate da terzi ti consentono di ottenere un risultato in tempi brevi anzichè sviluppare

tutto da zero. Se poi chi realizza tali librerie ha diversi sviluppatori vale il detto già visto... l'unione fa la forza.

E molto spesso più teste riescono a risolvere/considerare uno spettro più ampio di problemi.

del_user_56966
Inserita:
E molto spesso più teste riescono a risolvere/considerare uno spettro più ampio di problemi.

quando funziona è cosi.... ma a volte è l'opposto...

Inserita:

Ehhh... lo so. Troppi galli in un pollaio non funziona.

Però se lo scontro è costruttivo magari si ottengono buoni risultati.

Tornando all'integrazione, visto che partiamo da un prodotto Java,

partirei con l'usare gli strumenti nativi del linguaggio e quindi

i socket (o qualche libreria basata su socket)... poi si aggiungerà in corso d'opera.

del_user_56966
Inserita:
partirei con l'usare gli strumenti nativi del linguaggio e quindi

i socket (o qualche libreria basata su socket)... poi si aggiungerà in corso d'opera.

qualcosa su Windows c'è già, visto che con java si utilizza una VM non dovrebbero esserci grandi differenze che dici...?

Inserita:

Nessuna differenza :-) ... generalmente, dico generalmente, non ci sono

problemi ad eseguire codice tra versioni di java per piattaforme differenti.

Inserita:

Ciao ragazzi, siete fortissimi ;) le cose sono un pò più chiare, nei prossimi giorni proverò da openHab ad usare il binding modbus TCP per colloquiare il termoregolatore ST/MCT3.

Per smoothhands per il binding homePLC mi offro per un aiuto.

grazie

ciao

bacaezio

Inserita:
per il binding homePLC mi offro per un aiuto

Vi ringrazio... appena ho messo in piedi qualcosa di interessante

vi faccio un fischio. così facciamo un pò di prove :smile:

del_user_56966
Inserita:
appena ho messo in piedi qualcosa di interessante

tipo? :blink:

Inserita:

In questo momento sto mettendo a punto il generatore di eventi per un componente Java

che diventerà il core del sistema da installare sull'HomePLC.Linux.

Questo componente attualmente permette l'accesso alle istruzioni native del disposiivo

e appunto al generaore di eventi (su tutti gli 8000 registri... più o meno).

Concettualmente la mia intenzione è quella di mantenere questo componente

fisso (da qui il nome core) e dare la possibilità di aggiungere funzionalità al sistema anche

a runtime a seconda delle esigenze.

Cioè il sistema funziona a plugin e il primo plugin potrebbe essere appunto il gateway

per il collegamento con openHAB.

In questo modo chi vuole può realizzare il proprio plugin basato sui servizi forniti

dal componente core e estendere le funzionalità del sistema.

L'architettura è più o meno quella di openHAB alla fine.

Inserita:

Ciao,

sto facendo un pò prove con openHab + modbus e non riesco a leggere la temperatura da un termoregolatore MCT3 con id 30. La configurazione lato openhab del binding è la seguente:

modbus:poll=600
modbus:serial.slave1.connection=/dev/ttyUSB0:57600
modbus:serial.slave1.id=1
modbus:serial.slave1.start=0
modbus:serial.slave1.length=9
modbus:serial.slave1.type=discrete

l'item è cosi definito

Number Temp1 "Attuale [%.1f °C]" <temperature> (Temperature) {modbus="slave1:10"} (%MW11)

Dove sbaglio?

Grazie

ciao

bacaezio

del_user_56966
Inserita:

in che configurazione...?

se sei su HomePLC direttamente non serve il modbus... puoi leggere direttamente dalla memoria di Linux... :smile:

se sei remoto non devi usare il Modbus RTU ma quello TCP e prima lo devi installare e attivare... :blink:

Inserita:

modbus:serial.slave1.connection=/dev/ttyUSB0:57600

Ma cosa hai connesso sulla porta usb? :blink:

non riesco a leggere la temperatura da un termoregolatore MCT3 con id 30

Ma a cosa è collegato l'MCT3?

Inserita: (modificato)

avete ragione, ho dato per scontato molte cose.

Allora, ho la seguente configurazione, HomePLC + MCT3 + BLM1 (RS486 <-> USB), quest'ultimo è collegato al PC (linux) dove gira openHAB e ho pensato che potevo usare quest'interfaccia per poter usare MODBUS e leggere la temperatura direttamente dal MCT3. Fantascienza? devo usare per forza TCP e quindi convertitore RS485 <-> ETH ?

grazie

ciao

Bacaezio

Modificato: da Fulvio Persano
Eliminato frasi doppie
del_user_56966
Inserita:
Allora, ho la seguente configurazione, HomePLC + MCT3 + BLM1 (RS486 <-> USB), quest'ultimo è collegato al PC (linux) dove gira openHAB e ho pensato che potevo usare quest'interfaccia per poter usare MODBUS e leggere la temperatura direttamente dal MCT3. Fantascienza? devo usare per forza TCP e quindi convertitore RS485 <-> ETH ?

no semmai devi specificare che tipo di HomePLC utilizzi...

attualmente ce ne sono tre modelli che si distinguono tra HomePLC IEC1131-3 (Ladder e Functional Block)

e HomePLC.Linux che si programma tramite linguaggi tipo Java C/C++, Python ecc..

e per adesso la Lan a bordo (con TCP) è solo sulla versione Linux....

ma dato che è stata annunciata l'uscita di HomePLC 5 ARM IEC 1131-3 che ha la Lan anche nella versione Ladder/FBD... per evitare confusione meglio sempre specificare il tipo utilizzato...

da PC e embedded linux ci sono già varie applicazioni sviluppate utilizzando il Modbus RTU... quindi più che fantascienza direi che è la normalità... :smile:

Inserita:

scusate ma ancora devo prendere confidenza con le varie versioni, io sto sperimentando la version homePLC IEC1131-3 (Ladder e Functional Block)

del_user_56966
Inserita:

quel modello ha il Modbus RTU standard di serie....

quindi vai tranquillo,

dai retta...se vuoi fare esperimenti e non perder tempo...prima prova da un programma che invia stringhe Modbus in perfetto standard...

e solo in seguito al fatto che sai bene cosa viene inviato e cosa risponde il PLC provi a collegarti col software in test...

Inserita:

Come scriveva Aleandro nel 2010...

i comandi del Modbus sono standard,

il comando 01 Read Output e

il comando 02 Read Input Status gli HomePLC li implementano entrambi per la lettura a Bit (puoi usare indistintamente l'uno o l'altro..)

mentre per la lettura a Word si usa entrambi i comandi Read Output Register (03) e Read Input register (04) (puoi usare indistintamente l'uno o l'altro..)

per la scrittura a singolo Bit il comando Modbus è Force Single Coil (05) e

per la scrittura di un singolo registro devi usare Preset Single Register (06)

per le scritture multiple devi usare i comandi 15 Force Multiple Coils per la scrittura a Bit

e il 16 Preset Multiple Register per scrivere più registri in contemporanea (max 128)...

fai attenzione al fatto che scrivendo a Bit l'indirizzo massimo è 65535 quindi non puoi operare su tutti gli 8000 registri dell'HomePLC

ma solo sui primi 4096 Registri ovvero 65535 Bit...

Non dovresti avere problemi con il convertitore usb<>rs485.

Hai parlato di pc linux... vede bene il convertitore su usb?

Non ho la più pallida idea di cosa cerchi di spedire openHAB...

occorrerebbe analizzare i sorgenti e capire cosa viene generato

in base a cosa metti tra le parentesi graffe della definizione dell'item.

del_user_56966
Inserita:
Non ho la più pallida idea di cosa cerchi di spedire openHAB...

con i software che consigliavo sopra si può vedere...

Inserita:

Giusto... tra l'altro mi sa che con il binding openhab si può solo leggere.

Cercando velocemente ho trovato modpoll sul sito modbusdriver.com.

Se funziona puoi fare delle prove veloci direttamente da riga di comando.

Inserita: (modificato)

Ciao, ho appena fatto un po di prove con modpoll e sono riuscito a tirar fuori qualcosa, quello che acora mi sfugge è la questione indirizzamento dispositivo, mi spiego meglio. Per le mie prove ho colegati; homePLC, termoregolatore e convertitore, come faccio a vedere/impostare gli ID ModBUS? ad esempio con modpoll con la seguente sintassi ./modpoll -b 57600 -p none -m rtu -t 3 -a 1 -r 11 -c 10 /dev/ttyUSB0 ho il seguente otuput:

-- Polling slave... (Ctrl-C to stop)
[11]: 327
[12]: 4352
[13]: 1171
[14]: 0
[15]: 0
[16]: 0
[17]: 0
[18]: 0
[19]: 0
[20]: 0

cosa sto interrogando? l'homePLC? Termoregolatore? :wallbash:

Modificato: da Bacaezio
del_user_56966
Inserita: (modificato)
cosa sto interrogando? l'homePLC? Termoregolatore?

col Modbus RTU interroghi sempre HomePLC.... gli indirizzi dei registri vanno da 1 a 7999 e cosa trovi in questi dipende da quello che hai sull'impianto...

mentre per il resto ci sono tutte le indicazioni sull'_Help.....

fai attenzione che 1-8000 sono indirizzi fisici del protocollo...

mentre alcuni software utilizzano la dizione 10000, 20000, 40000 per specificare implicitamente il comando Modbus...

Modificato: da Aleandro2008

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 account

Accedi

Hai già un account? Accedi qui.

Accedi ora

Partecipa anche tu alla Live su Youtube martedì 28/01/2025 per festeggiare i 24 anni di PLC Forum

Per ulteriori informazioni leggi questa discussione: https://www.plcforum.it/f/topic/326513-28012025




×
×
  • Crea nuovo/a...