[Sergio Bertana]

Non abbiamo prodotti specifici per gestire I/O in WiFi, ma abbinando un modulo CPU Compact Eth. ARM7 ad un access point WiFi, è possibile realizzare quello di cui necessiti ad un costo competitivo.
 
Il modulo CPU è un PLC e quindi oltre a svolgere la funzione di remote I/O può anche essere programmato per fargli svolgere compiti autonomi. Ad esempio può eseguire un conteggio sugli ingressi o prolungare la durata dello stato degli ingressi per dare tempo al PLC centrale di acquisirne lo stato.
 
Nelle due stazioni con un maggiore numero di I/O puoi collegare al modulo CPU dei moduli di espansione I/O per raggiungere il numero di ingressi ed uscite che ti servono.

[Sergio Bertana]

Siccome al bus di estensione del modulo CPU possono essere connessi 16 moduli (Indirizzi da 0 a 15) , gli I/O del modulo CPU sono indirizzati con indirizzo di modulo 255. Quindi se utilizzi la mappatura in immagine di processo devi mappare gli ingressi come %IX255.0, %IX255.1, … e le uscite come %QX255.0, %QX255.1, … Se gestisci gli I/O direttamente con i blocchi funzioni relativi devi definire indirizzo di modulo 255.

Attenzione, Questa regola non vale per i moduli CPU NetlogIII, in quel caso gli I/O del modulo CPU sono mappati ad indirizzo 0.

Il motivo di questa differenza è che il modulo NetlogIII è basato su di un modulo CPU OEM, il quale ha già degli I/O cablati (Indirizzo modulo 255). La parte hardware fisica di I/O non è altro che un modulo di espansione 20 I/O (Con indirizzo 0) connesso al bus di estensione del modulo CPU. Eventuali altri moduli di espansione connessi al bus assumeranno automaticamente indirizzi da 1 a 15.

[Sergio Bertana]

Aggiungo che tutte le soluzioni proposte sia HWg-Ares che Poseidon si interfacciano al portale gratuito SensDesk ed al software di monitoraggio HWg-PDMS. E’ così possibile gestire archiviazione dei dati in un database con possibilità di consultazione e creazione di reports anche con esportazione in Excel.

[Sergio Bertana]

Se il mezzo mobile non ha connessioni Internet la soluzione più semplice è HWg-Ares, il dispositivo può essere facilmente configurato (Topic) per gestire l’invio di segnalazioni di allarme (SMS o Email) in caso di superamento di soglie sul valore impostato. Tramite appositi sensori può acquisire sia i valori di temperatura, di umidità, di corrente, ecc.
 
Il prodotto dispone di un modem GSM/GPRS integrato, e di una batteria ricaricabile che lo rendono completamente autonomo, basta inserire una SIM ed alimentarlo. In caso di mancanza di alimentazione tramite la batteria interna è in grado di inviare una segnalazione di allarme.
 
Per la seconda domanda invece propongo un router della famiglia Conel, dal più semplice GPRS fino a soluzioni ultraveloci in LTE (4G). Basta inserire una SIM abilitata al traffico dati, accenderlo e collegando alla sua porta Ethernet Pc o altri dsispositivi è possibile accededre ad Internet come un normale router ADSL su linea telefonica. Naturalmente se si utilizza il router e quindi si ha l’accesso ad Internet al posto dell’Ares può essere utilizzato un Poseidon.

[Sergio Bertana]

E’ molto strano visto che l’estratto del manuale parla sembrerebbe in modo chiaro. Unico dubbio l’indirizzo prova usare un indirizzo più alto di 40001 perché il protocollo Modbus ha sempre di mezzo l’annoso problema dell’offset di 1. Definendo un indirizzo, nel protocollo passa l’indirizzo -1 e non vorrei fosse quello il problema. Io proverei con un indirizzo pari esempio 40008, oppure 40009.

