Flusso In Ladder ... Ma Dai!

[Water]

ciao a tutti,

ho scoperto casualmente che il flusso in ladder

non si interrompe se il contatto è aperto

semplifico (di moltissimo) il problema:

|--|I0.0|---(Q0.0)

|

|--|I0.1|---(Q0.0)

a logica, se attivo l'ingresso I0.0 viene attivata l'uscita Q0.0

stessa cosa se attivo l'ingresso I0.1 ... ma non è così!!

se attivo SOLO l'ingresso I0.0 l'uscita Q0.0 rimane disabilitata!

anche se I0.1 è aperto il "flusso" mi disabilità l'uscita Q0.0

tralasciando l'inutilità dell'esempio, è la logica che mi rende perplesso,

in un programma strutturato con parecchi sottoprogrammi

l'abilitazione di un uscita o merker, potrebbe venire da diverse fonti

quindi risulta facile incappare nell'errore esposto sopra

premetto che sto parlando di Siemens S7-200 e MicroWin aggiornatissimo

ma penso che il discorso sia di carattere puramente generale

Giuseppe

[bigalex]

Direi che quanto hai esposto è assolutamente corretto .

Se infatti si attiva una uscita (o un merker) solo con istruzioni di comando tipo bobina ( --( )--| ) è solo l'ultimo comando in termini di elaborazione che prevale sui precedenti .

Pertanto come nel tuo esempio anche se attivi l'ingresso I0.0 e non attivi anche l'ingresso I0.1 l'uscita Q0.0 rimane a "0" .

Ciao

Bigalex

[lucios]

Occorre distinguere tra ladder e ladder....

In alcune macchine il flusso viene letto riga per riga (es. GE Fanuc), per cui il comportamento è effettivamente quello che descrivi.

In altre il flusso viene letto a colonne (nel tuo es. viene letto primas I0.0 poi I0.1), quindi procede a zig-zag per tutte le colonne, in questo caso il Q0.0 te lo troveresti a 1.

In ogni caso non è certo una buona regola di programmazione settare un relè in più posti.

Per questo ci sono in set-reset o, dove possibile, l'esecuzione condizionata di blocchi (segmenti) di programma. Ci sono anche i jump, ma in ladder non mi piacciono molto....

Ciao

[Piero Azzoni]

no lucios

in alcune macchine la rung viene eseguita in priorita' di riga

in alcune macchine la rung viene eseguita in priorita' di colonna

ma la rung successiva viene eseguita solo dopo la completa fine dell'elaborazione della precedente

in ogni caso non cambia nulla

la prima riga fa una cosa la seconda un'altra

se e' in contradizione rimane cio' che e' stato fatto dopo

[lucios]

in ogni caso non cambia nulla

Hai ragione . Nell'esempio fatto non cambia nulla.... sorry.

Bisogna stare attenti quando si utilizza nel secondo ramo un contatto di un relè di un ramo precedente, in quel caso si possono avere risultati non corretti.

Ciao

[batta]

Direi che il comportamento dell'uscita è assolutamente corretto.

Per precisare, tieni presente che se inserisci un segmento tra i due dell'esempio ed in questo segmento interroghi lo stato di Q0.0, leggerai lo stato dell'immagine di Q0.0 che sarà quello stabilito dalle condizioni del segmento precedente. Lo stato logico dell'uscita fisica verrà invece aggiornato a fine scansione, quindi assumerà lo stato dell'ultima assegnazione.

Se così non fosse, sarebbe un gran casino: controllando un segmento dove assegni uno stato OFF ad un'uscita e questa dovesse invece rimanere ON, non ti pare che sarebbe una situazione alquanto strana?

Per spiegarlo con un esempio:

Se in una stanza entrano una dopo l'altra un certo numero di persone, ed ogni persona a sua discrezione accende o spegne la luce, fino a quando ci sarà flusso di persone lo stato della luce continuerà a cambiare. Quando anche l'ultima persona sarà entrata avrà rilevanza solo l'operazione eseguita dall'ultima persona entrata.

[mynameisrex]

Se può interessare c'è una discussione aperta a rigurado, nel forum PLC/Siemens :

Marcia/arresto Plc S7-300 Kop... .!

Bye

[Luca Bab]

Questa condizione si puo' usare per salvare bit

io ne approfitto per fare dei segmenti cosi

|--|I0.0|---(m0.0)

|

|--|m0.0|---|I0.1|---(m0.0)

Ovviamente con molti piu' operandi

ciao

Luca

[Water]

ringrazio tutti per le risposte,

anche se in realtà ho fatto la domanda e mi son dato la risposta!

ma visto che la cosa è stata fonte per me, di un piccolo problema,

volevo solo metterlo in evidenza, evitando che qualcun'altro ci caschi,

