Utilizzo Dell'ingresso "e" Nella Bobina Di Uscita

[fabmatt]

Sto leggendo un programma e mi sono ritrovato queste righe

U E5.0

U T1

= E5.0

Questa è una delle tante righe che trovo nel programma, cosa significa? Come fa ad utilizzare un ingresso come uscita?

Grazie.

[batta]

Lo stato dell'ingresso E5.0 viene letto all'inizio della scansione (immagine ingressi).

Lo stato di T1 è in grado di influenzare lo stato di E5.0 dal punto in cui è richiamata l'istruzione fino alla fine del programma.

Senza entrare nel merito della motivazione di una simile istruzione, io avrei scritto:

UN T1

R E5.0

Con Siemens (non tutti i plc lo permettono) è possibile da programma scrivere lo stato anche degli ingressi.

Un semplice esempio dell'utilità di tale operazione:

Valvola con finecorsa di posizione. Riesci a collaudare il software, completamente scollegato dall'impianto, simulando lo stato degli ingressi dei finecorsa.

[Livio Orsini]

Per completezza dell'informazione. Scrivere lo stato di un ingresso modifica il registo immagine degli ingresi ma, ovviamente, non può modificare lo stato fisico dell'ingresso.

[Simone70]

Aggiungo una puntualizzazione. Lo stato dell'ingresso condizionato da T1 è preso in considerazione solo nella parte di programma successiva all'istruzione; nella parte precedente lo stato dell'ingresso preso in considerazione dal programma è quello fisico collegato al PLC.

[ricki]

Per me è una boiata.... non ha nessun senso forzare un ingresso che nel programma plc può controllare funzioni vitali alla macchina che stai gestendo.

Se proprio lo vuoi forzare, lo appoggi su di una M e ti gestisce la M come ti pare e piace.

Ciao

Ricki

[dott.cicala]

Per me invece quando si utilizzano certi inghippi si è nella M..... ed hai voglia a gestirla....

Ovviamente scherzo...è la M che mi ha ispirato...

[OB1-Roby]

Come di dice giustamente batta, una cosa del genere è molto utile in fase di debug del sw. Solitamente, quando ho a che fare con impianti con, ad esempio, valvole con finecorsa di apertura e/o chiusura, creo un fc all'interno del quale "simulo" i sensori scrivendo una serie di:

U A0.0

= E0.0

dove A0.0 è il comando della valvola ed E0.0 è chiaramente il suo sensore di apertura.

Con questo piccolo stratagemma riesco a simulare la quasi totalità dei cicli dell'impianto restando seduto alla scrivania in ufficio, avendo poi ovviamente cura di eliminare tale fc in fase di collaudo vero e proprio!

Il programma che stai leggendo, se proviene da un impianto funzionante, potrebbe essere il risultato di una pensata, diciamo così, poco ortodossa, altrimenti, come ti ho accennato, potrebbe avere un senso.

Ciao

[rddiego]

un senso ce l'ha eccome...

ha tutta l'aria di essere un filtro dell'ingresso utile per esempio contro i falsi contatti o cose del genere.. Sarebbe bello sapere come viene attivato T1

secondo me avrebbe un senso se fosse

U E5.0

SE T1

U E5.0

U T1

= E5.0

oppure attivare T1 con una qualsiasi condizione dopo la quale ci si deve aspettare E 5.0

io copio sempre gli ingressi, ma nulla toglie che così un senso ce l'ha

[ricki]

Ok rddiego, metti che pure sia un filtro, ma io torno a dire che non è una cosa logica forzare un ingresso fisico. Se lo voglio filtrare , lo appoggio se un T e se vuoi su una M.

U e5.0

l s5t[at]3s

se t1

u t1

= m0.0

ps : se utilizzi una forzatura su un ingresso, cosa succede dell'inizio OB1 all' utilizzo effettivo di =E5.0 ?

Ciao

Ricki

Modificato: 19 dicembre 2006 da ricki

[Simone70]

Un'altro utilizzo tipico è quando si ha un attuatore che viene montato NC invece che NO (o viceversa). Invece di andarlo a sostituire in tutto il programma è sufficente mettere

UN E 0.0

= E 0.0

sull'OB1 ed il gioco è fatto.

Altro uso che a volte uso è quello di ritardare o mettere dei tempi di mantenimento su dei segnali

ES.

U E 0.0

L S5T#300ms

SE T 0

U T 0

= E 0.0

oppure

U E 0.0

L S5T#300ms

SA T 0

U T 0

= E 0.0

[ricki]

Ciao Simone 70, con forzature del genere cosa ti ritrovi online con una VAT ? il valore vero dell'ingresso oppure un valore fittizio ? .... Livio dicci la tua .....

Ciao

Ricki

[rddiego]

io come già detto copio sempre gli ingressi su altre variabili e qui chiudo perchè ciascuno fa ciò che crede ma

