pneumatica e plc

[pascal98]

Salve a tutti sono nuovo nel forum! Sono uno studente di ingegneria meccanica, appassionato di automazione. Nel mio piano di studi ho inserito un esame di oleodinamica e pneumatica, e mi chiedevo se ci fosse qualche libro o guida che potete consigliarmi per avviarmi alla programmazione PLC di sistemi pneumatici. Vi ringrazio in anticipo.

[Marco Mondin]

Se conosci la pneumatica non credo che ti serva un testo specifico. Basta una infarinatura blanda blanda di un sistema PLC.
Alla fine servono giusto 2 stupidaggini. Saper scalare una analogica per i trasduttori di pressione, saper gestire degli IO. Il resto è banale.
Puoi cercare con il motore di ricerca stra usato nel mondo "CODESYS Beginners Tutorial", poi passi alla guida online per sapere tutto ciò che puoi fare.
Ti consiglio CODESYS in quanto è tra i pochi che ti permette di fare i primi paciocchi a gratis (tempo limitato 2 ore del runtime demo e ambiente di sviluppo gratuito) ed è quello che si attiene di più allo standard IEC61131-3 V3.
A livello universitario poi puoi usarlo su un raspberry PI con il suo GPIO, che è anche ben visto a scopo didattico.
Poi puoi passare a cosa ti sembra più utile, per esempio SIEMENS, visto che hai scritto qua.

Modificato: 28 dicembre 2020 da Marco Mondin

[pascal98]

4 ore fa, Marco Mondin ha scritto:

Se conosci la pneumatica non credo che ti serva un testo specifico. Basta una infarinatura blanda blanda di un sistema PLC.
Alla fine servono giusto 2 stupidaggini. Saper scalare una analogica per i trasduttori di pressione, saper gestire degli IO. Il resto è banale.
Puoi cercare con il motore di ricerca stra usato nel mondo "CODESYS Beginners Tutorial", poi passi alla guida online per sapere tutto ciò che puoi fare.
Ti consiglio CODESYS in quanto è tra i pochi che ti permette di fare i primi paciocchi a gratis (tempo limitato 2 ore del runtime demo e ambiente di sviluppo gratuito) ed è quello che si attiene di più allo standard IEC61131-3 V3.
A livello universitario poi puoi usarlo su un raspberry PI con il suo GPIO, che è anche ben visto a scopo didattico.
Poi puoi passare a cosa ti sembra più utile, per esempio SIEMENS, visto che hai scritto qua.

Ciao, intanto ti ringrazio per la risposta. L'esame devo ancora sostenerlo quindi non conosco ancora a fondo la pneumatica. Per quanto riguarda Codesys sono solo due ore gratis? Diciamo che vorrei imparare siemens perché è quello più diffuso sul mercato e credo che possa darmi una marcia in più nel mondo del lavoro (correggimi se sbaglio). Accetto altri consigli riguardo ai linguaggi da imparare per lavorare in questo settore, ti ringrazio ancora

[Marco Mondin]

22 minuti fa, pascal98 ha scritto:

Per quanto riguarda Codesys sono solo due ore gratis? Diciamo che vorrei imparare siemens perché è quello più diffuso sul mercato e credo che possa darmi una marcia in più nel mondo del lavoro (correggimi se sbaglio). Accetto altri consigli riguardo ai linguaggi da imparare per lavorare in questo settore, ti ringrazio ancora

2 ore per ogni sessione, riavvii il runtime e riparte.

I PLC si somigliano tutti. Passare da uno all'altro è banale. Ci sono solo limitazioni imposte dalle marche chi più chi meno.

[Livio Orsini]

9 ore fa, Marco Mondin ha scritto:

I PLC si somigliano tutti. Passare da uno all'altro è banale.

 

Non sono completamente d'accordo.

Che i PLC superficialmente si somiglino tutti è vero, però ogni costruttore ha i suoi modi particolari di affrontare e risolvere determinati problemi applicativi.

Anche i PC sono tutti, praticamente simili,ma se sul medesimo PC installi Win o Linux, costruire applicazioni diventa molto differente.

 

10 ore fa, pascal98 ha scritto:

orrei imparare siemens perché è quello più diffuso sul mercato

 

