[Sergio Bertana]

Come sistema di controllo PLC ti consiglio la nostra famiglia SlimLine abbinata ai terminali operatore touch screen della Weintek. Vediamo di riepilogare le tue necessità, intanto per l’acquisizione analogica ti occorre un modulo espansione I/O analogico PCB126*110 da 5 ingressi. Una precisazione il modulo può acquisire direttamente le termocoppie quindi ti eviterebbe i convertitori da termocoppia a 4-20 mA (Riducendo i costi totali). Ricorda che utilizzando gli ingressi in termocoppia si perde 1 ingresso (Utilizzato internamente per la compensazione del giunto freddo).
 
Come modulo CPU puoi utilizzare un modulo CPU Compact ARM7 MPS050*020, che oltre ai 6 ingressi digitali ed alle 4 uscite relè ha anche 2 ingressi analogici 0-10Volt o 4-20mA. La connessione tra il terminale ed il modulo CPU può essere in seriale RS485 mentre la seriale RS232 la puoi utilizzare per gestire la stampante termica.
 
Come terminale puoi scegliere nella gamma Weintek, il modello da 4.3″ può fare al caso tuo. Essendo registrato sul sito puoi vedere i prezzi di tutti gli articoli che ti ho indicato (Ho compilato una quotazione automatica ed ottengo un totale di ca 400€).

[Sergio Bertana]

Riporto lo screenshot della visualizzazione di un calendario su di un pannello Weintek. Il sistema in oggetto realizzato da un nostro cliente MBC-Systems su di un NetlogIII, gestisce il comando delle campanelle scolastiche.

Il suo funzionamento è molto simile a quello che devi realizzare tu, in pratica è possibile da pannello operatore impostare per ogni giorno dell’anno gli orari di attivazione delle campanelle. Nella programmazione si escluderanno i giorni festivi evitando il suono delle campanelle (Con disturbo alle abitazioni vicine) nei giorni  in cui la scuola è chiusa.

[Sergio Bertana]

Il consiglio è quello di utilizzare dei sistemi SlimLine interconnessi in Ethernet, in questo modo puoi utilizzare per l’interconnessione la rete aziendale se presente, od in alternativa inserire dei sistemi WiFi.

Per la gestione della luminosità esterna esistono molti sensori con uscita in tensione e/o corrente (4-20 mA) esempio il modello AHKF della S+S Regeltechnik GmbH (Vedi datasheet) che si trova ad un centinaio di € sul mercato italiano. Per la gestione del calendario puoi realizzare o delle pagine web direttamente nello SlimLine oppure creare un calendario sul terminale operatore.

E’ anche possibile definire gli orari in un file CSV che poi verrà letto dal sistema per gestire i comandi di accensione/spegnimento (Topic). Utilizzando la tecnica del file CSV è possibile con alcune modifiche al programma gestire uno schedule annuale definendo anche i giorni di festività in cui le lampade devono restare spente.

Se utilizzi una rete WiFi potrai accedere al terminale operatore o alle pagine web dello SlimLine anche da apparecchi mobili come Tablet e Smartphone.

[Sergio Bertana]

UniFi Controller
E’ un software java scaricabile gratuitamente che può essere installato su un PC (Windows, Linux, MAC) collegato alla rete (Topic), oppure nel cloud. Il controller permette la gestione dell’intera infrastruttura di APs WiFi tramite pagine web in modo semplice e immediato a portata di click.

Di default i singoli AP possono essere “adottati” dal controller, una volta adottati si potrà procedere con la configurazione della rete wireless. Lo scenario base prevede solitamente la presenza di una rete WiFi privata, ovviamente protetta a cui accedono tutti i dispositivi  affidabili. Tali dispositivi potranno quindi accedere a qualsiasi servizio o risorsa presente nella rete locale.

Il secondo SSID è dedicato all’utenza guest, in questo caso vengono applicate policy molto più restrittive. L’isolamento del client è attivo e quindi tutti i dispositivi ospiti non potranno accedere alla rete intera ma potranno solo accedere a risorse esterne (internet). E’ anche possibile applicare limitazioni sulla banda in download o upload per garantire che i client guest non saturino l’intera banda disponibile.

