Utilizzo Dell'ingresso "e" Nella Bobina Di Uscita

[Ecup]

Io lavoro solo con Siemens quindi il problema non sussiste.

Checc'entra? si sta parlando di programmazione in generale...

Rigirandoti la frittata ancora ti dico che il tuo metodo non mi piace proprio, ma ripeto, è un parere personalissimo. e non penso assolutamente che devi cambiarlo. Per me è molto meno leggibile andare a leggere un programma dove invece di trovare Ingressi trovo solo memorie.

Basta dare dei nomi "sensati" ai merker, per esempio un tag iniziale che identifica il fatto che sia un ingresso mappato... ME-PS_vattelapesca -> Mappatura ingresso, pressostato vattelapesca

Immagina se per qualche motivo (capita spessismo) non si ha a disposizione la documentazione che indica la mappatura.

documentazione? c'è un blocco dove è fatta la mappatura e un simbolico con tutti i nomi...

Tu dai la documentazione dei "giochetti" che fai sovrascrivendo gli ingressi?

[dott.cicala]

Colpa mia Livio, sono stato troppo vago.

Spero che sia proprio come dici in merito al pressapochismo....spero inoltre che valga non solo per la programmazione....guardandomi intorno, purtoppo questi segnali non li vedo ancora.

Probabilmente da me l'onda non è ancora arrivata. Aspetto pazientemente la primavera...

[Simone70]

Visto che la metti sul chi ce l'ha più duro, per me la discussione in merito è finita. Peccato.

[Ecup]

Visto che la metti sul chi ce l'ha più duro, per me la discussione in merito è finita. Peccato.

Se ce l'hai con me non so che dirti... io ti ho riportato le mie scelte documentendo il perché ritengo che siano migliori, e rispondendo alle tue osservazioni sulla documentazione. Se tu tagli il discorso dicendo "tanto a me non frega niente degli altri PLC perché uso solo Siemens" o "se faccio così ci metto più tempo" non so che dirti... continua pure a programmare così, a me non cambia la vita, ma non aspettarti che questo modo di programmare sia ritenuto corretto in certi ambiti.

Poi ognuno ha il suo modo di vedere le cose... io per esempio sono consapevole di fare, a volte, rami poco comprensibili (anche se commento il più possibile), ma quella di sovrascrivere gli ingressi (IMHO) è una cosa che basilarmente non andrebbe proprio fatta...

[walter.r]

Ragazzi, è un paio di giorni che seguo questa discussione, e mi domando una cosa molto semplice, al di là dei principi della progettazione e delle necessità contingenti ( essendo che a volte le necessità ti obbligano a superare i tuoi principi..... Livio , concordo con te sui metodi, ma quando sono magari le 2 di notte e sei nelle Filippine a risolvere un problema........) :

Ripeto, mi domando una cosa: ma Step7 non ha l'editor simbolico delle variabili ??

E' una cosa che uso da anni, tu ad esempio generi la variabile "FC_salita", la accoppi a E 0.0, e nel programma usi "FC_salita", il che rende comprensibile il software, e consente di fare quello che dice batta , cioè, se si deve simulare basta cambiare l'accoppiamento nome<-->variabile e il gioco è fatto.

Ed è ottimo anche quando per vari motivi ti spostano un segnale da un ingresso ad un'altro, che fai, ricerca e sostituzione in tutto il progetto ????

Non c'è questo nello Step7 ????

Mi sembra piuttosto strano che non ci sia, e che nessuno lo usi..!!

Fatemi sapere. Grazie

Modificato: 21 dicembre 2006 da walter.r

[supernovellino]

Sì che c'è, si chiama ricablaggio.

[Simone70]

Se ce l'hai con me non so che dirti... io ti ho riportato le mie scelte documentendo il perché ritengo che siano migliori, e rispondendo alle tue osservazioni sulla documentazione. Se tu tagli il discorso dicendo "tanto a me non frega niente degli altri PLC perché uso solo Siemens" o "se faccio così ci metto più tempo" non so che dirti... continua pure a programmare così, a me non cambia la vita, ma non aspettarti che questo modo di programmare sia ritenuto corretto in certi ambiti.

Poi ognuno ha il suo modo di vedere le cose... io per esempio sono consapevole di fare, a volte, rami poco comprensibili (anche se commento il più possibile), ma quella di sovrascrivere gli ingressi (IMHO) è una cosa che basilarmente non andrebbe proprio fatta...

