[Sergio Bertana]

Aggiungo a quanto detto nel post precedente, che il limite sul numero di utenti da gestire è solo la dimensione del file, si possono gestire tranquillamente migliaia di utenti. Aggiungendo schede I/O logiche di estensione è possibile gestire più di due porte.

Il vantaggio di poter disporre di un prodotto programmabile permette di modificarne il funzionamento secondo le proprie esigenze con possibilità di aggiungere altre funzionalità. Il sistema può gestire anche l’invio e la ricezione di SMS permettendo una interazione anche tramite SMS.

Su un progetto simile realizzato qualche anno fà da un nostro cliente che gestiva l’apertura di un cancello per una palestra, nel file dati era memorizzata la data di nascita dell’utente, e quando comandava l’apertura del cancello se era nel giorno prossimo a cui era nato veniva inviato un SMS con gli auguri.

Altra possibilità e di gestire via SMS altri comandi come illuminazione, riscaldamento, irrigazione, ecc, inoltre il sistema può inviare SMS su condizioni di allarme.

[Sergio Bertana]

Tra le nostre case distribuite non abbiamo un prodotto che risolva il vostro problema, ma utilizzando i prodotti della nostra famiglia SlimLine è facile realizzare quello da voi richiesto. Ho realizzato un semplice progetto di cui fornisco il programma sorgente tagliato esattamente sulle esigenze richieste.
 
La realizzazione si basa su di un modulo CPU che ha a bordo 2 I/O logici, le due uscite saranno utilizzate per comandare l’apertura delle due porte. Il modulo tramite una porta seriale si connette ad un modem GSM, mentre tramite la porta ethernet si connette alla VPN.
 
Nel file system del modulo CPU è possibile trasferire un file (Formato CSV) che contiene i numeri di telefono abilitati alla apertura delle porte, per ogni numero è indicata quale delle due porte deve aprire. Il file può essere realizzato in Excel o anche con un normale text editor e trasferito nel modulo via FTP (Vedi post). Esempio file (Ogni riga và terminata con <CR><LF>):
 
+39335123456; 1
+39014234567; 2
+39014223578; 2
 
Come si vede il primo numero di telefono comanda l’apertura della porta 1, mentre gli altri due comandano l’apertura della porta 2. Alla ricezione della chiamata telefonica il blocco funzione di gestione modem ModemCore, rileva il CLIP del chiamante e lo passa al blocco funzione FindCLIPOnFile che esegue la ricerca nel file CSV del numero. Se il numero è trovato viene comandata per 5 Sec l’uscita relativa alla porta da aprire, ecco la stampa del programma ed il codice sorgente.

[Sergio Bertana]

Premetto che la versione LinuxPLC anche se annunciata non è ancora disponibile, abbiamo prototipi in tests presso i nostri laboratori e presso alcuni clienti betatester. Vedo di darti informazioni riferite alle caratteristiche che saranno sicuramente presenti nella versione definitiva.

La programmazione IEC è standard quindi avremo sempre gli stessi tipi di dato, per la variabile che tu indichi bit credo ti riferisca al tipo BOOL che occupa comunque un byte di memoria.

Il puntamento modbus sarà sicuramente lo stesso, avremo però un’area più grande di memoria, l’attuale DB100 (Attualmente di 4096 bytes) sarà sicuramente ampliata di molto. Ad essa si abbineranno altre aree di memoria allocate in altre DB.

Avremo sicuramente più connessioni TCP/IP modbus contemporanee, rispetto alle 3 gestite attualmente.

Si potrà trasferire il programma a caldo, senza cioè arrestare il programma in corso. Si potrà quindi modificare il programma mentre il sistema stà eseguendo quello precedente senza arresti.

Per la funzione WebServer abbiamo sicuramente intenzione di attivarla con la possibilità di definire pagine web configurabili dall’utente, ma questo arriverà più avanti.

[Sergio Bertana]

Aggiungo per quanto riguarda la programmabilità, come si vede dalla pagina del prodotto, sono disponibili due linee di moduli identici dal punto di vista hardware.