Se guardi come funziona il protocollo puoi provare con la nostra utility Toolly ad inviare stringhe di interrogazione Modbus e verificarne il ritorno. In alternativa utilizza un programma tipo Modbus Poll per testare i comandi Modbus. Per leggere due registri ad indirizzo 40008 devi inviare la stringa binaria 00 00 00 00 00 06 01 03 9C 48 00 02 su porta TCP 502. Ecco lo screenshot del comando con Toolly inviato ad un nostro modulo CPU SlimLine, la risposta è in verde (Il valore dei registri è 0x0000, 0x0000).

[Sergio Bertana]

Come si vede dal manuale che hai allegato l’area da 40001 a 41024 è indirizzabile con i comandi modbus “03, Read Holding Registers”, “06, Preset Single Register”, “16, Preset Multiple Registers” come vedi dal manuale Modbus.

I codici che vedi negli oggetti Weintek fanno riferimento a questi comnandi, quindi per gestire quest’areas devi usare il codice 3x (Comando 03, Read Holding Registers). Se l’oggetto Weintek che utilizzi gestisce la scrittura dei dati il terminale utilizzerà in modo automatico i comandi 6 o 16 per gestire la scrittura del registro.

Sempre dall’estratto del manuale mi sembra di capire che i registri da 41025 a 42048 sono registri di sola lettura sempre utilizzando il comando 3x. Mentre i registri da 30001 a 31024 sono accessibili in sola lettura con il comando “04, Read Input Registers”.

Se l’oggetto che inserisci nel terminale non riesce a connettersi al dispositivo, và in errore e non viene visualizzato. Spero che queste indicazioni ti possano essere di aiuto.

[Sergio Bertana]

Per gli altri utenti del forum ricordo che si fa riferimento a questo topic, in pratica viene descritto come realizzare un semplice convertitore Ethernet/Seriale utilizzando un modulo CPU della serie SlimLine. La stessa applicazione è sicuramente possibile con un modulo CPU CODESYS, come si vede da questo topic, il modulo CPU è corredato da una libreria di funzioni embedded molto simili a quelle fornite con il modulo CPU programmabile in ambiente LogicLab.

In questi giorni stiamo completando tutta la documentazione per rilasciare il prodotto e sono impegnato, ma spero nei prossimi giorni di avere un attimo di tempo per postare un programma CODESYS che realizza il convertitore.

[Sergio Bertana]

Il modulo CPU MPS46A100 è equipaggiato con la porta Ethernet e la connessione ethernet è di gran lunga la migliore tra le connessioni possibili. Ricordo che ci si può connettere al modulo CPU anche tramite la porta seriale sia in RS232 che in RS485.
 
Abbiamo aggiunto la connettività via USB per i moduli compact che non dispongono di porta Ethernet ed abbiamo gestito l’USB con il driver RNDIS per poter veicolare le connessioni TCP/IP e poter accedere al modulo via USB con i protocolli Telnet, FTP e HTTP.
 
La gestione del protocollo TCP/IP su USB è molto pesante per la CPU rispetto alla stessa gestione su porta Ethernet ed è per questo che consigliamo sempre se disponibile di utilizzare la porta Ethernet. Il supporto dell’USB ha portato oltre a modifiche software anche a modifiche hardware e quindi non è possibile aggiornare i moduli CPU modello A con le nuove versioni di software.

[Sergio Bertana]

Fai riferimento alle news ed ai bollettini che stiamo inviando in questi giorni, in effetti il settore sviluppo è in piena attività da mesi per raggiungere lo scopo che i commerciali ci hanno richiesto. L’obiettivo è di proporre un modulo CPU SlimLine programmabile in CODESYS. Ma non solo abbiamo reso disponibile la programmazione in ambiente CODESYS sui prodotti della nostra linea SlimLine ma grazie ad uno sforzo congiunto con Axel che sviluppa LogicLab abbiamo anche pensato di fornire la possibilità per  chi arriva dall’ambiente CODESYS di importare i propri progetti in LogicLab. Tutto questo step evolutivo è ad un passo dal rilascio, un ritardo di un paio di settimane è stato necessario per aggiungere alcune implementazioni che un nostro beta tester ci ha segnalato e che abbiamo preferito inserire subito piuttosto che uscire con una patch dopo il rilascio. Quindi se segui il nostro sito presto la pagina di LogicLab riporterà il link per il download della nuova versione.

[Sergio Bertana]

