[Sergio Bertana]

ProfilabExpert supporta la comunicazione con il protocollo Modbus, sia RTU che Over IP, quindi puoi tranquillamente connetterlo ai nostri moduli SlimLine sia tramite connessione seriale che Ethernet.
 
In questa configurazione puoi realizzare il programma logico di gestione direttamente nello SlimLine delegando al ProfilabExpert la sola interfaccia con l’utente. Questo permette di avere un reale funzionamento realtime con tempi di esecuzione estremamente ridotti e garantisce il funzionamento anche a PC spento o scollegato.
 
Per la realizzazione di sinottici animati normalmente i clienti utilizzano un pannello operatore touch screen che con costi estremamente ridotti permette di realizzare interfaccie uomo macchina accattivanti. La versione dotata di porta Ethernet del pannello operatore permette tramite un server VNC integrato di essere accessibile anche da web su PC o su smartphone tramite un comune client VNC gratuito (Vedi post).
 
Nella sezione del forum dedicata allo SlimLine troverai moltissimi posto con esempi di programmi realizzati di cui è possibile eseguire il download.

[Sergio Bertana]

Il problema è che tu stai istanziando una FB la SysETimeToDate in una funzione. Nella normativa IEC 611131 le funzioni non possono avere al loro interno dati statici, quindi per realizzare quello che tu vuoi, devi per forza realizzare un blocco funzione. Ecco il listato di una FB che ha in entrata una variabile di tempo in Epoch time ETime ed una uscita con una stringa formattata di data ed ora OString.

ETToD(EpochTime:=ETime); (* Valore di epoch time *)
i:=SysVarsnprintf(ADR(OString[0]), 4, ‘d/’, USINT_TYPE, ADR(ETToD.Day));
i:=SysVarsnprintf(ADR(OString[3]), 4, ‘d/’, USINT_TYPE, ADR(ETToD.Month));
i:=SysVarsnprintf(ADR(OString[6]), 6, ‘d ‘, UINT_TYPE, ADR(ETToD.Year));
i:=SysVarsnprintf(ADR(OString[11]), 4, ‘d:’, USINT_TYPE, ADR(ETToD.Hour));
i:=SysVarsnprintf(ADR(OString[14]), 4, ‘d:’, USINT_TYPE, ADR(ETToD.Minute));
i:=SysVarsnprintf(ADR(OString[17]), 3, ‘d’, USINT_TYPE, ADR(ETToD.Second));

Allego stampa e programma sorgente di un semplice porogramma di test.

[Sergio Bertana]

Il terminale Weintek può acquisire anche le variabili REAL dal PLC senza alcun problema, il formato delle variabili REAL sia sul pannello che sui sistemi SlimLine segue lo standard IEEE 754-1985 in singola precisione a 32 bit (Vedi post). La rappresentazione in memoria sui sistemi SlilLine è in Little-Endian ed è direttamente acquisita dal terminale.

Il fatto che leggi asterischi è perchè il valore della variabile è fuori dal range di visualizzazione dell’oggetto, probabilmente non hai settato correttamente il formato numerico della variabile. Essendo una variabile a virgola mobile devi definire il tipo 32-bit Float (Screenshot). Come vedi nella stessa finestra di impostazione puoi definire anche il numero di cifre intere e decimali che deve avere il numero visualizzato.

Ho realizzato un piccolo progetto (PLC e terminale) che esegue l’acquisizione di un valore analogico 0-10 Volt e lo visualizza sul terminale (Download progetto). Nel progetto la variabile REAL è allocata alo stesso indirizzo MD 100.16 che tu hai citato e quindi l’indirizzo da definire sul pannello è 40008.

Ricordo che le variabili REAL vanno sempre allocate in memoria ad indirizzi divisibili per 4, quindi MD 100.16, MD 100.20, MD 100.24, ecc.

[Sergio Bertana]

Sulla release B dei moduli CPU è possibile trasferire pagine web utente, e le pagine possono essere dinamiche, cioè  il loro contenuto viene modificato dal server, in questo modo è possibile visualizzare dati da variabili di programma. Ho realizzato una semplice pagina web di dimensioni adatte ad essere visualizzata anche in uno smartphone che visualizza i 4 valori di temperatura ed umidità del programma del post precedente. Ecco la pagina come visualizzata su uno smartphone (Screenshot).

Allego la stampa del sorgente html, basta copiarlo in un file testo e salvarlo con estensione htm nella directory Storage dello SlimLine per poterla visualizzare semplicemente digitandone l’indirizzo come si vede dallo screenshot.

