Risposte nei forum create
-
Post
-
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.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).
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.
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.
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.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.
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.
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.
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.
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).
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).
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.
Come primo step ti consiglio di dare una occhiata a questo topic, non mi dici il tipo di stringa che lo strumento invia ciclicamente sulla porta seriale.
Posso immaginarmi un esempio di programma che acquisisce il valore di peso inviato da una bilancia, immagino una stringa del tipo “Peso:120.5 Kg”, ecco la stampa del programma ed il programma sorgente.
Come vedi dallo screenshot, inviando tramite un terminale seriale (Esempio il nostro programma Toolly) la stringa di peso il programma la cattura e trasferisce il valore di peso nella variabile.
Aggiungo la risposta alla domanda sulle variabili ritentive, come riportato in questo topic, le variabili RETAIN sono inizializzate al loro valore di INIT al caricamento del programma. Se vuoi che rimangano settate al loro valore al caricamento del programma devi mapparle sulla DB 100 ad indirizzi a partire da 2048.
Come vedi nel programma di esempio del post precedente ho mappato le variabili in quest’area, attenzione alle variabili a WORD devono essere mappate ad indirizzi divisibili per 2. Le variabili DWORD o REAL devono essere mappate ad indirizzi divisibili per 4.
Cancellazione memoria, proprio perché le variabili RETAIN allocate nella DB 100 non sono inizializzate al caricamento del programma, se utilizzate, conviene effettuarne l’azzeramento per evitare di averle valorizzate a valori indesiderati. Per eseguire la cancellazione, connettersi in Telnet al sistema e dopo il login arrestare l’esecuzione del programma utente PLCCommand -stop, eseguire la cancellazione della memoria PLCCommand -mc e poi rimandare in esecuzione il programma PLCCommand -go, (Screenshot).
Nel programma che hai scritto non vi è nessuna subroutine, nella normativa IEC non è possibile realizzare subroutines all’interno di un programma. Le funzioni o le FB devono essere definite come tali e solo dopo averle definite possono essere richiamate da programma.
Nel tuo programma se F01 è alto esegui un salto condizionato JMPC alla etichetta LblA dove incrementi T01 e poi con RET esci dal programma. Per eseguire una subroutine (Function in IEC 61131) devi definirla (Esempio AddValue) e poi eseguirla da IL. Allego la stampa del programma ed il codice sorgente.
LD F01
JMPCN Lbl (* Se F01 non attivo salto a label *)LD T01 (* Carico 1o operando funzione (Value) *)
AddValue 1 (* Eseguo funzione passando 2o operando (Increment) *)
ST T01 (* Memorizzo valore di ritorno da funzione *)Lbl:
LD T01
LT 1000
ST F02
