[Sergio Bertana]

Sembra che la pagina che hai richiesto non sia esistente sul sito ed allora ti viene ritornata una pagina di errore che probabilmente è molto più lunga della dimensione dei buffers da te stabiliti. Ho corretto il FB, ora vengono ignorati i caratteri che eccedono la dimensione del buffer stabilito. Prova ad eseguire il download della libreria, il link del post precedente ora punta la nuova versione.

[Sergio Bertana]

Il Modbus RTU prevede un solo sistema master, quindi per la tua soluzione opterei per avere il pannello operatore master che scrive/legge dai due moduli CPU, che operano come slave. Per il passaggio dati da uno SlimLine all’altro puoi utilizzare l’oggetto Data Transfer sul pannello che permette di trasferire su comando (Trigger) o a tempo (Ciclico), dati da un sistema slave all’altro.

Naturalmente l’utilizzo del FB ModbusMaster sullo SlimLine per lo scambio dati è più veloce rispetto al Data Transfer da terminale (Che anche se impostabile a 200 mS credo sia difficile scendere sotto i 500 mS), ma se non hai particolari problemi di velocità l’utilizzo del Data Transfer è molto più semplice.

In alternativa uno degli SlimLine agisce da Modbus master e scambia dati con l’altro e con il terminale che agisce come slave Modbus (Topic). Utilizzare il terminale come slave è comunque più complesso rispetto alla classica configurazione master.

Riguardo alle ricette, è possibile caricare ricette da Pen Drive e/o SDCard dierettamente dal terminale, non è possibile utilizzare quella dello SlimLine (Topic, topic).

[Sergio Bertana]

La famiglia SlimLine viene offerta sia in versione LogicLab che CODESYS, a livello di caratteristiche funzionali i due tipi di prodotto sono equivalenti e condividono gli stessi moduli di estensione. Il modulo CPU della versione CODESYS è leggermente più costoso a causa delle royalties dell’ambiente di sviluppo.

Entrambi gli ambienti di sviluppo sono IEC-61131 compliant e supportano i 5 linguaggi della normativa. Per la gestione delle logiche di automazione è possibile realizzare logiche in LD (Ladder Diagram) e/o a piacere utilizzare qualsiasi altro linguaggio IL, FBD, ST o SFC. Per la comunicazione è disponibile il protocollo Modbus si RTU su seriale che TCP/IP su poprta ethernet.

Come hai giustamente fatto notare per l’interfaccia Uomo/Macchina si può utilizzare un qualsiasi modello dei ns terminali operatore Touch screen. Il modulo CPU CODESYS dispone anche della visualizzazione grafica WebVisu (Topic, Screenshot).

Il datalogging può essere effettuato sia dal terminale operatore (Topic), che memorizzando un file formato CSV direttamente sul modulo CPU (Topic, topic). Il file potrà poi essere scaricato con una connessione FTP.

[Sergio Bertana]

Se si vuole mantenere esattamente uguale la gestione l’unico modo è di creare una VPN tra la Modem Machine ed il tuo server, per fare questo puoi utilizzare un router Conel (Topic). In questo modo la VPN si comporta come un cavo di rete tra i due punti e puoi utilizzare la tecnica dello scambio di messaggi UDP.

Il router Conel alla accensione crea la VPN, naturalmente devi disporre sul tuo sito server di un indirizzo IP pubblico, la VPN può essere creata tra il router Conel ed il tuo router ADSL di acceso Internet, oppure puoi utilizzare un client VPN su PC (Esistono client gratuiti sia OpenVPN che IPSec).

Questa soluzione però prevede come ovvio l’aggiunta di un router oltre al modem, e devi utilizzare due SIM, una sul modem per la gestione delle chiamate ed una sul router per la VPN.

In alternativa è possibile modificare la gestione utilizzando il solo modem, in questo caso avresti anche una sola SIM, ma occorre fare modifiche sia lato Modem Machine che lato server. Il modem effetua una connessione HTTP verso il server chiedendo la pagina e passando in GET il comando (Heartbeat o numero telefono). Il server deve agire come server web ritornando una pagina web con con il comando verso il modem (Heartbeat , Denied o Allowed). In questo topic trattiamo una soluzione simile.