Linux Open
Programmabile con tutti gli strumenti di sviluppo del mondo GNU linux. E’ possibile operare tramite una connesione ethernet in SSH (Esempio Putty) con l’interfaccia standard a comandi di Linux. Per lo sviluppo forniamo una macchina virtuale VMWare già predisposta con sistema operativo Linux e tools di sviluppo installati. Apposite librerie forniscono l’accesso ai nostri moduli di estensione.

Linux PLC
Programmabile con LogicLab esattamente come l’attuale modulo CPU. Su questa piattaforma è possibile migrare tutti i programmi attualmente già sviluppati per il modulo attuale, con la possibiltà di aumentare la dimensione e la complessità del programma. Su questo modulo si renderanno mano a mano disponibili nuove funzioni e blocchi funzioni.

[Sergio Bertana]

Con la nuova CPU ARM9 (Linux) abbiamo voluto aumentare le prestazioni del nostro sistema programmabile SlimLine. SlimLine è una linea di schede industriali per automazione, programmabili secondo lo standard IEC 61131-3 utilizzando l’ambiente di sviluppo LogicLab (Fornito gratuitamente).

Da tempo i nostri Clienti ci chiedono l’apertura del sistema verso nuovi protocolli di comunicazione (Seriale, CAN, Ethernet), verso una gestione disco con sempre più files e sempre più spazio a disposizione, la possibilità di sviluppare algoritmi di calcolo sempre più complessi. Ecco quindi la necessità di realizzare una CPU più veloce e con maggiore disponibilità di risorse. Si è scelto di utilizzare una piattaforma basata su ARM9 e vista la sua natura Open source si è scelto il sistema operativo Linux, per realizzare un nuovo modulo CPU da affiancare a quello esistente.

Il nuovo modulo ha stesse dimensioni e stesse connessioni del modulo basato su ARM7, unica differenza è la presenza di un connettore USB host in più su di un lato. Naturalmente dispone di una maggiore velocità di processo e di un maggiore spazio di memoria sia per il programma che per il file system.

I moduli di estensione della famiglia SlimLine sono perfettamente compatibili con il nuovo modulo CPU.

[Sergio Bertana]

In alternativa all’utilizzo di Modbus, come già espresso in questo post, su SlimLine utilizzando il blocco funzione SysSktListen è possibile mettere in ascolto su di una porta TCP un socket e gestire lo scambio dati su di esso, la stessa cosa è possibile da porta seriale.

Utilizzando quindi i metodi classici Sysfopen, Sysfgetc, Sysfputc, SysVarsscanf, SysVarfprintf è possibile ricevere e trasmettere dati sia da porta seriale che da socket TCP/IP, questo rende possibile creare una propria gestione di un qualsiasi protocollo di comunicazione.

Ecco quindi che nel tuo caso è possibile realizzare la gestione di un semplice protocollo su TCP/IP per acquisire il valore dei contatori e per resettarli. Ho aggiunto al programma di conteggio sacchi anche la gestione della ciomunicazione TCP con i comandi di lettura valore contatori e reset.

Aprendo la connessione con un client Telnet (Esempio Toolly) sulla porta 2000 (Vedi Screenshot), verrà visualizzato un messaggio di Welcome, poi inviando il comando ?C<CR> viene ritornato il valore dei due contatori ed inviando il comando !C<CR> il valore dei due contatori viene resettato, stampa e download programma sorgente.

[Sergio Bertana]

I sistemi SlimLine supportano il protocollo Modbus Ascii ed Rtu (Vedi Modbus Protocol Reference) sulle porte seriali (Bisogna configurarlo dalla pagina web del prodotto), e over IP dalla interfaccia ethernet (Vedi Modbus messaging on TCP/IP).
 
Come ho scritto nel post precedente le variabili di conteggio sacchi sono state appoggiate su valori UINT allocati nella DB100 dello SlimLine e questo permette di leggerne e scriverne il valore (Quindi resettarle) da modbus. Il protocollo modbus è uno standard “de facto” e quindi si trova molta documentazione su come implementarlo.
 
Nel nostro forum si trovano molte informazioni sul modbus, in questo post c’è una implementazione in Php.

[Sergio Bertana]

La possibilità di eseguire una chiamata telefonica abbinata alla possibilità da parte della FB ModemCore di ritornare il CLIP (Numero di telefono) del chiamante, permette di realizzare un sistema di controllo heartbeat a costo zero.