Sull’UniFi Controller un intero menù è stato dedicato al controllo degli accessi ospiti, che di fatto è una delle funzionalità più importanti, l’autenticazione degli utenti ospiti può essere fatta in diversi modi. E’ possibile lasciare la rete completamente aperta, oppure possiamo aggiungere una password WPA che dovremmo dare successivamente al cliente. Ma la caratteristica più interessante è l’attivazione di un portale interno dedicato interamente agli utenti guest. Il controller ci permette infatti con pochi click di realizzare un portale con queste modalità:

– Accettazione di un semplice legal notice prima della navigazione.
– Inserimento di una password prima della navigazione.
– Inserimento di un voucher temporale.
– Pagamento di una tariffa oraria tramite PayPal (o altri gataway di pagamento).
– Redirect verso un portale esterno per l’autenticazione.

[Sergio Bertana]

Ma se il punto dove vi è la connessione ADSL è visibile da tutti gli altri punti di utilizzo, basta utilizzare nel punto centrale un solo dispositivo con antenna omnidirezionale (Esempio Rocket con antenna Omni) configurato come access point. Nei vari edifici dove serve la connessione puoi utilizzare una NanoStation M (Configurata come station) puntata verso l’antenna del Rocket. Tutti i dispositivi devono essere in modalità Bridge.Alla uscita della NanoStation potrai mettere il tuo switch (Esempio un ToughSwitch) a cui collegherai tutti i dispositivi (Inverters) presenti nell’edificio. Come dispositivi sceglierei quelli in banda 5Ghz.

[Sergio Bertana]

Ora è tutto molto più chiaro, il problema è che il simulatore non gestisce ne le comunicazioni (Seriale e TCP) né gestisce i files, ecco perché non riesci a fare quello che desideri. Per poter dialogare in Modbus ti serve proprio il target hardware (Un sistema SlimLine o Netlog).

Andando più approfonditamente nell’argomento ti posso dire che SimuLab (Cioè l’ambiente di simulazione) dà disponibili aperture di comunicazione via TCP/IP su localhost ma non con il protocollo Modbus. Queste informazioni le puoi avere direttamente dalla ditta che realizza LogicLab e SimuLab che è la ditta Axel. Ti mando un email al tuo indirizzo privato in cui ti allego tutti i riferimenti.

[Sergio Bertana]

Non abbiamo notizie di blocchi simile al tuo anche da utenti che utilizzano il pannello connesso a PLC Mitsubishi. Quindi tenderei ad escludere bugs nel driver di comunicazione PLC. Visto che hai già provveduto ad eseguire l’upgrade del firmware del pannello, credo non ti resti che compilare l’RMA ed inviarci il pannello per la riparazione.

[Sergio Bertana]

A partire dalla versione SFW184A800 del sistema operativo è stata introdotta la funzione SysSpyData che permette se abilitata di spiare da connessione Telnet dati di programma utente, è utilizzata in alcuni FB e funzioni per permetterne il test di funzionamento. Nel tuo caso specifico è utilizzata nel FB ModbusMaster per spiare i dati in transito sullo stream di comunicazione. Infatti gli errori sono tutti riferiti alla FB ModbusMaster.

Purtroppo per gli SlimLine MPS046Ax00 non è stata implementata questa funzione ma ti posso consigliare un workaround che ti permette di aggirare il problema. Come vedi dalla stampa di questo progetto ho realizzato una funzione SysSpyData esattamente uguale come argomenti alla funzione embedded, in questo modo LogicLab compila il progetto utilizzando nelle librerie la chiamata a questa funzione senza generare errore.

Occorre anche definire 3 costanti che definiscono il modo in cui la funzione esegue lo spy dei dati. Le costanti vanno definite nell’area di definizione delle variabili globali. Allego comunque il progetto sorgente per il download da cui si può esportare sia la funzione che le definizioni.

SPY_ASCII : USINT := 1; (* Ascii mode *)
SPY_BINARY : USINT := 100; (* Binary mode *)
SPY_ASCHEX : USINT := 10; (* Extended ascii mode *)

[Sergio Bertana]

