[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.

[Sergio Bertana]

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.

[Sergio Bertana]

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).

[Sergio Bertana]

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

[Sergio Bertana]

Il problema credo sia nel modo in cui il PLC tratta le variabili impostate dall’HMI, non conosco il Micrologix, però in generale quando converti un numero in una stringa (Il modem necessita di una stringa) se non fissi il numero di cifre da stampare indicando che devono essere necessariamente precedute da “0”, sono convertite in ascii solo le cifre indicative e non gli “0” che le precedono.

Perché non usi l’oggetto introduzione Ascii sul terminale e gestisci l’intero numero come una stringa da 16 o più caratteri, potrai passare la stringa così definita direttamente al modem.

Ad esempio nei PLC della nostra serie SlimLine l’FB di gestione modem accetta il numero già come stringa Ascii (Topic). In questo topic viene trattato l’invio di un SMS da pagina web, come vedi l’impostazione del numero di telefono è realizzata impostando una stringa Ascii.

[Sergio Bertana]

Ho realizzato un semplice progetto di Marcia/Arresto con un pannello di comando in WebVisu (Screenshot), il progetto può essere eseguito in simulazione direttamente sul PC.

Per eseguire il progetto in simulazione sul PC attivare il modo simulazione (Screenshot), eseguire login sul simulatore (Alt F8) e poi mandare in run il programma (F5). Come si vede dallo screenshot in funzionamento con il simulatore ha l’accesso alla interfaccia WebVisu solo dall’ambiente di sviluppo CODESYS, mentre se caricato sul sistema target permette di essere gestito da browser (Download progetto).

[Autore]

Post