Occorre tenere presente che la connessione HTTP via modem richiede un certo tempo (da 20 a 60 Sec) ed in questo tempo il modem risulta cieco alle chiamate telefoniche. Questo non sarebbe un problema sulla attivazione dell’apertura perchè la chiamata sarebbe già ricevuta, ma potrebbe fare perdere chiamate sulla gestione dell’Heartbeat.

[Sergio Bertana]

Se la pagina richiesta è più grande della dimensione del buffer di pagina PBuffer si incorre in un bug del FB, ho provveduto a correggere l’errore. Ecco la libreria con la versione corretta del FB (Download HTTPGetPage.pll).

Ho provveduto successivamente anche a correggere il programma del post precedente che ora utilizza questa versione del FB.

[Sergio Bertana]

Quindi mi sembra di capire che ora il modulo si connette alla rete WiFi ed il server DHCP gli assegna un indirizzo, è così ?
L’indirizzo IP assegnato è coerente con la classe di indirizzi della tua rete ?
Il PC da cui effettui il Ping è connesso alla stessa rete ?

[Sergio Bertana]

E’ sicuramente possibile aumentare il numero di POU gestibili, basta definire il nuovo valore nelle impostazioni del target (Screenshot). Unica accortezza come indicato nel post precedente è non superare il limite di memoria disponibile. Quindi se aumenti il numero di POU devi diminuire l’area di memoria (Ti consiglio di ridurre l’area di memoria globale). Ricorda come già detto precedentemente che ogni POU necessita di 12 bytes di memoria.

Quindi se aumenti di 1536 il numero di POU portandolo a 2048, dovrai ridurre di 18432 bytes l’area di memoria globale.

[Sergio Bertana]

Ecco lo screenshot di un test eseguito con Modscan. Il protocollo Modbus TCP è diverso dal Modbus RTU, ma utilizzando Modscan se lo imposti per modbus TCP sicuramente genera la trama corretta. Piuttosto hai impostato correttamente gli altri parametri:

Indirizzo di nodo Modbus deve essere 1.
Hai eseguito un comando 16#03 Read Holding Register ?
Che  indirizzo di registro hai usato (Devi usare indirizzi nel range da 40000 a 42047).

[Sergio Bertana]

Le operazioni di associazione alla rete sono quelle descritte nel topic.

Hai verificato che la crittografia utilizzata nella tua rete sia gestita dal convertitore, hai impostato correttamente il comando setet ?
La password di crittografia è molto lunga od ha spazi al suo interno ?
Prova a generare una rete WiFi con il tuo telefono (Hot spot WiFi) e prova a connetterti cosi verifichi se funziona.

[Sergio Bertana]

Come dicevo nel post precedente l’applicazione è nata per permettere di avere una interfaccia web sulla gestione del modem da parte del FB ModemCore. Poi abbiamo dato una configurabilità minima gestendo i 6 ingressi e le 4 uscite di un Modulo CPU compact con invio e ricezione di messaggi programmabili direttamente dalla pagina web.Ma la libreria eModemLib offre FB sia per la ricezione che l’invio di SMS, naturalmente va modificato il programma standard della Modem machine tramite LogicLab per adattarlo alle proprie necessità. Non vi è sicuramente problema a gestire 24 outputs, dovrai solo aggiungere un modulo di espansione a relè.

[Sergio Bertana]

Hai colto l’essenza di quello che si vuole offrire con l’utilizzo della funzione SysI2CWrRd, la funzione offre proprio la possibilità di gestire dal modulo CPU dei proprii moduli di I/O. Questo permette di sfruttare tutte le potenzialità offerte dall’ambiente di sviluppo LogicLab e/o CODESYS e dalle librerie da noi fornite su di un hardware costruito sulle esigenze del Cliente abbattendo i costi.

In merito al limite sul numero di bytes da scambiare è un problema solo legato al tempo di scambio che se i bytes sono molti provoca dei jitters sulla esecuzione delle tasks in interrupt (Task Fast e Slow). Ma è comunque possibile  frazionare i comandi, così ads esempio se devo gestire una memoria I2C anche da 1 Mb basterà scrivere/leggere i dati a blocchi di 10 bytes alla volta in modoi da permettere all’interupt di “entrare” tra una gestione è l’altra.

