Sw Per "trasformare" Un Pc In Plc

[fabio670]

Buongiorno a tutti.
Premetto che pur nascendo da un'esigenza reale questa discussione vuole essere anche uno spunto per la didattica.
Prima di porre la questione vorrei illustrarvi da dove nasce l'esigenza.
Ho uno smart reay zelio sul quale ho creato un programma in FBD, ho collegato poi all'interrfaccia seriale un modulo
seriale/ethernet di terze parti e, tramite il protocollo di comunicazione illustrato sul manuale ho realizzato su un pc
un'interfaccia di monitoraggio/controllo.

Ora, dovendo eseguire calcoli di difficile programmazione sul plc mi sono chiesto: ma se, tralasciando la questione
sull'affidabilita' di un PC, il real time e quant'altro, sposto tutta la  logica sul PC e uso lo zelio solo come modulo I/O?
D'altra parte esistono moduli I/O su modbus ethernet quindi questa mia idea e' gia' qualcosa di consolidato.

Il problema e' nato nel momento della programmazione:

1. come trasformo il mio programma FBD in qualcosa come C o python ?
2. anche volendo riscriverlo pur essendo possibile (d'altra parte nel plc si trasforma sempre in una sequenza di istruzioni) non
risulta agevole: c'e' qualche sw che puo' venire in aiuto?
3. esistono sw che installati su PC lo trasformino in PLC prendendo in pasto un codice in FBD o simile?
4. oppure esistono sw che trasformano un FBD in un qualcosa di simile ad un linguaggio di programmazione "C-style"?

Ovviamente essendo mosso piu' da curiosita' che da una reale esigenza, nel caso in cui questi sw esistano preferirei soluzioni non
professionali da costi elevati.

Scusate per il basso livello delle mie domande ma pur avevndo letto molto ed avendo forse trovato qualcosa non riesco a chiarirmi
fino in fondo le idee.


Grazie
Fabio
 

[Livio Orsini]

esistono sw che installati su PC lo trasformino in PLC prendendo in pasto un codice in FBD o simile?

 

Esistono dei sistemi dove il PC ha solo funzione di ospite e di HMI.

Una scheda ospite del PC svolge le funzioni tipiche del PLC e comunica tramite bus di campo con le periferiche di I/O.

Diversi construttori di di I/O, periferiche, morsetti, etc. come Phoenix ed altri hanno in catalogo questi PLC.

Sono dispositivi validi ed affidabili.

La convenienza economica va valutata in funzione delle esigenze di impianto ma spesso, a parità di complessità, risulta esserci un rapporto favorevole a questo tipo di soluzione.

 

 

tralasciando la questione sull'affidabilita' di un PC,

 

A mio giudizio non è possiible tralasciare questa questione.

Se si pensa ad un'applicazione professionale non si può prescidere dal mettere al primo punto l'affidabilità e la disponibilità del sistema di controllo.

Se invece si sta ipotizzando un'applicazione amatoriale è una questione completamente differente.

 

come trasformo il mio programma FBD in qualcosa come C o python ?

 

Dipende in quale linguaggio è stato scritto il Sw PLC.

In genere non c'è nessuna corrispondenza automatica tra il programma scritto per PLC e programma in "C". Anche usando linguaggi PLC ad alto livello come SCL o grafcet si deve compiere la trasposizione in modo manuale. Almeno io non sono a conoscenza di transcodificatori automatici.

[fabio670]

Ciao Livio,

grazie della risposta molto chiara, scusami se "insisto" ma e' solo per comprendere meglio.

Per approfondire l'argomento, ricordo di aver visto PC industriali con sistema operativo unix-like real-time che venivano usati per macchine di taglio a controllo numerico ma non so come venissero programmati. Se uso linguaggi ad alto livello come SCL o grafcet c'e' poi un "emulatore" da far girare su PC al quale passargli il codice?

Per esempio ho visto anche codesys (che non ho ancora capito bene cos'e' di preciso !!) addirittura per raspberry ma non ho capito se poi il raspberry diventa un modulo controllato da un PC principale o se diventa un PLC indipendente.

Per quanto riguarda l'affidabilita' mi chiedevo, a livello ditattico, come potessi sperimentare sul PC di casa una programmazione per PLC ad alto livelllo e poi chiaramente trasferirla in ambito industriale su soluzioni professionali.

 

Grazie ancora

Fabio

[lelos]

ciao

anche se l'articolo è vecchio , secondo me è valido ancora oggi.

http://www.controleng.com/single-article/inside-machines-pc-versus-plc-comparing-control-options/9bf8690c6f23b11370bec90b52cb15c9.html

 

 

spero possa chiarirti i problemi principali

[Livio Orsini]

Per approfondire l'argomento, ricordo di aver visto PC industriali con sistema operativo unix-like real-time...

 

Non è solo un problema di SO, è anche e molto un problema di affidabilità Hw.

Siemens una ventina di anni fa aveva un ottimo PC industriale, con un RTOS veramente affidabile. Il sistema usava tutte le periferiche dello S7-300 ed era conveniente quando si dovessero affrontare problemi di regolazione complessa con prestazioni elevate.

Venne abbandonato perchè la maggior parte degli utilizzatori di S7 non era in grado di utilizzare il suo RTOS.

 

Oggi con raspberry ed arduino che si programamno facilmente anche da persone pressochè digiune di programamzione sembra che con questi dispositivi si possa fare facilmente qualsiasi cosa.

Finche si stà in ambienti protetti funziona tutto. Quando si comincia ad andare nelmondo reale incominciano le difficoltà.

 

Forse è un bene che non ci sia una corrispondenza automatica tra programmi sviluppati per PLC e programmi per PC et similia; è una sorta di deterrente che sconsiglia certe sconsideratezze.

 

come potessi sperimentare sul PC di casa una programmazione per PLC ad alto livelllo

 

Nei pacchetti di sviluppo per Sw PLC, invero molto costosi, sono anche compresi degli ottimi simulatori con cui puoi fare quello che intendi.

[accacca]

 

sposto tutta la  logica sul PC e uso lo zelio solo come modulo I/O?

Uhmm la comunicazione sarà anche veloce ma un'architettura del genere ti penalizza sicuramente le prestazioni

Può andare bene per processi lenti dove le cose cambiano con molta calma ma pensa di dover leggere

dei segnali ad esempio di encoder a 50KHz devi continuamente inviare al pc dati

Come ti è stato detto il sistema operativo poi ci mette di suo Parlo per esperienza diretta su ethernet

se un socket aperto sul PC riceve troppi dati e non riesce a gestirli il sistema ti blocca temporaneamente il socket

impedendo altre trasmissioni. 

Direi che  l'architettura PC-cavo-I/O è utilizzabile in semplici start stop o processi a gestioni tranquilla.

[fabio670]

Per lelos,

grazi del link e' stato molto interessante.

 

Per accacca,

certo, processi veloci non potrebbero essere gestiti con questa modalita' e nel mio caso (processo lento) il protocollo dello zelio funziona con domanda/risposta per cui e' il PC che inizia la comunicazione e non c'e' pericolo di saturare la coda di ricezione del PC. Io ho preso spunto da una esigenza "domestica" per cercare di allargare le mie conoscenze ma credo ci siano molti processi industriali in cui i tempi non sono cosi' stringenti (il riscaldamento/raffreddamento di grosse masse, il lavaggio di un serbatoio). Una domanda:  ad esempio i moduli di I/O della Wago su modbus TCP  hanno una logica interna o funzionano come il mio zelio (ovviamente in modo piu' professionale)?

 

Per Livio,

tutto chiaro: la mia intenzione era quella di capire se riuscivo a programmare su un pc, usando le mie conoscenze di programmazione classiche, per controllare un processo lento in ambiente domestico con un linguaggio di programmazione piu' orientato all'automazione... mi sembra di capire che dovro' rinunciarci.