Ipotizziamo di avere un certo numero di sistemi sparsi geograficamente ognuno dei quali invia SMS in caso di allarme, in questa condizione è importante essere certi del buon funzionamento dei sistemi. Nessuna ricezione di SMS può voler dire che tutto è normale, ma può anche voler dire che c’è un guasto nel sistema che ne impedisce l’invio degli SMS.

In questo scenario può essere utile fare eseguire ai sistemi una chiamata telefonica ogni tempo prefissato verso un sistema munito di modem, su questo sistema (Senza rispondere alla chiamata) si potrà controllare i CLIP delle chiamate ricevute ed in caso di assenza prolungata di uno o più CLIP si può generare una condizione di allarme.

[Sergio Bertana]

La libreria eModemLib ha una serie di funzioni e blocchi funzione per gestire un modem connesso alla porta seriale (Estratto documentazione). In questo post si trova una descrizione di come gestire l’invio e la ricezione di messaggi SMS tramite le varie FB.

ModemCore, modem core management: FB di gestione modem.
ModemSMSReceive, receive a SMS message: FB ricezione messaggio SMS.
ModemSMSSend, send a SMS message: FB invio messaggio SMS.

Dalla versione SFR057B000 della libreria è stato aggiunto il blocco funzione:

ModemPhoneCall, executes a phone call: FB gestione chiamata telefonica.

Tramite questo blocco funzione è possibile su comando effettuare una chiamata telefonica ad un numero definito. E’ possibile definire il tempo di durata chiamata, passato il quale la chiamata viene conclusa ed il telefono chiamato smette di squillare.

[Sergio Bertana]

E’ normale che dia quegli errori, la variabili VarOut0 e VarOut1 sono variabili definite solo nel simulatore, quindi sul target reale non vengono trovate. Occorre definire due variabili una per il conteggio dei sacchi piccoli ed una per il conteggio dei sacchi grandi. Ti ho modificato il programma definendo le variabili:

SacchiPiccoli AT %MW100.16 : UINT; { DE:”Numero sacchi piccoli” }
SacchiGrandi AT %MW100.18 : UINT; { DE:”Numero sacchi grandi” }

Da notare che le ho allocate in memoria ad indirizzo fisso, in questo modo sono accessibili da modbus. Ad esempio utilizzando un terminale operatore touch screen basterà creare una pagina con due oggetti di visualizzazione variabili uno che legge l’indirizzo modbus 40008 (Per visualizzare il numero di sacchi piccoli) e l’altro che legge l’indirizzo modbus 40009 (Per visualizzare il numero di sacchi grandi).

Tutti gli errori del programma StatUp sono anche loro connessi all’uso di variabili che parametrizzano il simulatore. Tutto il programma StartUp non serve sul sistema reale e quindi l’ho eliminato. Ecco la stampa del programma ed il codice sorgente.

[Sergio Bertana]

Lo scambio di memoria tra sistemi SlimLine tramite connessione UDP è gestito dal blocco funzione UDPDataTxfer (Vedi post). Con questo blocco funzione è possibile scambiare un blocco di memoria tra due sistemi, l’FB gestisce sia la trasmissione che la ricezione dei dati. I dati sono trasmessi con i controlli di CRC ed è gestito un acknowledge sulla ricezione, nel caso in cui il pacchetto UDP venga perso viene eseguita automaticamente la ritrasmissione.

L’FB per minimizzare il traffico di dati sulla rete, invia il pacchetto dati verso gli altri sistemi solo se vi è variazione dei dati nel buffer in scambio.

Seguendo le tue richieste ho realizzato un programma LogicLab che prevede la gestione dello scambio tra i 3 sistemi. Per semplicità ho realizzato un solo progetto con 3 programmi.
 
DataTxFerPLC0:
Invia verso PLC1 (192.168.0.101) da DB100.0 a DB100.99 e riceve da DB100.100 a DB100.199
Invia verso PLC2 (192.168.0.102) da DB100.0 a DB100.99 e riceve da DB100.200 a DB100.299
 
DataTxFerPLC1:
Invia verso PLC0 (192.168.0.100) da DB100.100 a DB100.199 e riceve da DB100.0 a DB100.99
Invia verso PLC2 (192.168.0.102) da DB100.100 a DB100.199 e riceve da DB100.200 a DB100.299
 
