Interoperabilità in soluzioni ibride .NET MF / PLC

  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google
Post di Lorenzo Maiorfi domenica 6 maggio 2012 14:50:29
Valuta questo articolo 0 Voti

Per chi si occupa di progetti .NET Micro Framework costretti a “farsi largo” in contesti industriali, il tema dell’interoperabilità è ovviamente uno dei più interessanti e stimolanti, anche se poi in verità quello che vedremo fra poco si applica in maniera assolutamente equivalente a soluzioni in cui la parte gestita da schede a microcontrollore non sia necessariamente rappresentata da dispositivi basati su .NET Micro Framework.

Introduzione ai PLC

Con il nome di PLC viene di norma indicato un controller programmabile in grado di eseguire applicazioni di controllo in contesti industriali. Premetto subito che dalle mie prime sperimentazioni in materia di PLC emerge che ciò che nello sviluppo di soluzioni industriali distingue maggiormente l’approccio “a PLC” rispetto a quello “a microcontrollore” è rappresentato non dalle caratteristiche dell’hardware, come inizialmente pensavo, ma dalla metodologia di programmazione. Senza addentrarci troppo nei dettagli, diciamo infatti che, mentre nel mondo dei microcontrollori lo sviluppatore di soluzioni è di fatto abituato (direi costretto) a realizzare sistemi sui quali si ha il massimo controllo e la massima flessibilità ma a costo di una complessità che in progetti reali può trasformarsi facilmente in mesi/uomo di sviluppo firmware (senza contare l’impegno relativo alla necessità di conciliare il mondo fisico con quello digitale, fatto di attività su sensori, attuatori, elettronica di condizionamento dei segnali, protocolli di comunicazione, ecc.), lo sviluppatore PLC si trova a confrontarsi con un ambiente e dei linguaggi di programmazione (la IEC ha standardizzato tre diversi linguaggi di programmazione industriali, di cui due grafici, equivalenti sul piano funzionale ma distinti sul tipo di “modello” cui si ispirano) che rendono estremamente veloce lo sviluppo di un ristretto insieme di applicazioni, guarda caso quelle in cui i PLC trovano maggiore adozione.

Vediamo subito un esempio: supponiamo di voler realizzare una semplicissima applicazione di controllo che a fronte dell’attivazione di uno switch a due posizioni attivi un relé che a sua volta azioni ad esempio un motore elettrico, mentre alla disattivazione dello switch mantenga attivo il relé per un certo tempo prima di disattivarlo, tutto questo con la gestione di un ulteriore pulsante di sicurezza che indipendentemente da tutto disattivi il motore istantaneamente in caso di emergenza. In un’applicazione basata su microcontrollore il firmware dovrebbe necessariamente gestire gli interrupt relativi ai fronti di salita e discesa del segnale digitale proveniente dallo switch, utilizzare un thread diverso da quello principale per gestire correttamente il ritardo nella disattivazione del relé (un Thjread.Sleep() bloccherebbe il thread relativo all’handler che gestisce l’interrupt, non drammatico visto il tipo di applicazione ma senz’altro neanche ottimale), gestire eventuali “glitch” relativi ai “rimbalzi” meccanici dello switch, ecc., senza peraltro contare che molto probabilmente lo switch industriale di cui parliamo potrebbe avere necessità di una piccola “rete” elettrica di condizionamento perché magari realizza a seconda dello stato un circuito aperto o un corto circuito, con la necessità di prevedere una resistenza di pull-up che limiti la corrente nel secondo caso, tanto per fare un esempio.

La stessa applicazione, espressa con il linguaggio più diffuso nel mondo dei PLC, il Ladder, è invece definito(graficamente) come segue (in cui i nomi simbolici “Switch_Nero1” e simili sono mappati su ingressi e uscite specifiche attraverso una “tabella dei simboli” che fa corrispondere ad esempio allo switch di emergenza l’area “I1.2”):

Inoltre, la modularizzazione e standardizzazione dei componenti hardware rende possibile allo sviluppatore PLC quello che di fatto ricorda un po’ quanto avviene con la sviluppo di applicazioni Gadgeteer, in cui mainboard e moduli sono referenziati e configurati graficamente all’interno di una superficie di design quale quella illustrata di seguito, che si riferisce al nostro “rack” PLC di esempio:

Sperimentare con un PLC

Se siete curiosi di fare qualche piccolo esperimento, è sufficiente che vi procuriate un modulo CPU, un alimentatore e un paio di moduli di I/O per gestire rispettivamente ingressi e uscite. Va anche detto che in commercio esistono moltissime soluzioni micro-PLC in cui tutti i moduli elencati sono già presenti all’interno di un unico dispositivo. Aggiungo inoltre che in rete (su eBay in particolare) è reperibile moltissomo materiale usato veramente a basso costo rispetto ai prezzi (davvero esorbitanti) di listino del nuovo.

Per la mia sperimentazione ho fatto riferimento a dispositivi Siemens della serie Simatic S-300. nel dettaglio, mi sono procurato un alimentatore 24V PS-307, un modulo CPU-315, un modulo 32 ingressi 24VDC denominato SM321 e un modulo 24 uscite 24VDC 0.4A denominato SM322, il tutto usato e acquistato, appunto, su eBay.

Come ambiente di sviluppo, ho utilizzato l’IDE STEP 7 Lite (versione 3.0 SP4), liberamente scaricabile dal sito Siemens. Va purtroppo notato che questo software è installabile solo su sistemi operativi a 32 bit, con una spiccata preferenza per Windows XP, per cui ho dovuto ricorrere ad una macchina virtuale (Virtual Box) per l’installazione di quanto necessario. Per potermi poi collegare al modulo CPU del PLC da Windows (per la programmazioe, il debugging, ecc.) mi sono procurato un adattatore MPI USB (MPI è un protocollo di comunicazione proprietario utilizzato nei moduli PLC sprovvisti ad esempio di accesso Ethernet), nel mio caso un clone del più diffuso “PG/PC” (come viene chiamato nella documentazione ufficiale) prodotto da Siemens. Per chi volesse spetimentare anche senza un PLC fisico, è possibile scaricare una versione trial (“facilmente estendibile”) di S7-PLCSIM, un simulatore che può essere utilizzato da dentro STEP 7 Lite in maniera indistinguibile da un PLC reale, con tanto di finestre di eding/monitoring di tutte le aree di memoria interne (tra cui, ovviamente, quelle relative a ingressi ed uscite digitali, per intenderci).

Collegare il PLC ad un FEZ-Panda

Le modalità di interazione che è possibile prevedere tra sistemi PLC e schede a microcontrollore sono parecchie: nei casi più complessi possiamo pensare ad una condivisione di un qualche tipo di bus/rete, quali Modbus, Profibus, CANBus, Ethernet Industriale, OPC (che è in realtà un wrapper applicativo basato su COM dei canali di comunicazione citati), ecc., senz’altro soluzioni ottimali se si prendono a riferimento progetti complessi, ma è possibile anche prevedere soluzioni un po’ più adatte a piccoli progetti, quali ad esempio una comunicazione seriale su RS-232/485, che richiedono però che nel rack PLC sia presente almeno un modulo di comunicazione.

La soluzione minima prevede invece che gli ingressi e le uscite del PLC siano collegate ad altrettanti GPIO della scheda a microcontrollore, per realizzare ad esempio dei sistemi in cui una scheda basata su .NET MF faccia da “supervisore” (magari come bridge verso sistemi che espongono API TCP/HTTP quali Pachube o applicazioni propietarie basate ad esempio su SignalR) del sistema PLC vero e proprio.

In questo caso il problema dell’interazione si trasforma in un semplice problema di adattamento elettrico di segnali. Gli ingressi digitali di un modulo PLC sono infatti tipicamente realizzati come dei “cortocircuiti” o dei “circuiti aperti” che rispettivamente aprono e chiudono un circuito ai cui capi troviamo l’alimentazione (nel nostro caso 24V DC) del modulo stesso. Le uscite digitali, analogamente, riportano in uscita una logica 0-24V DC (con una limitazione di 0,5A nel modulo che ho utilizzato) che tipicamente viene utilizzata per attivare dei relé con bobine a 24V.