Ecco la stampa di un semplice programma che utilizzando la funzione SysVarsnprintf crea il messaggio da inviare e poi usando la funzione SysUDPSktSend è possibile inviarlo in UDP. Come si vede ho reralizzato un PROGRAM in linguaggio ST che gestisce una temporizzazione, ad ogni secondo incrementa il valore di due variabili REAL e ne invia il valore in UDP.

Nel mio caso il valore è inviato all’indirizzo 192.168.0.42 su porta 2000, e come si vede dallo screenshot ho messo Toolly come server UDP in ascolto sulla porta e ricevo i dati inviati dallo SlimLine. Come carattere di inizio ho scelto “[” come separatore “-” e come terminatore “]”, ma puoi scegliere i caratteri che desideri, basta modificarli nella funzione SysVarsnprintf.

Per semplificarti la decodifica della stringa ricevuta, puoi anche fissare il numero delle cifre trasmesse modificando la formattazione del numero nella funzione SysVarsnprintf. %.2f forza 2 cifre decimali, .3f fissa al minimo 7 cifre 3 intere il punto e 3 decimali (Esempio se il valore è 95.32 verrà riportato come 095.320). Allego programma sorgente per download.

[Sergio Bertana]

Eseguendo il simulatore SimuLab all’interno di LogicLab si apre il pannello di simulazione che prevede la possibilità di avere alcune configurazioni già preimpostate. Attivando questi pannelli puoi simulare il modulo CPU base e quello Compact oltre ad un modulo di I/O sia logico che analogico.

Ma queste sono solo suggerimenti, per la simulazione è preferibile aggiungere pannelli custom e semplicemente trascinando nel pannello la variabile potrai gestirne la simulazione (Screenshot). Quindi nel tuoi caso aggiungi un pannello e poi trascini all’interno le variabili che utilizzi nel tuo progetto.

[Sergio Bertana]

Dici che apri la connessione TCP/IP ma verso che porta ? immagino tu desideri utilizzare il Modbus TCP quindi credo utilizzi la porta 502. Se è così ti ho già spiegato nei post precedenti come poter fare, ti rimando comunque alla lettura della Modbus Protocol Reference Guide e della Modbus messaging on TCP/IP implementation guide.

Per aiutarti posso ancora riproporti delle semplici stringhe modbus per leggere e scrivere un registro a 16 bits nella memoria dello SlimLine. Ipotizzando di dover accedere ad una variabile allocata nella DB 100.16 (Indirizzo modbus 40008). Ricorda che l’indirizzo Modbus ha offset 1 pertanto nel comando devi inviare indirizzo -1 (40007 -> 0x9C47) per meglio capire ti allego l’estratto del manuale.

Per leggere il valore devi usare il comando modbus Code 03: Read holding registers, che in esadecimale è 00 00 00 00 00 06 01 03 9C 47 00 01.

Per scrivere 0x1234 devi usare il comando modbus Code 10: Preset multiple registers, che in esadecimale è 00 00 00 00 00 09 01 10 9C 47 00 01 02 12 34.

Per scrivere 0x5678 devi usare il comando modbus Code 10: Preset multiple registers, che in esadecimale è 00 00 00 00 00 09 01 10 9C 47 00 01 02 56 78.

Ecco lo screenshot dell’invio dei comandi verso uno SlimLine effettuato con Toolly. Come vedi in rosso sono evidenziate le stringhe di risposta ai comandi di scrittura (Preset) ed in blu quelle di risposta ai comandi di lettura (Read). Attenzione alla configurazione di Toolly nel Config devi definire modalità HEX.

[Sergio Bertana]

Dopo quanto scritto precedentemente ecco la stampa di un programma che dimostra come utilizzare I/O nella task Fast. Come si vede vi sono due programmi uno eseguito in Slow che appoggia l’ingresso Di00M00 sull’uscita Do00M00, ed un programma eseguito in Fast che appoggia l’ingresso Di01M00 sull’uscita Do01M00 (Download programma). Punti da considerare.

Il modo di acquisizione ingressi e DI_I_8_LL in modo da evitare il debouncing hardware presente sui moduli.

Nella gestione delle uscite logiche viene impostato il Mask per mascherare il bit 1 (Quello relativo alla uscita Do01M00). Attenzione la mascheratura è definita a bit, se si gestiscono più bit devi fare la OR dei bits utilizzati. Esempio per mascherare i bits 0, 1, 4 devi scrivere 16#00000013.