non è una cosa logica forzare un ingresso fisico

non ti devi intestardire pensando sia qualcosa di fisico... è pur sempre una variabile come tutte le altre sia M sia DB

poi non è un forzamento non confondiamoci coi termini.

e ad ogni modo d'accordo o no gli esempi di simone70 sono proprio quelli che fanno al caso della nostra discussione

[rddiego]

nella VAT trovi sempre l'ultimo valore quindi nei nostri esempi sempre un valore non corrispondente alla realtà

ma non fa differenza questo perchè vale per tutte le variabili scritte magari duecento volte in tutto il programma

ed in un dato punto del programma la vat non ti dice che valore ha..

piuttosto vai online con la singola FC e lì saprai i valori in quel dato punto

[ricki]

Ok rddiego, mettiti nei panni di fabmatt, che ha un impianto fermo e ha un fucile puntato dalla direzione che con un cronometro gli sta contando il downtime... va online con una vat e si trova Roma per toma ingressi a 1 invece sono a zero , magari un ingresso che sfarfalla ma non lo vede perche in giro per 80 Kb di software c'è un filtro che mi forza un ingresso . Allora il caro fabiomatt non puo che cancellare le prime 3 lettere del suo nickname e diventare "matt" . Il mio è solo un parere : è contropruducente forzare un ingresso , anche in sede di test. ( a tutti puo capitare di dimenticarsi una "forzatura" in giro per il programma )

Ciao

Ricki

[rddiego]

è contropruducente forzare un ingresso

torno a dire che è incorretto parlare di forzatura che è tutt'altra cosa

ribadisco che bisogna vedere l'area delle immagini degli ingressi come semplici variabili

ed il tuo esempio può calzare, ma evidentemente ogni programma ha la sua applicazione e bisogna che ci mettiamo tutti in testa che per programmare una qualsiasi cosa ci sono svariati modi tutti plausibili.

Ripeto ancora che non è nemmeno mia attitudine programmare così, ma è perfettamente coerente con gli esempi fatti più sopra da simone70 che a mio parere ha già chiuso la discussione

[batta]

Insomma, scrivere lo stato di un ingresso può piacere o non piacere. Ognuno deciderà se farlo o meno.

Qui, mi pare, sono state date esaurienti spiegazioni sull'eventuale utilizzo.

ps : se utilizzi una forzatura su un ingresso, cosa succede dell'inizio OB1 all' utilizzo effettivo di =E5.0 ?

Rileggi i messaggi #2, #3, #4: c'è già la risposta.

Personalmente l'utilizzo che ne faccio di solito è quello da me accennato in #2 e descritto meglio da OB1-Roby in #7: simulazione.

In questo modo eviti di appoggiare inutilmente gli ingressi a dei merker, per qualcosa che ti serve solo per il debug in ufficio. Queste istruzioni andranno semplicemente rimosse (cancelli e/o non richiami la FC di simulazione) quando inizi ad operare sull'impianto.

[ricki]

Ciao rddiego, esprimo le mie ultime opinioni e poi lascio il parere anche ad altri colleghi :

1) "forzatura che è tutt'altra cosa" : si hai ragione e viene anche segnalata dal LED Force... ma = e5.0 non viene segnalato da nessuno ( a meno di qualche ob di errore di prog , ma non ne sono sicuro).

2) "per programmare una qualsiasi cosa ci sono svariati modi tutti plausibili" : pienamente d'accordo , il software è una creazione puramente personale : ma quando lavori in team ( in senso amichevole) e un tuo collega naviga nel buio più nero ( per cento ragioni non solo sw) , io credo che solo una programmazione semplice e snella gli può rendere la vita meno difficile.

3) "Discussione chiusa " : daltronde , io credo , nel rispetto del lavoro degl'altri , che ognuno ha il dovere di aiutare il prossimo , perche domani sicuramente sarò io ad essere nella m.... altro che buio....

Ciao e buona serata

Ricki

[rddiego]

ps : se utilizzi una forzatura su un ingresso, cosa succede dell'inizio OB1 all' utilizzo effettivo di =E5.0 ?

funziona come con le uscite, ma potrebbe non essere vero perchè le uscite sono aggiornate alla fine... sarebbe da provare. Secondo me esegue la funzione di scrittura e quindi forzando comunque bisognerà aspettare T1

1) dici così perchè lo ritieni un errore e ancora ti ostini a ritenerla al pari di una forzatura va beh

2) più che difficile può essere inconsueta e non vedo tutte queste complicazioni (a meno che non pensi sempre al fucile puntato)

3) con discussione chiusa non intendevo non parlare più, intendevo che abbiamo ampiamente risposto al quesito di fabmatt

[dott.cicala]

Se si parla di test, nel caso ci sia solo la cpu e nient'altro, allora mi quadra scrivere gli inputs che non ci sono, altrimenti essendo la programmazione un'arte ognuno fa quel che gli pare.