Come si nota per la visualizzazione dei valori si utilizza una sintassi del tipo <!–[“%3.1f”, REAL, 0]–>, che stà ad indicare la visualizzazione di una variabile di tipo REAL ad indirizzo MD 100.0 con rappresentazione a due cifre intere ed una cifra decimale. Maggiori informazioni sulle pagine web dinamiche si trovano sul Manuale programmazione IEC61131-3 su sistema SlimLine.

Come si vede dalla direttiva <meta http-equiv=”refresh” content=”5″>, la pagina verrà ricaricata dal browser ogni 5 secondi visualizando così la variazione dei valori.

[Sergio Bertana]

Rispondo subito alla tua domanda, l’apertura del socket e la sua forzatura in listening può essere fatta una sola volta se poi vengono sequenziate le varie acquisizioni dai moduli STE, allego la stampa e i files sorgenti, di un programma che acquisisce 2 STE, ma può essere esteso al numero desiderato solo aggiungendo chiamate alla FB STESnmpAcq.

Vediamo come funziona la comunicazione con protocollo UDP facendo riferimento al programma indicato. Con la chiamata alla funzione Sysfopen viene aperto un socket UDP, la FB SysSktListen lo pone in ascolto sulla porta 161, tutti i pacchetti UDP da qualsiasi IP che arriveranno su questa porta saranno ricevuti e bufferizzati.

Ad ogni secondo (Se si hanno molti STE consiglio di mettere un timer con tempo maggiore) la prima FB STESnmpAcq invia la richiesta SNMP al modulo con IP 192.168.0.174 sulla porta 161 ed aspetta la risposta. Su ricezione risposta Done o su timeout od errore Fault viene attivata la seconda FB STESnmpAcq che invia la richiesta SNMP al modulo con IP 192.168.0.101 ed aspetta la risposta. E così via per tutte le altre acquisizioni che fossero necessarie.

Anche se si potrebbero eseguire tutte in parallelo le abilitazioni alla FB STESnmpAcq, per evitare di intasare lo stack di ricezione pacchetti UDP consiglio di sequenziarle come fatto nell’esempio.

[Sergio Bertana]

Si in effetti ho riletto quanto dichiarato nel post che tu citi e ci sono contraddizioni. Attualmente abbiamo rilasciato i nuovi moduli CPU Compact e la versione B dei moduli CPU ARM7. Questi nuovi prodotti sono retrocompatibili, ma avendo ridesegnato alcuni parti del sistema operativo stiamo lavorando su una nuova funzione per migliorare questo aspetto di protezione a livello utente.

[Sergio Bertana]

La soluzione più semplice per gestire la sua applicazione è l’utilizzo del Poseidon 3268. Tramite un comune browser il prodoto può essere configurato per gestire una uscita logica sul superamento di una soglia impostabile di temperatura e anche gestire l’invio di una Email.

Nello screenshot indico le due impostazioni da effettuare, la prima è per gestire l’uscita logica, la seconda per l’invio della Email. La mail può essere inviata a un massimo di 2 destinatari, se serve inviarla a più destinatari è possibile utilizzare il software PD Trigger (Vedi post).

[Sergio Bertana]

Aggiungo che tutto quanto descritto in merito al driver RNDIS è disponibile anche sui moduli CPU ARM7 versione B a partire da sistema operativo codice SFW184A200.

[Sergio Bertana]

Aggiungo che dopo l’impostazione dell’indirizzo IP di rete il modulo CPU SlimLine sarà accessibile da TCP/IP come un qualunque modulo connesso in rete. Ad esempio digitando nella barra di indirizzo di un browser l’indirizzo del modulo (Esempio 192.168.1.122) ne possiamo visualizzare la pagina web di configurazione (Screenshot).