diciamo che operando così, di fatto si crea un... "AND" occulto :ph34r:

ciao, Giuseppe

[Ecup]

Beh... la "bobina" è una sorta di assegnamento di varibile, quindi è logico che prevalga l'ultima. Anche in altri linguaggi di programmazione (tanto per fare un esempio stupido) se scrivi

i:=2;

i:=3;

prevale l'ultima istruzione

Se non ti piace puoi usare i Set e Reset, ma occhio a non incappare in situazini anomale (tipo merker che non riesci più a resettare)

[Water]

x Ecup

ok ... che prevalga l'ultima istruzione è assodato,

ma il discorso è un altro,

se rileggi il semplice esempio che ho postato

il "flusso" attraversa anche un contatto aperto!

quindi in "teoria", non stai assegnado un bel niente!

l'esempio funziona solo con le "bobine" (uscite dirette o merker)

mentre ed ovviamente altrimenti sarebbe un problema serio,

non ha alcun effetto su altre istruzioni (es. scrittura di una word)

ciao, Giuseppe

[Luca Bettinelli]

il "flusso" attraversa anche un contatto aperto!

quindi in "teoria", non stai assegnado un bel niente!

e qui ti sbagli, il contatto apero assegna a 0 lo stato del "Risultato logico combinatorio"

[lucios]

Quando apri l'interruttore la lampadina si spegne!

[walter.r]

e qui ti sbagli, il contatto aperto assegna a 0 lo stato del "Risultato logico combinatorio"

Mi associo a Luca: quello che dici, Water, è valido in elettromeccanica ( se un contatto "fisico" è aperto, alla bobina non arriva corrente ), ma non è valido in programmazione PLC.

Questo è un errore che in passato ho visto commettere spesso da chi ha iniziato a programmare avendo in precedenza realizzato solo quadri elettromeccanici.

[Water]

sul fatto che Luca abbia ragione non ci sono dubbi!!

il motivo di questo post è proprio quello di evidenziarlo

ed evitare che casualmente, qualcuno cada nell'errore

programmo PLC da molti anni e semplicemente non ci avevo fatto caso!

sicuramente qualcuno me lo avrà a suo tempo detto ...

ma la logica dei programmi che faccio non da spazio a questi errori,

il caso ha voluto che mi serviva, sul campo, una scorciatoia

per abilitare un uscita, mentre da un'altra parte ... e annidato ...

è successo più o meno quello esposto nell'esempio

stare a spiegare il perchè ed il per come sarebbe solo noioso ...

sicuramente come dici ha influito la parte elettromeccanica

anche perchè non provengo da questo settore ... ma ci appartengo!!!

ciao a tutti e buona continuazione

Giuseppe

[batta]

programmo PLC da molti anni e semplicemente non ci avevo fatto caso!

Sinceramente non capisco dove sia la stranezza.

Assegnare uno stato ad una bobina in due segmenti diversi non significa mettere in OR le condizioni scritte nel primo segmento con quelle scritte nel secondo (equivalente a mettere in parallelo in uno schema elettromeccanico), ma semplicemente fare due assegnazioni in due parti diverse del programma. Insomma, non basta attivarla in un punto qualsiasi del programma perché rimanga attiva.

Pensa che casino se fosse così. Potresti essere lì che guardi un segmento con un contatto NO a livello basso, e ti chiederesti perché quella maledetta bobina, direttamente a valle del contatto, si ostina a rimanere attivata.

L'immagine dell'uscita può cambiare più volte in una scansione. L'uscita fisica verrà invece aggiornata a fine scansione, ed assumerà quindi lo stato definito dall'ultima assegnazione.

Più normale di così...

[ifachsoftware]

Oltre a confermare quello gia' detto da Batta (che sottoscrivo i pieno) , volevo solo aggiungere che il fatto di mettere piu' bobine uguali in giro per il programma e' sicuramente da evitare in primis per evitare problemi di interpretazione del ladder (interpretazioni che possono variare da PLC a PLC ) ; sucessivamente per semplificare la leggibilita' di un programma ed infine perche' tale pratica genera degli errori su alcuni tipi di PLC ....

Ciao

[walterword]

probabilmente non hai ancora capito come funziona e come processa gli i/o un plc.

Intanto per iniziare le bobine dirette vanno scritte ua volta sola per comodita' di debug ect .

Poi devi sapere che le uscite vengono scritte alla fine dell'esecuzione del programma utente ,

in base al all'ultimo valore di esse .

Saprai bene che il plc scansiona dall'alto verso il basso e da sinistra verso dx , detto in parole poverissime , quindi avra' predominanza l'ultima assegnazione .

Ripeto che comunque scrivere piu di una volta una bobina dirretta e' indice di mal programmazione.