Grazie alla “chirurgica” attenzione di un utente del forum che ha individuato l’errore “volutamente” nascosto nel programma citato in questo topic, rimando alla lettura di questo topic dove si è trattata la questione errore e sue possibili soluzioni.

[Sergio Bertana]

Ciao chegio, per gli altri utenti del forum informo che stiamo parlando del programma di esempio riportato in questo topic, di cui qui la stampa del programma a cui si fa riferimento. Ed un bravo a chegio che ha individuato l’errore “volutamente” nascosto nel programma…

In effetti ho scritto quel programma di getto scopiazzando pezzi da altri programmi e quell’errore è proprio scappato. Visto poi che l’errore non inficia il funzionamento non me ne sono accorto nel test. Però attenzione questo errore è molto grave perché è uno di quegli errori che possono provocare malfunzionamenti di un programma. Se si continuano a ricevere caratteri dalla seriale senza ricevere <CR> si sfora la dimensione del buffer RxString andando a sporcare le variabili allocate successivamente. Quindi come suggerito dopo la riga 44 si deve gestire l’incremento della variabile RxChars con le istruzioni.

RxChars:=RxChars+1; (* Nr of characters *)

In alternativa si può eliminare del tutto la gestione della variabile RxChars, eseguendo alla riga 49 il controllo sul pointer alla stringa con le istruzioni.

IF (Ptr >= (ADR(RxString)+SIZEOF(RxString)-1)) THEN CaseNr:=0; RETURN; END_IF;

Per completezza ricordo che una variabile stringa ha lunghezza superiore di un byte a quella dichiarata (Per contenere il codice tappo di fine stringa 16#00). Quindi il valore di SIZEOF(RxString) è 33.

[Sergio Bertana]

I protocolli gestibili dal pannello HMI sono una infinità impossibile conoscerli tutti, non ho mai approcciato un progetto con la connessione ad un dispositivo Yaskawa.

Credo la soluzione migliore sia fare delle prove, scaricando il programma EasyBuilder Pro tu hai a disposizione un simulatore di pannello, puoi realizzare un progetto e testare direttamente l’applicazione sul PC con la connessione reale al dispositivo.

[Sergio Bertana]

Non conosco i controllori YASKAWA e ProCoNos più che un protocollo sembra un sistema operativo Real time. Ma se tu fai riferimento alla Guida connessioni PLC che è scaricabile dal sito nella sezione download in fondo alla pagina del terminale trovi i riferimenti per la connessione del pannello al controllore YASKAWA 2300Siec.

Riporto un estratto della guida per la sezione che ti riguarda (Download estratto).

[Sergio Bertana]

Grazie alle possibilità di visualizzazione offerte da WebVisu integrato in CODESYS, ho aggiunto al progetto precedente una semplice pagina di visualizzazione di uno strumento a lancetta che indica il valore di peso acquisito dalla porta seriale.

Come si vede dallo screenshot, ho aggiunto un pannello di visualizzazione al progetto e nel pannello ho inserito uno strumento di visualizzazione. La variabile Weight che prima era una variabile locale è stata spostata nelle variabili globali di progetto per poter collegare lo strumento di visualizzazione alla variabile.

Trasferendo il programma su di una CPU SlimLine ed andando in debug è possibile vedere il movimento della lancetta sullo strumento nel pannello di debug di CODESYS. Accedendo al modulo CPU con un browser web viene visualizzato lo strumento con il movimento live della lancetta. Ricordo che WebVisu per permettere il movimento live degli oggetti nel browser utilizza una applet Java (Download programma sorgente).

[Sergio Bertana]

Con la presentazione della nuova famiglia di moduli CPU SlimLine programmabili in ambiente CODESYS, grazie ad una libreria fornita con il prodotto, possiamo offrire la stessa facilità di programmazione offerta da LogicLab anche in questo ambiente di sviluppo.

Traggo spunto dal programma di esempio soprariportato per dimostrare come con semplici modifiche sia possibile modificare il codice per poterlo eseguire sul modulo CPU CODESYS. In questo topic troverete lo stesso programma funzionante in ambientye CODESYS.

[Autore]

Post