Allo stesso modo potremo accedervi da LogicLab con connessione ModbusTCP sulla porta 502, da Telnet sulla porta 23 e da Ftp sulla porta 21. Accedendo in Ftp con l’esplora risorse di Windows (Definendo nella barra indirizzo ftp: //Admin:[email protected]) potremo vedere il File system del modulo CPU (Screenshot). 

[Sergio Bertana]

Bloccare la lettura del SysCustomerCode non è possibile in quanto questo codice deve comunque essere leggibile da programma e quindi basterebbbe per un cliente realizzare un semplice ramo nel programma che con un MOVE ne copia il valore su una sua variabile per poterlo acquisire.

Come forse non è stato ben spiegato nei post precedenti, il SysCustomerCode può proteggere il programma solo se non si danno i sorgenti al cliente. Nel caso in cui si diano i sorgenti al cliente l’unico modo di proteggere efficacemente il programma è utilizzare il Manufacturer ID.

Altra tecnica che alcuni adottano è di utilizzare una variabile in memoria RETAIN impostandone in debug il suo valore, il blocco funzione criptato controlla questo valore e se diverso si blocca. Non essendo nota la locazione di memoria utilizzata e quasi impossibile bypassare la protezione.

[Sergio Bertana]

Aggiungo la possibilità di utilizzare un Poseidon come netGSM gateway (Vedi post).

[Sergio Bertana]

Aggiungo per completezza dell’argomento che sui sistemi SlimLine è possibile avere anche un Manufacturer ID (MID), questo identificativo viene impostato sul dispositivo direttamente dalla Elsist che ne tiene tracciabilità. In questo modo nei programmi sviluppati che fanno riferimento a questo codice si ha la certezza che non possano essere eseguiti su sistemi SlimLine che non hanno lo stesso MID definito.

A differenza del Customer code, questo codice non è visibile da programma utente, esso viene controllato eseguendo una specifica funzione embedded che ne verifica l’esettezza utilizzando un algoritmo di criptazione. Ulteriori informazioni sono disponibili in questa FAQ.

[Sergio Bertana]

Cerco di spiegare meglio come funziona la protezione basata sul SysCustomerCode, la variabile è accessibile al programma utente perchè deve essere controllata nelle funzioni e FB protetti del cliente, e quindi è anche visualizzabile in debug. Ma si tratta di una variabile di sola lettura, quindi se si mette nella finestra di watch e si cerca di modificarne il valore LogicLab darà un errore.

Se qualcuno più smaliziato inserisce un ramo di programma ladder che con una istruzione MOVE oppure da ST con una assegnazione cerca di scrivere il valore nella variabile SysCustomeCode LogicLab si accorgerà del tentativo di scrivere su una variabile di sola lettura e darà un errore in compilazione.

Le protezioni descritte sono gestite da LogicLab, ma se qualcuno fosse così eclettico da inventarsi un qualche modo per riuscire a scrivere nella variabile SysCustomerCode il valore che tu hai fissato e che controlli nelle tue funzioni protette, ecco che interviene un controllo a livello sistema operativo di SlimLine. Il sistema operativo controlla il valore impostato della variabile con il valore presente in SysCustomerCode, e se riscontra una differenza (Segno che qualcuno in qualche modo ne ha forzato la scrittura) arresta l’esecuzione del programma.

Allo stato attuale (Sperando di non essere smentiti da qualche hacker) possiamo garantire che il Customer Code dà sufficenti garanzie di protezione sulla proprietà intellettuale del software.

[Sergio Bertana]

Le soluzioni sono molteplici, la prima che posso suggerire è di utilizzare un servizio di Email to SMS (Vedi post), naturalmente in questo caso bisogna appoggiarsi ad un servizio esterno e questo prevede una connessione Internet oltre a dei canoni da pagare.

Un’altra soluzione basata su PC prevede l’utilizzo del software PD Trigger (Vedi post), in questo modo l’invio degli SMS è gestito direttamente dal PC dove è eseguito il PD Trigger, inoltre il programma può eseguire un controllo attivo del buon funzionamento del dispositivo inviando un tramite ping segnalando allarme se il dispositivo non risponde.

HWgroup prevede inoltre la possibilità di utilizzare un dispositivo Poseidon come gateway SMS, in questo modo tutti i dispositivi HWgroup connessi in rete potranno inviare tramite il gateway messaggi SMS (Vedi datasheet).

[Sergio Bertana]

Il sensore utilizza il protocollo modbus RTU quindi non vi è alcun problema ad interfacciarsi con un modulo CPU SlimLine al sensore, basta utilizzare il blocco funzione ModbusRTUMaster_v1 per eseguire la lettura dei registri indicati dal sensore.

Per comodità ti ho realizzato un semplice blocco funzione in ST che acquisisce i registri 7, 8 e 9 dal sensore, siccome i valori sono espressi in decimi del valore, nella FB eseguo la divisione per dieci, e ritorno il valore di temperatura in gradi centigradi, di umidità in percentuale e del punto di rugiada in gradi centigradi tutti espressi in REAL.

Per evidenziare la caratteristica di poter mettere in cascata piu istanze del blocco funzione per acquisire più sensori in una rete RS485, ho realizzato un semplice programma dove vengono acquisiti i valori da 2 sensori. Terminata l’acquisizione del primo si acquisisce il secondo, terminata l’acquisizione si riparte dal primo. Allego stampa del programma e codice sorgente.

[Autore]

Post