Simulazione PLC Esercizio n,4

[Narcolex]

Si, in effetti avevo inserito FCB nel commento ma non nello schema.. scusa :) ...
ho corretto FCB anche nel COUNTER, quindi non utilizzo quel contatto a freccia
( di cui però disconosco il significato ) .. e metto semplicemente il contatto
FCB per conteggiare le volte in cui FCB viene attivato.

04.png (5.98 KiB) Visto 4055 volte

Come dicevo vorrei chiarire i problemi che possono nascere dall'inversione,
ma attendo che tu non abbia più dubbi sulle fasi. Me lo confermi?

Se lo schema è corretto te lo confermo :) ....

Riguardo l'inversione, credo che forse si potrebbe inserire un timer, che ritardi leggermente
l'inversione, per evitare eccessive sollecitazioni al meccanismo, ma non so se ti riferivi a questo.

[g.schgor]

No, lo schema di FaseBA è ancora sbagliato:
l' FCB va messo nelle condizioni di inizio fase (prima del contatto di ritenuta)
Ma non dovrei essere io a dirti se è giusto o sbagliato:
se fai la simulazione dovresti accorgerti tu stesso dell'errore...

[Narcolex]

ok..

fase5.png (5.97 KiB) Visto 4044 volte

[Narcolex]

A me così funziona, anche il counter sembra andare, ho fatto la prova ad avviare per 3 volte FCB e dopo 3 volte si attiva, quindi dovremmo esserci.

[g.schgor]

Si, infatti così va bene.
Ed ecco le osservazioni sull'inversione di marcia.
E' abbastanza facile vedere che se nel programma "viene prima"
la fase che è disattivata dalla successiva, vi è una
sovrapposizione delle 2 fasi che dura un tempo di scansione del PLC.
Se queste comandassero direttamente le uscite si avrebbe una
contemporaneità di due comandi contrapposti. Questa in essenza
è la critica fatta da Candy all'Esercizio n.1.
Una volta noto il problema è tuttavia facile porvi rimedio: in molti casi
(dove non vi siano inversioni ripetute, come in questo esercizio)
per eliminare la contemporaneità basterebbe invertire l'ordine
delle fasi, ma spesso basta interbloccare fra loro i comandi delle uscite
(come appunto fatto nell'Esercizio n.1).
Nei moderni impianti industriali a ciascun motore corrisponde un
"cassetto" di MCC (Motor Control Center) che realizza elettromeccanicamente
tutte le protezioni e gli interblocchi necessari alla sicurezzadi funzionamento
del motore (quindi questo compito non è demandato al PLC).

La precauzione migliore tuttavia rimane quella di prevedere un tempo di pausa
fra le inversioni per dare il tempo al motore di fermarsi prima di invertire il movimento.
Nel presente esercizio basta infatti prevedere tempi di qualche secondo
all'arrivo sui sensori di posizione.

[Candy]

Se vogliamo parlare di automazione e di programmi ladder, leggibili, manutenibili, (in senso lato), allora bisogna anche seguire un logica in questo.
Una sequenza ladder la si scrive in modo da poter anche essere riletta, corretta, animata.
Le varie network si susseguono in modo logico, senza mescolarsi, suddividendo il programma in macro blocchi.
Venendo al concreto e tralasciando tutto il resto di un teorico programma, avremo un task per il sequenziatore, che partirà dal primo passo, fino all'ultimo, seguento il naturale evolvere del ciclo:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

E successivamente, in altro task, avremo la parte di codice per le attuazioni:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Dove io nel primo esempio ho messo il bit cumulativo "bTransition1" si può immaginare l'esploso di tutte le condizioni che producono la transiszione al passo 2.

Il cambio passo avviene sempre accertandosi di commutare, resettando quello precedente e settando il successivo. Nelle task di attuazione, poi, se occorre si usaranno i merker di più passi per attuare il comando voluto.

Non c'è nessun compilatore di codice Grapcet, (di quelli che ho usato), che si dimentichi, durante una transizione, di resettare il passo d'uscita. Oltre che una probabilissima fonte di errore, è una bruttura spaventosa.

Se si prendono cento programmatori, di fronte allo stesso compito, si otterranno cento programmi diversi. Questo è pacifico. Ed è pacifico che il programma migliore sarà quello anche più leggibile, malleabile alla manutenzione, animabile con rapidità.

Un ultimissima nota: è da venti anni e forse più che mi occupo di impianti industriali. Ho visot un unico MCC,desueto, che nessuno voleva. Ho invece visto ante, ante ed ante di minicontattori, contattori, inverter ed azionamenti, ed è bene che il programma PLC sia molto ben fatto, perché nessuno risolverà mai i problemi del programmatore, anzi, davanti ad un problema se non lo risolverai, ti schiacceranno.

[Narcolex]

La precauzione migliore tuttavia rimane quella di prevedere un tempo di pausa
fra le inversioni per dare il tempo al motore di fermarsi prima di invertire il movimento.

Come? con un timer va bene?

[g.schgor]

Sì un timer attivato dal sensore di arrivo va bene,
Ovviamente la fase seguente dovrà essere attivata dalla fine del timer.

[Narcolex]

Quindi di norma si inserisce un timer per ritardare l'inversione, oppurre ci sono altri escamotage per inserire un ritardo ( escludendo quelli già illustrati ).

[Candy]

Qui hai due problemi:
1) Quello logico: una volta rilevato il sensore, devi fermare la marcia in una direzione, attendere che il rotore del motore sia fermo, ed attivare la marcia in direzione opposta. Ed il tutto non solo per evitare di attivare due contattori contemporaneamente.
2) Quello meccanico: una volta rilevato il sensore, fermi la marcia in una direzione per un certo tempo, e ti si aprono due scenari.
2.1) Il motore avanza ancora per inerzia e, come spesso accade, fa abbandorare la posizione al sensore che lo aveva rilevato.
2.2) Sempre perché avanza ancora per inerzia, tra l'altro, sovente, nel caso di assi, va ad urtare contro arresti meccanici.

Non dico la 2.2.), ma non omettere ti tenere in buona considerazione la 2.1).