In pratica la funzione SysI2CWrRd è atomica, quindi ad  esempio se operasse su 100 bytes consecutivi fino a quando non ha terminato le tasks Fast e Slow sono bloccate (In questo topic trovi ulteriori informazioni).

[Sergio Bertana]

La risposta è articolata, intanto partiamo dal presupposto di avere una connettività Internet in entrambe le abitazioni (Nel caso non fosse disponibile una connessione ADSL o WiFi si può utilizzare un router GSM/UMTS). Se si dispone di indirizzi IP pubblici (Anche dinamici, Topic) è possibile pensare ad un dialogo tra i sistemi SlimLine utilizzando il protocollo Modbus.

Attualmente non disponendo della connessione TCP client sugli SlimLine LogicLab, bisogna appoggiarsi ad un convertitore Ethernet-Seriale come indicato in questo topic. In alterenativa si può utilizzare lo SlimLine CODESYS.

Un FB ModbusMaster sullo SlimLine di Genova dialoga via Internet con lo SlimLine di Aosta e tutti i dati sono riportati poi sul pannello operatore connesso. Se il pannello operatore è pubblicato su Internet tramite una applicazione VNC è possibile accedervi anche da smartphone (Topic).

Se non si ha la disponibilità di IP pubblici occorre operare in una configurazione cloud, tutti gli impianti domotici si connettono ad un server nel cloud ed è il server a creare l’interscambio dei dati tra le varie abitazioni. Il server sul cloud potrà anche pubblicare pagine web consultabili anche dallo smartphone (In questo topic una soluzione simile).

[Sergio Bertana]

Il bus I2C è uno standard ben definito, non si può inventare. Il primo byte inviato dopo il bit di start start è proprio composto da 7 bits di indirizzo (Infatti il range dell’indirizzo è compreso tra 16#00 e 16#7F) e da un bit che identifica il comando di read (Bit a 1) o write (Bit a 0).

[Sergio Bertana]

Il bus I2C dei sistemi SlimLine e NetlogIII opera a 400Khz. La funzione SysI2CWrRd ha questi parametri:

Address (USINT) Indirizzo dispositivo I2C (Range da 16#00 a 16#7F).
WrBytes (USINT) Numero di bytes dati da scrivere. 0 se solo lettura.
WrBuffer (@USINT) Indirizzo buffer memoria che contiene i dati da scrivere. NULL se solo lettura.
RdBytes (USINT) Numero di bytes dati da leggere. 0 se solo scrittura.
RdBuffer (@USINT) Indirizzo buffer memorizzazione dati letti. NULL se solo scrittura.

Il frame I2C si compone di due sequenze eseguite una di seguito all’altra.

Se definiti dati da scrivere (WrBytes <> 0, WrBuffer <> NULL), inizia con start seguito da indirizzo I2C (Address), comando di write poi sono scritti tutti i bytes ed infine stop.

Se definiti dati da leggere (RdBytes <> 0, RdBuffer <> NULL), inizia con start seguito da indirizzo I2C (Address), comando di read poi sono letti tutti i bytes ed infine stop.

In merito alla composizione dei comandi I2C tu ti riferisci ai nostri comandi proprietari di gestione moduli di espansione che hanno un CRC per verificare la correttezza dei dati. Ma tu puoi utilizzare i comandi che desideri, in base al componente hardware da gestire. Discorso a parte sulla lunghezza dei dati da gestire in scrittura/lettura, noi consigliamo di tenere frame non più lunghi di una decina di bytes in totale questo per evitare jitters sulla esecuzione delle tasks (Vedi ulteriori informazioni in questo topic).

[Sergio Bertana]

Come vedi nei posts precedenti la Modem Machine è un laboratorio, il prodotto è programmabile tramite LogicLab. Se dai una occhiata alla stampa del programma, vedrai che la gestione degli I/O è realizzata in linguaggio ladder e quindi è completamente modificabile per adattarla alle tue necessità.

Il programma utilizza il FB ModemCore per la gestione del modem e come troverai in altri topic collegando alla ModemCore altri FB puoi cimentarti in applicazioni più ardite ed ampliare il progetto come desideri (Topic). Utilizzando come linguaggio di programmazione l’ST (Structured Text) puoi estendere ulteriormente le applicazioni (Topic).

[Autore]

Post