Riprendo la discussione perchè non mi va di lasciare perdere le cose in sospeso sbattendo la porta. Dico soltanto che la parola "giochetti" te la potevi risparmiare, visto che io non ho mai offeso il tuo lavoro e la tua professionalità, ho soltanto espresso il mio parere su una variante di programmazione che in 15 anni di lavoro non ho mai avuto l'esigenza di adottare e che, ribadisco, non mi piacerebbe adottare.

tanto a me non frega niente degli altri PLC perché uso solo Siemens

Questa frase non è mia, rispondevo soltanto alla tua affermazione di non poter usare la stessa istruzione in un'altro PLC, esigenza che non ho mai avuto.

Rigurdo alla nota dolente della discussione, e cioè mettere in = un ingresso, ripeto che non è una prassi che uso sistematicamente, ma mi è capitato di farlo in certi contesti limitati e documentati e non la trovo una bestialità come la disegni tu.

Concludo augurandoti Buone feste

[tode72]

sono arrivato tardi.... si chiama ricablaggio ed è molto utile a volte... e questa secondo me potrebbe essere una di quelle, cioè ricablare al posto degli ingressi dei merker e andare a controllare quest'ultimi in fase di debug precollaudo.... comunque personalmente preferisco lasciare il programma intatto e andare a modificare i merker che mi interessano tramite una vat e vedere il risultato che ne scaturisce senza forzare nessun ingresso e senza ricablare... a volte ci si può sempre dimenticare di rimettere tutte le cose a posto e in fase di collaudo possono accadere eventi non troppo piacevoli (vedi sostituzione di un finecorsa)

[supernovellino]

Il ricablaggio è comodo, però se si ha un hmi le cui variabili sono collegate ai simboli di step7.....ci si deve ricordare di ricompilare e ritrasferire altrimenti....

Anche io ritengo non sia corretto scrivere gli ingressi, ma molte volte a mali estremi si ricorre ad estremi rimedi.....In questi casi io uso dire "gabola" senza offesa x nesuno.

Ciao

[Ecup]

la parola "giochetti" te la potevi risparmiare, visto che io non ho mai offeso il tuo lavoro e la tua professionalità

la parola "giochetti" (virgolettata) è riferita ai "giochetti" fatti per modificare lo stato degli ingressi (che dopo certi "giochetti" non rappresentano più lo stato degli ingressi), e non certo per definire "giochetti" i tuoi lavori o offendere la tua professionalità.

Per quanto mi riguarda nei tuoi 15 anni di esperienza puoi anche aver fatto gli impianti più importanti di questo pianeta, ed essere un professionista molto più affermato di me, ma ciò non toglie che fare certi "giochetti" sugli ingressi, IMHO (e ribadisco IMHO) non è minimamente corretto.

Questa frase non è mia,rispondevo soltanto alla tua affermazione di non poter usare la stessa istruzione in un'altro PLC, esigenza che non ho mai avuto.

Se è per quello io rispondevo solo alla tua affermazione che lamentava di dover sostituire il merker in tutto il programma, cosa che dovresti fare comunque con gli altri PLC

Rigurdo alla nota dolente della discussione, e cioè mettere in = un ingresso, ripeto che non è una prassi che uso sistematicamente, ma mi è capitato di farlo in certi contesti limitati e documentati e non la trovo una bestialità come la disegni tu.

Dal punto di vista delle programmazione IMHO è una grande bestialità. Se poi vogliamo dire che in certi contesti faccia comodo, diciamolo pure, ma resta pur sempre una bestialità, e (sempre IMHO) un ripiego.

Se l'ingresso E0.0 è il segnale di pressostato, deve essere il segnale di quel pressostato, non può essere altro. Se ho bisogno di filtrarlo con un tempo T1 avrò il segnale T1 che si chiama "pressostato filtrato" e userò T1 nella mia logica. Se ho bisogno del segnale negato perché ho fatto tutta la mia logica col segnale negato, lo appoggio negato su M0.0 e uso M0.0 per la mia logica. Tutte queste cose si fanno senza problemi e senza sostituzioni se si prepara direttamente la logica con gli Mx.x senza preoccuparsi di come saranno gli ingressi.