Sicuramente Siemens in Europa ha una posizione dominante, a mio parere non tanto per la validità tecnologia ma grazie ad un'abile politica commerciale iniziata oltre mezzo secolo fa, unità ad una robustezza finanziara notevole. Specializzarsi su prodotti siemens sicuramente da vantaggi iniziali però ti mette in concorrenza con una moltitudine di programmatori.

[pigroplc]

15 ore fa, pascal98 ha scritto:

e mi chiedevo se ci fosse qualche libro o guida che potete consigliarmi per avviarmi alla programmazione PLC di sistemi pneumatici

imparare a programmare la parte di PLC che comanda un circuito pneumatico oppure oleodinamico presuppone la conoscenza del circuito da comandare. Le marche più utilizzate sono Festo per la pneumatica e Bosch-Rexroth per la parte oleodinamica, ed entrambi hanno loro PLC dedicati per completare il quadro della fornitura.

Se tu provi a contattare i centri di addestramento di entrambe le aziende potresti ottenere delle dispense sulle quali studiare.

 

 

 

10 ore fa, pascal98 ha scritto:

Diciamo che vorrei imparare siemens perché è quello più diffuso sul mercato

entrambe le marche hanno interfacce Profibus e Profinet per rendere i propri prodotti utilizzabili con il resto del mondo, ma politicamente sia meglio comprendere il sistema completo visto che ogni costruttore spinge i propri prodotti. Inoltre serve a farti un'idea di quello che sono i sistemi programmabili al di fuori di Siemens (e ti posso assicurare che non sono affatto malaccio, anzi....).

[Marco Mondin]

26 minuti fa, Livio Orsini ha scritto:

Non sono completamente d'accordo.

Che i PLC superficialmente si somiglino tutti è vero, però ogni costruttore ha i suoi modi particolari di affrontare e risolvere determinati problemi applicativi.