DataTxFerPLC2:
Invia verso PLC0 (192.168.0.100) da DB100.200 a DB100.299 e riceve da DB100.0 a DB100.99
Invia verso PLC1 (192.168.0.101) da DB100.200 a DB100.299 e riceve da DB100.100 a DB100.199

Ti ricordo che puoi esportare ogni programma (Tasto destro del mouse sul programma Export program to Library) dal mio progetto in una libreria ed importarlo poi nel tuo progetto. Allego stampa del progetto e file sorgente per download.

[Sergio Bertana]

Certo che è possibile, la comunicazione seriale è indipendente dalla comunicazione radio, quindi puoi mischiare il tipo di interfaccia seriale con la quale ti colleghi all’apparecchio. Puoi tranquillamente, come nel tuo caso, utilizzare una connessione RS422 su un apparecchio ed una connessione RS232 sull’altro apparecchio.

Nel caso di connessione RS485 su due fili, l’ATC-3200 gestisce anche in automatico la direzione dei dati permettendo la comunicazione in Half-Duplex.

[Sergio Bertana]

Per sicurezza il server FTP sullo SlimLine chiude automaticamente sia la connessione comandi che la connessione dati se non riceve pacchetti per 30 Secondi. Quindi può succedere che lasciando aperto in connessione il client FTP sul proprio PC ma non eseguendo comandi e/o trasferimenti di dati per un tempo superiore a 30 Sec, lo SlimLine provvede a chiudere la connessione.

In questo caso quando sul client cerco di eseguire un comando ottengo come risposta un errore ed occorre chiudere e riaprire la connessione con lo SlimLine per rispristinare il funzionamento corretto. Come si vede da questo screenshot nella configurazione di alcuni client FTP (Nell’esempio il Total Commander) è possibile impostare l’invio automatico di un comando (Solitamente il NOOP) per mantenere viva la connessione. Naturalmente il tempo di invio deve essere inferiore ai 30 Secondi.

[Sergio Bertana]

I 2 ingressi digitali della CPU come tutti gli ingressi digitali dei moduli di espansione sono optoisolati ed accettano una tensione in ingresso nel range da 10 a 30 Volt. Per il conteggio dei sacchi mi parlavi di utilizzare una fotocellula a sbarramento il cui fascio viene interrotto dal passaggio del sacco.

Sul mercato esistono moltissimi tipi di fotocellule, non ti posso dare una indicazione precisa, cito ad esempio il sensore a sbarramento E3F2 della Omron (Vedi datasheet).

Ti consiglio di cercare da un rivenditore di materiale elettromeccanico oppure effettuando una ricerca con il termine sensori fotoelettrici sul sito RS components.

[Sergio Bertana]

SlimLine supporta il protocollo modbus in modo nativo, il modbus RTU slave è disponibile standard su tutte le porte seriali sia RS232 che RS485 (Nella versione Full RS485).

La versione Versione Full RS485 dispone anche della porta ethernet ed è possibile accedere con un comune browser alla configurazione sia dei parametri seriali che dell’indirizzo di nodo modbus (Screenshot).

Se invece vuoi gestire la comunicazione modbus master basta utilizzare l’apposito blocco funzione sModbusRTUMaster (Estratto manuale). L’utilizzo del blocco funzione è estremamente semplice ed è interamente visibile nell’esempio ladder incluso nel manuale.

L’argomento comunicazione modbus è ampiamente trattato nel forum, e con la funzione Ricerca testo puoi trovare molti argomenti che lo trattano. (Vedi questi posts 1, 2).

Ho comunque ripreso il programma di esempio ModbusScambioIO (Download programma) che esegue lo scambio I/O logici tra due sistemi SlimLine. L’esempio contiene due progetti, uno da trasferire sul sistema master (Stampa), ed uno da trasferire sul sistema slave (Stampa).

Come si vede nel progetto master ho semplicemente accodato due chiamate al blocco funzione sModbusRTUMaster, il primo esegue la lettura degli ingressi dal modulo slave (Con il comando 16#01), il secondo esegue la scrittura delle uscite sul modulo slave (Con il comando 16#0F).

[Autore]

Post