Non c'è alcun pericolo di mancanza di documentazione se si usano nomi appropriati e si fa tutta la mappatura in un unico blocco.

Tra i vantaggi di questa prassi c'è anche quella di poter definire l'interfaccia utente svincolandosi dallo stato degli ingressi (ma utilizzando il "senso" assegnato ai merker), nonché quello di poter riutilizzare parte del codice (non so tu ma a me capita spesso di fare più macchine simili) agendo solamente sulla mappatura.

Altro vantaggio: raggruppare tutti i segnali di una certa sezione nella stessa zona di merker. Se poi ci sono più sezioni simili si può anche pensare di fare funzioni indicizzate che eseguono la stessa operazione puntando ad una certa zona di merker che tu hai definito sempre uguale in maniera ripetitiva (cosa che generalmente non accade con gli ingressi, a meno che non sia tu a preparare anche gli schemi elettrici e la tipologia dell'impianto ti consenta un certo tipo di raggruppamento)

Concludo dicendo che alcuni miei clienti, solitamente quelli che hanno anche un reparto manutenzione ben "attrezzato", esigono la mappatura riconoscendone i pregi (cosa che non mi crea problemi in quanto la farei comunque), e che con certi PLC (dove non puoi scrivere gli ingressi e nemmeno richiamare ingressi non presenti fisicamente) è indispensabile se si vuole fare una simulazione provando la CPU a banco (ma senza schede I/O che nella realtà sono sparse per tutto l'impianto) con relativo sistema di supervisione e simulazione di cicli di lavoro completi.

Concludo augurandoti Buone feste

la cosa è reciproca

[Livio Orsini]

..personalmente preferisco lasciare il programma intatto e andare a modificare i merker che mi interessano tramite una vat e vedere il risultato che ne scaturisce senza forzare nessun ingresso e senza ricablare... a volte ci si può sempre dimenticare di rimettere tutte le cose a posto e in fase di collaudo possono accadere eventi non troppo piacevoli

Concordo in toto

[elettricem]

Per Livio:

Forse mi son perso qualcosa, ma io non ho mai detto di programmare in quel modo, ho solo detto di non sentirmi in posizione di giudicare qualcuno, soprattutto se non sono a esatta conoscenza dei fatti avvenuti prima di trovare ...mi sono trovato una volta a tirare conclusioni affrettate e non lo farò mai più.

Ti avevo anche chiesto di non volermene ...ma visto la risposta...credo di essere stato solo frainteso.

Buon Natale a tutti

[batta]

sono arrivato tardi.... si chiama ricablaggio ed è molto utile a volte... e questa secondo me potrebbe essere una di quelle, cioè ricablare al posto degli ingressi dei merker e andare a controllare quest'ultimi in fase di debug precollaudo.... comunque personalmente preferisco lasciare il programma intatto e andare a modificare i merker che mi interessano tramite una vat e vedere il risultato che ne scaturisce senza forzare nessun ingresso e senza ricablare... a volte ci si può sempre dimenticare di rimettere tutte le cose a posto e in fase di collaudo possono accadere eventi non troppo piacevoli (vedi sostituzione di un finecorsa)

Punto fermo: scrittura stato ingressi solo in simulazione. In questo caso il ricablaggio NON è una valida alternativa, per i seguenti motivi:

1) sono in ufficio, utilizzo una cpu senza moduli di I/O (oppure un simulatore). Da VAT posso impostare lo stato degli ingressi come fossero merker, quindi il ricablaggio con merker in sostituzione degli ingressi non serve. Ho evitato un doppio ricablaggio, quindi ho ridotto le possibilità di introdurre errori.

2) la cosa più utile è simulare segnali che dovrebbero arrivare dal campo. Esempio classico di valvola comandata da una uscita e con 2 finecorsa di posizione. Nel blocco "Simulazione" (richiamato all'inizio di OB1) scrivo:

U ComandoValvola

= FC_ValvolaAperta

NOT

= FC_ValvolaChiusa

E gli ingressi funzionano come se ci fosse la valvola collegata. Molto più comodo che andare a gestire in una VAT decine o centinaia di merker.

Poi basta eliminare il richiamo a "Simulazione" e tutto torna perfettamente a posto.

Molto più comodo, più semplice e più pulito di un ricablaggio per simulare, seguito da un ricablaggio al contrario per tornare ad operare normalmente. Per finire, pensa se, con continui ricablaggi, una volta commetti un errore. Con il blocco "simulazione" basta invece aggiungere o rimuovere // per abilitare o disabilitare il richiamo al blocco. Possibilità di errore: tendente a zero.

[tode72]

scusa batta, ma è il tendente a zero che mi preoccupa visto che non è zero e poi come ho detto non uso il ricablaggio visto che lì la possibilità di errore è sicuramente diversa da zero.... ma se proprio non se ne può fare a meno.... e questo topic lo trovo utile per trovare le valide alternative... anche alla mia soluzione che sarà onerosa ma lascia intatto tutto il ciclo macchina e non coinvolge nulla che non sarà presente anche in fase di collaudo reale.

[Livio Orsini]

Elettricem:

Livio non me ne volere ma sono anch'io daccordo in toto con rddiego.

Livio

Elettricem, non te ne voglio:....

Elettricem

Per Livio:

Forse mi son perso qualcosa, ma io non ho mai detto di programmare in quel modo, ho solo detto......

Forse ti sei davvero perso qualche cosa: i post precedenti al primo messaggio quotato .Ma non ho intenzione di iniziare una nuova diatriba

...e questo topic lo trovo utile per trovare le valide alternative...

Personalmente, forse perchè provengo dal mondo dei microcontrollori prima che dal mondo PLC, in fase di test preferisco agire sul valore delle memorie con operazioni analoghe all'uso delle VAT di Step7. Anche il metodo descritto da Batta e da OB-1 sono metodi che considero validi e corretti.

La cosa veramente importante è raggruppare tutto quanto riguarda i test in files facilmente individuabili e rimovibili. In altre parole da una parte c'è un programma applicativo che dovrà girare sulla macchina, da un'altra parte c'è una sezione distinta di programma che sarà attivato solo in fase di test. Mai inserire varianti e varabili temporanee nel corpo del programma: si rischia di non toglierle tutte finiti i test.

Quando negli impianti si previlegiava la qualità, le aziende che lavoravono seriamente pretendevano che le modifiche hardware, eseguite al solo scopo di test dell'impianto, venissero cablate con cavi tutti di identico colore e di colore diverso dagli altri cablaggi. Solitamente si usava il colore rosso, dato che i cablaggi alle morsettiere erano eseguiti con cavi multipolari di colore nero. In questo modo era sufficiente una rapida occhiata per individuare un eventuale ponticello dimenticato in morsettiera.

Anche le modifiche software per i test dovrebbero avere la medesima logica.

Modificato: 21 dicembre 2006 da Livio Orsini

[dott.cicala]

La maggior parte dei programmatori sostengono che la loro percentuale di errore sia tendente a zero, poi nella realtà si scopre che è tendente a + infinito...

[ricki]

esagerato "+infinito", ma comunque non è sufficiente

U ComandoValvola

= FC_ValvolaAperta

NOT

= FC_ValvolaChiusa

e tutti i transienti di mezzo !?! chi li considera.....

il tendente a zero non è piu proprio zero .....

Ciao

Ricki

Modificato: 21 dicembre 2006 da ricki

[batta]

Ricki, non capisco cosa vuoi dire.

Cosa c'è che non va in quelle istruzioni? Non credo che, in simulazione, sia un problema se la valvola risulta aprirsi in una scansione, anziché impiegare qualche secondo. Nei rarissimi casi in cui ciò potrebbe essere importante, si usa un timer.

Per quanto riguarda la simulazione, una cosa non è ancora stata considerata: il blocco di simulazione NON serve per forzare ingressi (lo stato di un ingresso non fisicamente presente lo posso scrivere in una VAT né più né meno di quanto farei con un merker), ma per simulare risposte dal campo.

Insomma, il blocco simulazione servirebbe anche nel caso di utilizzo di merker al posto degli ingressi, e sarebbe assolutamente identico, solo che "FC_ValvolaAperta" e "FC_ValvolaChiusa" sarebbero merker invece di ingressi. Le possibilità di errore sono quindi esattamente le stesse.

A meno ché non vi sembri una buona soluzione prepararsi una VAT con centinaia di merker da dover continuamente attivare e disattivare ad ogni comando. Se operi con poche valvole magari ci stai anche dietro, diversamente non riusciresti a provare il ciclo, perché saresti sempre fermo per allarmi di errate commutazioni delle valvole. Certo, si potrebbe sempre risolvere, piuttosto che con un blocco per simulare gli ingressi, apportando modifiche provvisorie per disabilitare gli allarmi

Modificato: 21 dicembre 2006 da batta

[Savino]

Hi every one,

Sono in assoluta corrispondenza con quello postato da Livio Orsini ...

niente da aggiungere

[walter.r]

Beh, se può servire a qualcosa, dato che poi ognuno di noi è LIBERO di scegliere i modi e i metodi che preferisce........ personalmente non ci trovo nulla di scandaloso in quello che dice Batta .

Se c'è la possiblitità di debuggare il programma stando alla scrivania, e senza avere l'impianto "fisicamente" presente, perchè non approfittarne???

Credo che questo metodo, pur non avendolo mai usato, permetta di verificare delle funzionalità riducendo al minimo la possibilità di DIMENTICARE nel progetto linee di codice temporanee.

Chiaro, l'idea di SCRIVERE un INGRESSO può sembrare strana, ma ricordiamoci che il POTER SIMULARE in un modo molto vicino alla realtà può essere di grande aiuto.

Occorre comunque ricordare che, quando si fanno delle verifiche, delle prove, occorre tassativamente essere LUCIDI, quindi RICORDARE, in qualunque modo valido, le modifiche provvisorie che si fanno.

Chi ha la capacità di essere LUCIDO può permettersi anche di girare il software sottosopra, perchè SA di essere perfettamente in grado di rimettere le cose come stavano.

[batta]

Occorre comunque ricordare che, quando si fanno delle verifiche, delle prove, occorre tassativamente essere LUCIDI, quindi RICORDARE, in qualunque modo valido, le modifiche provvisorie che si fanno.

Esatto!

Ed anche qui sta la forza del blocco di simulazione: basta eliminare la chiamata al blocco e tutto il programma è perfettamente a posto, senza modifiche sparse qua e là

[ricki]

Scusa Batta , ho frainteso quel tendente a zero.

La mia risposta era legata al modo in cui un tecnico esegue un test del programma.

Batta , le righe da te scritte, non fanno una piega . Ma , nel caso degli impianti che costruisce l'azienda per cui lavoro, risulterebbe molto incompleto un debug nel quale , l' "FC di simulazione" dice se ho la valvola "A" sovrascrivo "Indietro" e in caso contrario sovrascrivo "Avanti", perchè devo tener conto anche di eventuali ritardi o altre cose che non sto ad elencare, quindi nel tuo caso , non sapendo come è costituito il tuo impianto, tutto OK , ma non sempre puoi simulare un completamente o anche parzialmente un processo produttivo.

Tutto qui .

Buon Natale

Ricki

[Ecup]

esagerato "+infinito", ma comunque non è sufficiente

U ComandoValvola

= FC_ValvolaAperta

NOT

= FC_ValvolaChiusa

e tutti i transienti di mezzo !?! chi li considera.....

il tendente a zero non è piu proprio zero .....

Per simulare va più che bene...

Tra l'altro, per me "ComandoValvola", "FC_ValvolaAperta" e "FC_ValvolaChiusa" sono tutti merker messi in corrispondenza con I/O in blocchi opportuni. Tutta la simulazione, ovvero istruzioni tipo questa, stanno in un blocco richiamato solo in simulazione (mentre simulo i blocchi che appoggiano gi I/O sui merker non sono richiamati)

Ovvio che poi nella logica del programma che gira sulla macchina si saranno anche gli opportuni controlli... per esempio:

U ComandoValvola

U(

UN FC_ValvolaAperta

O FC_ValvolaChiusa

)

O [viceversa]

L S5T#tempo

SE T1

U T1

S Allarme (come resetterlo dipende dalla macchina)

U FC_ValvolaAperta

UN FC_ValvolaChiusa

UN Allarme (eventualmente)

= Stato_di_ValvolaAperta

Se poi in campo scopro che (a differenza di quanto riportato sugli schemi) certi sensori non ci sono, nel blocco dove appoggio gli ingressi ai merker prenderò i dovuti accorgimenti... per esempio se manca "FC_ValvolaAperta" scriverò:

U ComandoValvola

UN FC_ValvolaChiusa

L S5T#tempo

SE T2

U T2

= FC_ValvolaAperta