Oggi diciamo che abbiamo CODESYS ed i suoi derivati (Schneider, ABB, Beckhoff, Exor, Esa, Wago, ... sono un'infinità non me ne vogliano se non li elenco tutti), che è quello che pone meno limiti. Ci si fa praticamente tutto quello che si fa con gli altri.
Abbiamo B&R che vive nel suo mondo, ma pone pochi limiti.
Poi abbiamo SIEMENS ed OMRON che se si usano le loro librerie hanno un sacco di pappa pronta, ma tendono a vincolare al loro mondo. Commercialmente è una scelta comprensibile, ma io non simpatizzo per chi cerca di vincolarmi al suo mondo.
A livello didattico, per non crescere con i paraocchi io consiglio sempre CODESYS, ma è una cosa molto soggettiva scaturita da mie valutazioni fortemente soggettive.

 

Quote

Anche i PC sono tutti, praticamente simili,ma se sul medesimo PC installi Win o Linux, costruire applicazioni diventa molto differente.

Oggi anche in questo settore scegliendo ambienti giusti inizia ad esserci convergenza.
Un tempo era una affermazione verissima, poi arrivò JAVA che rompeva in parte le differenze tra gli OS installati, ma pregiudicava le prestazioni, ed in alcuni casi non era accettabile.
Oggi abbiamo Framework come QT, che per altro sono molto flessibili come licenze GPL, LGPL, commerciale per piccole aziende e commerciale enterprise, che permettono di sviluppare in C++ con la sua potenza, che se da un lato è sul podio come il linguaggio più complesso, dall'altro è sul podio dei linguaggi più potenti, ma dal'altro offrono talmente tante API che permettono di usare di tutto (Dai widget, ai databases relazionali, ai file, ai socket, a semplici BUS di campo come MODBUS, e molto altro) con sorgente unico compilabile su Windows, Linux, MacOS, iOS, Android, QNX, VXWorks, BSD e qualunque cosa per cui ci sia un MSVC, un GCC o un CLANG.
Molti linguaggi moderni come Python e JavaScript, ormai sono intercompatibili tra tutti gli OS, e direi menomale.
Per fortuna molti sviluppatori si sono resi conto che unire le forze è più produttivo che frammentarle.
 

Quote

Sicuramente Siemens in Europa ha una posizione dominante, a mio parere non tanto per la validità tecnologia ma grazie ad un'abile politica commerciale iniziata oltre mezzo secolo fa, unità ad una robustezza finanziara notevole. Specializzarsi su prodotti siemens sicuramente da vantaggi iniziali però ti mette in concorrenza con una moltitudine di programmatori.

SIEMENS è dominante, ma anche qua ci sono dei se e dei ma.
Lo è nei grandi impianti e nelle linee, ma come hai giustamente osservato tu è anche dove ci sono più integrator e sviluppatori, e questo indica tanta concorrenza.
È una direzione in cui secondo me c'è più offerta che domanda e questo seguendo la classica legge di mercato ha le sue conseguenze.

Nella costruzione di singole macchine, il mercato è invaso da centinaia di piccoli produttori, la maggior parte dei quali per non riscoprire l'acqua calda oggi si appoggia a CODESYS a differenza degli anni '90 in cui si facevano tutto da soli. Tra quelli non piccoli Beckhoff che con il suo Twincat, che è un CODESYS esteso ogni anno erode quote enormi proprio a SIEMENS.
In questo settore la domanda, almeno per ora supera l'offerta, ed anche se è richiesto sovente un livello di specializzazione più spinto, mettendoci un po' di impegno secondo me si possono raccogliere frutti più succosi.

Tuttavia sono solo considerazioni personali.

[Livio Orsini]

1 ora fa, Marco Mondin ha scritto:

Oggi abbiamo Framework come QT,...

 

Non credo che tu possa portare senza alcuna modifica un programma scritto per Win sotto linux o Mac. Che le modifiche sian minime o massime son comunque modifiche, inoltre se non conosci bene lo SO che vai ad usare son comunque dolori.

 

Discorso simile per i PLC. In Europa Siemens assorbe oltre il 50% delle applicazioni. Quello che svilupopi per l'ambiente Siemens non lo porti su altri PLC e viceversa, tranne alcuni PLC come VIPA, che son nati proprio come succedanei di Siemens.

 

 

[max81]

Ciao,

un libro che mi è stato molto utile sull'argomento, molti anni fa, è Comandi automatici - Massimo Barezzi

[Marco Mondin]

2 ore fa, Livio Orsini ha scritto:

Non credo che tu possa portare senza alcuna modifica un programma scritto per Win sotto linux o Mac. Che le modifiche sian minime o massime son comunque modifiche, inoltre se non conosci bene lo SO che vai ad usare son comunque dolori.

Fidati... Oggi esistono Framework che lo permettono...

Questo è un esempio di un lavoro che sto debugguando in questo momento (Ho oscurato per privacy il nome del committente):
Un tool di backup di ricette per un tornio che abbiamo sviluppato.
Usa Database MySql, SQLite e Socket TCP.
Il team QT si è impegnato moltissimo per creare un framework che permettesse una totale portabilità indipendente dall'OS trasparente per lo sviluppatore medio.
Per fare un esempio buttato lì, l'oggetto QSettings, permette di salvare con coppie KEY<->VALUE [Stringa<->Variant] valori di setup di un applicativo.
Su Windows lo fa nel registro di sistema, su linux nella cartella .config, si adatta al sistema operativo che sta sotto in modo totalmete trasparente...
Tuttavia sto andando troppo OT... Ti chiedo scusa...
Il sorgente è lo stesso, in C++, non una riga di codice diversa. Compilato su KUbuntu/Linux con GCC e Windows 10 con i compilatori MSVC 2015.

[lelos]

ciao

vuoi solo fare teoria o anche pratica ?

[lelos]

20 ore fa, Marco Mondin ha scritto:

I PLC si somigliano tutti. Passare da uno all'altro è banale. Ci sono solo limitazioni imposte dalle marche chi più chi meno.

Questo è abbastanza vero , chi utilizza un plc (e sa programmare i  plc) passare ad un'altro non fa molta fatica.

La differenza sta a che livello fai automazione. Ogni plc oltra alle istruzioni base di contatti ,timer , contatori ,shift ,ecc offre una libreria fi funzioni che ha solo lui e che se la utilizzi ,allora il passaggio ad un'altra marca , a parità di programma , richiede uno pò più di sforzo , ma niente di spaventoso

Ci sono plc che usano sia il loro ambiente di programmazione oppure codesys. (non esiste il convertitore tra uno e l'altro).

Ma allora cosa usare ???

Non esiste una regola precisa....

Se l'automazione è piccola e "lenta" si può pensare di usare un pannello hmi con codesys (ci sono svariate marche tra cui scegliere) ,

Se l'automazione comprende robot ,  motion con 100 assi  che devono andare in fase con i robot o tra di loro , bus di campo con oltre  200 remotati da 32 in/out  ,analogiche ,sistemi di visione , e l'automazione deve essere veloce (quindi non di processo)  allora scordati di usare codesys , ma non perché non funzionerebbe , ma perché devi dipendere da bus proprietari perché devi andare veloce . 

Poi dare un definizione di veloce è strettamente legata all'automazione che devi fare o che sei abituato a fare.

Per esempio se hai 16 assi e devi fare 250 posizionamenti per ogni asse al minuto (naturalmente la giusta meccanica ), a passo di 10mm,e gli assi devo essere sincroni ,  per alcuni potrebbe essere veloce , per altri normale per altri non sufficiente.

Non esiste un plc che soddisfi tutte le esigenze ,non esiste un solo  linguaggio di programmazione per i plc che soddisfi tutte le esigenze .

Esiste quello che risolve il tuo problema . Siemens , Omron , ABB, Beckhoff , Mitsubishi , tra loro c'è quello più usato ,Siemens , ma Siemens non fà tutto al meglio.

Focalizzarsi su una sola marca o sistema di programmazione o bus di campo , ecc.. limita le possibilità di fare automazioni al meglio.

Ognuno porta la sua esperienza , nel suo campo , con i suoi anni di lavoro , ma NESSUNO ha visto tutto il mondo dell'automazione.

Anche ciò che ho scritto è basato sui miei 35 anni di esperienza tra varie marche , linguaggi e sistemi.

 

Modificato: 29 dicembre 2020 da lelos

[Marco Mondin]

 

18 minuti fa, lelos ha scritto:

Se l'automazione è piccola e "lenta" si può pensare di usare un pannello hmi con codesys (ci sono svariate marche tra cui scegliere) ,

Se l'automazione comprende robot ,  motion con 100 assi  che devono andare in fase con i robot o tra di loro , bus di campo con oltre  200 remotati da 32 in/out  ,analogiche ,sistemi di visione , e l'automazione deve essere veloce (quindi non di processo)  allora scordati di usare codesys , ma non perché non funzionerebbe , ma perché devi dipendere da bus proprietari perché devi andare veloce . 

Beh! Un HMI con Codesys integrato alla carlona si.
Un Codesys, su PC industriale, con Core separati e master Ethercat tiene testa a molti...
Che sia il Runtime RTE o un Runtime Linux SL con CPU Pinning e Kernel RT, noi stiamo sotto i 100us di Jitter, con ciclica a 1ms.
A livello personale nei miei test lo ho spinto tranquillamente a 250us di ciclica monitorando con un oscilloscopio il comportamento senza perdere un colpo per ore.
Lo ho anche spinto a 50us di ciclica ma perdevo circa il 5% dei pacchetti ethercat, ma è inutile.
Per il 99.98% delle applicazioni basta ed avanza andare a 1ms, in rari casi 500us o 250us, ma sono davvero rari.

Monitor task sul tornio:


Test pesonale (Non è proprio una sinusoide, avevo sotto mano una analogica 0-10 e l'ho fatta solo positiva)
Mi interessava monitorare la latenza tra ingresso ed uscita ricampionando l'uscita con un modulo IO ethercat.
Spinto a 50us di ciclica

P.S. con il tornio sviluppato di recente che controlla 5 assi, di cui uno idraulico con anello di posizione idraulico, anello di pressione ed interpolatore sviluppato da noi in ST in quanto non c'era nulla di fatto per il controllo idraulico di precisione, 128 uscite digitali, 96 ingressi digitali una manciata di analogiche, tutto in ethercat, giriamo ad una media di occupazione di 50-60us per la ciclica da 1ms e 60-80us per quella da 10ms. E' vero che abbiamo un I5 con 4 core di cui 2 staccati dal Kernel Linux RT e dedicati solo al runtime, ma non mi pare proprio lento... Con un NY5 omron non si raggiungono le stesse prestazioni, non ci avviciniamo neppure.

 

 

Modificato: 29 dicembre 2020 da Marco Mondin

[Livio Orsini]

12 ore fa, lelos ha scritto:

ma NESSUNO ha visto tutto il mondo dell'automazione.

 

Condivido e la mia esperienza inizia da quando le automazioni si effettuavano solo con logiche a relè.