Non vorrei però esser io quello che apre la vat e poi si va a cercare i vari stati dello stesso ingresso in giro x il programma...da ora in poi cross-reference x ogni ingresso sospetto.

X fortuna che x le mie applicazioncine basta plcsim x il debug.

...ma la discussione è chiusa o aperta?

[Ecup]

Secondo me tutti i giochetti di cui state parlando (filtri temporali, scambio NO<->NC, simulazione in fase di debug) andrebbero fatti su merker di appoggio, e non sugli ingressi veri e propri... lo stato degli ingressi "deve" rappresentare lo stato dell'impianto: non è concepibile che vado a leggere un ingresso in un punto del programma e questo non coincide con l'effettivo stato del segnale... questo è uno dei motivi per cui personalmente appoggio sempre tutti gli I/O su merker di appoggio

ciao

[Simone70]

Secondo me tutti i giochetti di cui state parlando (filtri temporali, scambio NO<->NC, simulazione in fase di debug) andrebbero fatti su merker di appoggio, e non sugli ingressi veri e propri... lo stato degli ingressi "deve" rappresentare lo stato dell'impianto: non è concepibile che vado a leggere un ingresso in un punto del programma e questo non coincide con l'effettivo stato del segnale... questo è uno dei motivi per cui personalmente appoggio sempre tutti gli I/O su merker di appoggio

Ovviamente ognuno è libero di pensarla come vuole a meno che non ci siano norme scritte a riguardo.

[Ecup]

Ovviamente ognuno è libero di pensarla come vuole a meno che non ci siano norme scritte a riguardo.

Ovvio... non so se ci sia una normativa in merito, ma IMHO leggere in un punto del programma un valore di un ingresso che non ha corrispondenza fisica, non ha senso e non è corretto... se appoggi gli ingressi su dei merker puoi assegnare a quei merker il significato che vuoi, ma un ingresso è un ingresso... tantopiù che queste cose non le puoi fare su tutti i PLC...

ciao

[elettricem]

Come qualcuno ha già detto la programmazione è qualcosa di personale e naturalmente la si pensa facilmente in modo diverso, ciò non toglie che può essere più o meno valido un metodo piuttosto che un altro.

mettiti nei panni di fabmatt, che ha un impianto fermo e ha un fucile puntato dalla direzione che con un cronometro gli sta contando il downtime...

in questo caso credo dipenda dalla singola persona permettere a qualcuno di puntare il fucile oppure meno...è capitato più volte anche a me, ma ho imparato a imporre i miei tempi (e quindi anche a rispettarli) e soprattutto a far valere la mia esigenza di lavorare senza pressioni, il che rende l'intervento più efficente e più veloce...e se sono convinti di essere migliori loro....

Buon Natale a tutti

[fabmatt]

Se ho capito bene con questa istruzione vado a modifiare l'immagine degli ingressi, ma il programma lo prende in considerazione solo da quel punto li fino alla fine della scansione. Faccio un esempio banale,su un cilindro, Fc Avanti e Fc indietro , mando avanti il cilindro, poi quando mando indietro il cilindro modifico l'immagine dell'ingresso Fc avanti (U EV Indietro = Fc Avanti, e quindi da quel punto in poi il programma sa che il cilindro a fatto quel movimento, perchè a l'ingresso Fc indietro ma nella sua immagine si ritrova anche Fc Avanti.

Se è così Grazie della spiegazione.

PS.

Ognuno è libero di fare il programma come vuole, non siamo tutti uguali e quindi rispettare il modo di lavorare degli altri. L'importante è capire perchè una cosa è fatta in una determinata maniera. Serve anche per arricchire le conoscenze personali.

Buone Ferie, per chi può

Grazie.

[Livio Orsini]

Io sono sempre del parere che i programmi debbano seguire una logica ben precisa. Se una variabile fisica condiziona, a seconda del valore che assume, una sequenza e/o lo stato di una o più uscite, allora in tutte le fasi del programma si deve usare lo stato fisico della variabile.

L'unica deroga a questa regola sono le operazioni di messa a punto e virifica. Le modalità corrette sono quelle descritte da OB-1. Al termine delle fasi di collaudo le funzioni di test saranno disattivite o rimosse.

Cambiare da programma lo stato di una variabile fisica non è un modo corretto di programmare. Anche nel caso di sensori, selettori che possono essere montati NO o NC, socondo una pessima abitudine degli elettrecisti ("tanto lo giri a software, per te è un attimo" ), non devono essere alterati gli stati della variabile. La cosa migliore è prevedere, come prima funzione, la copia degli ingressi relativi su memorie di appoggio e, al limite, si cambia la stato della memoria, memoria che sarà usata in seguito da tutto il programma.

Anche la realizzazione di filtri antirimbalzo, se si vuole realizzarli in modo corretto, non necessita di alcuna alterazione dello stato reale dell'ingresso.