Nelle altre tasks (Slow e Back) non devi utilizzare le uscite gestite nella task Fast.

[Sergio Bertana]

Tutti i moduli di I/O logici connessi al modulo CPU sono aggiornati automaticamente (Immagine di processo) e mappati nella tabella %IX e %QX nella task Slow. Gli ingressi sono acquisiti prima e le uscite sono gestite dopo, l’esecuzione del programma utente. Quindi l’immagine dello stato di un I/O è valida per tutta l’esecuzione della task slow.

Nella task Back, viene creata una immagine di processo “parallela” che riporta lo stato degli ingressi prima della esecuzione e gestisce le uscite dopo l’esecuzione del programma utente, anche questa “immagine” dello stato di un I/O è valida per tutta l’esecuzione della task ma riporta lo stato degli I/O così come sono stati gestiti dalla task Slow, aggiornati quindi con la velocità di esecuzione della task Slow.

Nella task Fast se si vuole gestire gli I/O alla velocità di esecuzione della task, occorre acquisirne il valore e gestirne l’attivazione con le apposite FB (SysGetPhrDI e SysSetPhrDO) e non utilizzando quelli mappati nella tabella %IX e %QX. Ora siccome la gestione degli I/O tramite il bus I2C richiede tempo CPU è preferibile utilizzare nella task Fast gli I/O del modulo CPU, od in alternativa cercare di utilizzare I/O sullo stesso modulo di estensione a gruppi di 8/16 in modo da potervi accedere con una unica chiamata alle funzioni di gestione. In questo topic viene trattato lo stesso argomento.

[Sergio Bertana]

Toolly oltre che trasmettere un file può anche salvare in un file tutto quello che riceve, se apri una istanza terminale su porta seriale puoi definire il file su cui viene salvato tutto quello che è ricevuto dalla porta seriale (Screenshot). Agendo sul tasto Config si può impostare il file in cui salvare tutto quello che  si riceve dalla istanza di terminale aperta.

Certo questa è una operazione da eseguire a mano, magari dovrai farti un programma tuo che automatizzi queste operazioni. NB, se usi Toolly puoi anche evitare di usare il software VirtualCOM, basterà aprire l’istanza terminale con una comunicazione di tipo TCP/IP direttamente sull’indirizzo IP del convertitore.

[Sergio Bertana]

La prima prova che consiglio di fare con i convertitori Ethernet/Seriale è proprio questa, utilizzare due PC oppure anche solo uno con il programma Toolly in emulazione terminale (Nel caso di un solo PC utilizzerò due istanze).

Una delle emulazioni terminale si connette direttamente via TCP/IP al convertitore Ethernet/Seriale (Senza usare il software VirtualCOM). L’altra istanza si connette ad una porta seriale nativa del PC oppure tramite un convertitore USB/Seriale, questa seriale è connessa con un cavo null modem alla porta seriale del convertitore Ethernet/Seriale.

Il test è proprio inviare i dati da un terminale e riceverli dall’altro e viceversa (Attenzione ai settaggi seriali, per il convertitore occorre definire i settaggi dalla sua pagina web). Quindi come si vede il dialogo è bidirezionale.

Poi si prosegue nella prova installando il software di vitualizzazione VirtualCOM e si collega l’istanza terminale di Toolly alla porta COM virtuale anziché via TCP/IP al convertitore (Questa è la prova che hai fatto tu). Ed anche in questo caso potrai testare la comunicazione bidirezionale tra le due istanze del terminale Toolly. Qui potrai anche testare che le impostazioni seriali del convertitore Ethernet/Seriale sono ora accessibili dalla porta COM virtuale proprio come se fosse una COM reale.

Quindi la risposta alle tue domande è si, certo il dialogo è bidirezionale proprio come se fosse una COM reale del PC, unica differenza è che essendo la comunicazione TCP/IP a pacchetti i dati seriali sono pacchettizzati e poi trasmessi e questo porta ad un ritardo di comunicazione che può essere pochi mS su reti Ethernet libere fino a diventare un tempo importante su reti molto trafficate o reti WiFi.

[Autore]

Post