Lo schema dei due moduli, DI e DO, è riportato nelle immagini che seguono:

Poiché come è noto i livelli “gestibili” da parte dei GPIO di una scheda a microcontrollore quale il FEZ-Panda utilizzato nel mio esempio, prevede ingressi 0-3.3V (5V nel caso di ingressi “tolleranti”) ed uscite 0-3.3V, l’interoperabilità è ottenibile facilmente utilizzando:

  • Per gli ingressi al PLC (uscite del FEZ-Panda) delle schede Relé che prevedano ingressi digitali 0-3.3V. In questo caso il relé commuterebbe i 0V e 24V provenienti dall’alimentazione del modulo ingressi del PLC verso ciascun ingresso da pilotare (un relé per ingresso, in altri termini). Le soluzioni più economiche che sono riuscito a trovare in rete sono quelle di Denkovi e KMTronics.
  • Per le uscite del PLC (ingressi del FEZ-Panda) una scheda con ingressi optoisolati che tollerino i 24V. In questo caso dovrete tipicamente collegare le uscite 0-24V del PLC agli optoisolatori della scheda, “estraendo” poi da un connettore per segnali a logica TTL i corrispettivi segnali (tipicamente invertiti) 0-5V. Per la mia sperimentazione ho utilizzato una scheda prodotta dalla tailandese ETT e commercializzata in Italia da Tellab. Questa scheda prevede l’utilizzo di due diverse alimentazioni, 12V e 5V, che ho ricavato con due piccoli DC/DC step-down switching prodotti da Sure Electronics, collegati in cascata a partire dalla 24VDC del PLC (in realtà il primo step-down porta la 24V a 12V, mentre il secondo porta a 9V, messi in ingresso al Vin del FEZ-Panda, per poi riprendere i 5V da quest’ultimo per alimentare la parte a più bassa tensione della scheda con gli opto-isolatori).

Il sistema completo utilizzato per le prove è quindi quello riportato nelle immagini che seguono, in cui il FEZ-Panda rilevava le variazioni delle uscite del PLC “rispondendo” con un “treno di impulsi” sul LED diagnostico a bordo scheda con un pattern specifico per ciascuna variazione rilevata. In considerazione dell’elemento di ritardo introdotto nella network Ladder (o “rung”, in gergo Ladder) relativa al processing dello “switch nero #1” (illustrata sopra), il treno di impulsi relativo alla disattivazione dell’uscita #1 viene attivato dopo 2 secondi dalla disattivazione dello switch stesso (a meno di intervenire sul pulsante di emergenza, ossia “switch rosso #1”.

re: Interoperabilità in soluzioni ibride .NET MF / PLC

venerdì 8 giugno 2012 11:00:16 y15822137359

A person might believe people need to make investments in mace, pepper spray, a fancy umbrella that flexes and folds in addition to disguising a deadly weapon inside and probably does the dishes too.

Well, it really costs absolutely nothing at all in order to always be well prepared for self defence, and a person's best self defence weapons are provided to everyone the day that you are born.

The actual 3 best self defence weapons are a person's eyes, your hands, and your own instincts.

re: Interoperabilità in soluzioni ibride .NET MF / PLC

giovedì 7 giugno 2012 10:46:43 elvisamy

  hello, guys. i'd glad to tell you that i had found some excellent mobilephones.  it has different styles, such as htc x315e  , mtk6575 . the functions of the phones are powerful.  they are very perfect,  you worth to own them. have a look, it maybe a big surpise.  

 

re: Interoperabilità in soluzioni ibride .NET MF / PLC

lunedì 7 maggio 2012 19:57:10 Mario Vernari

L'articolo è ben fatto come sempre, ma non ho chiaro il vantaggio nel realizzare un sistema così articolato. Se già c'è uno SCADA, che scopo ha una board con MF? Non è più semplice bypassare lo SCADA e colloquiare direttamente con il FEZ? Questo soprattutto per il non indifferente sistema hardware necessario, che potrebbe facilmente essere ottimizzato.

I commenti su questo intervento sono chiusi.