ciao

walter

[lucios]

Ripeto che comunque scrivere piu di una volta una bobina dirretta e' indice di mal programmazione.

Giustissimo!

A meno in quei casi dove si fa una logica a fasi, dove cioè si possono implementare e far svolgere al plc dei pezzi di programma dipendentemente dal valore, ad es., di una variabile. In questi casi può essere comodo

Ciao

[TravelMen]

Anche io sono pienamente d'accordo sul fatto di assegnare solo ed una sola volta l'uscita, ma se a qualcuno dovesse per "forza servire" allora:

|------------|I0.0|--------------(Q0.0)-----------|

|------------|I0.0|--------------(jpn via)---------|

|------------|I0.1|--------------(Q0.0)-----------|

|----|:via|-----------------------------------------|

..................................................................

:ph34r:

[walterword]

travel la tua proposta e' un arrampicarsi sui muri

non serve a niente , si assegna una volta sola se vuoi essere considerato un discreto programmatore

Questo non te lo dico io cosi perche non ho nient'altro da fare , ma perche e' cosi

Se devi usare dei passi a fasi usi tante bobine di una o piu Dword e alla fine se e' maggiore di zero vuol dire che almeno una e' a 1 ,anche se a dire il vero non dovrebbe mai essere maggiore di uno , cioe deve essere una condizione che mi da 1 la bobina finale .

Comunque poi ognuno programma come gli pare , o no ?

Il fatto e' che comunque per essere sempre dei discreti programmatori bisognerebbe scrivere

il codice in maniera commentato e chiaro , in modo tale che lo sfigato che ci mettera' poi le mani capisca quanto meno da dove iniziare

Si e' bravi quando anche gli altri capiscono, non solo quando si fanno andare le macchine o gli impianti a propria maniera e filosofia .

sempre opinioni personali

Modificato: 6 ottobre 2006 da walterword

[mynameisrex]

[si e' bravi quando anche gli altri capiscono, non solo quando si fanno andare le macchine o gli impianti a propria maniera e filosofia.]

...giuro che non ho mai trovato citazione migliore riguardo la "buona programmazione"...

Se un grande

[Luca Bab]

Si e' bravi quando anche gli altri capiscono, non solo quando si fanno andare le macchine o gli impianti a propria maniera e filosofia

Visto che ormai si riduce tutto in soldi e tempo , potrei aggiungere

Si è bravi quando si fanno andare bene le macchine , nella metà del tempo degli altri ( anche se non capiscono )

Ciao

Luca

[walterword]

il fatto di far andare le macchine non e' bravura , ma obbligo verso chi paga

che non pagherebbe qualora la macchina non funzionasse

Essere bravi e precisi e' un'altra cosa

Io non mi ritengo ancora bravo , pero ce la metto tutta ,e sinceramente quando vedo lavorare o leggere

codice di alcuni programmatori mi vien voglia di prenderli a calci in cu*o

Non a caso quando rivesto la carica di responsabile di automazione presso grandi linee e impianti , i programmatori fanno quello che dico io

I programmi si scrivono in diversi linguaggi , ladder , scl o ST , e talvolta anche S7-graph

Ogni linguaggio ha un suo appropriato utilizzo

Porcherie tipo fup o altro non le voglio nemmeno vedere

In una linea dove ci sono 3000-4000 I/O immaginate di dover risalire ad un baco o problema che sia se il software non e' ben commentato o chiaro ....

altra cosa molto importante e' l'organizzazione del software , con routine e funzioni che hanno nomi

ben precisi che facciano capire di cosa si tratta .

Queste cose sono molto importanti ,anche per se stessi , perc he poi di notte o dopo qualche mese

si perderebbero le tracce .

Di programmatori che si ritengon bravi perche fanno funzionare le macchine ce ne sono tanti , un po meno

sono quelli che lavoran bene .

Alcuni scrivono applicazioni giusto per la macchina cosi com'e' , poi bisogna aggiungere qualcosa o modificare e allroa li nascono i problemi perche il sw non prevede uno sviluppo capilalre o

elastico e allora si deve riscrivere il tutto che si fa prima

Poi ognuno e' sempre libero di fare quello che vuole , io per primo

ciao

walter

[mynameisrex]

Walter...

continuo a credere che tu sia il migliore !

Mi permetto di aggiugere un'altra piccola cosa...

non sempre un'automazione si esaurisce con la scrittura del suo programma o con il suo collaudo; spesso si protrae con assistenze, modifiche, revamping parziali...

E lì, se il codice non è più che comprensibile (e magari anche commentato !!!) sono veramente dolori...

Per concludere : queste maledette bobine... attiviamole una volta sola !!!!!!!

Buona giornata a tutti