Confrontarsi Con Gli Altri!

[yupanqui]

anche perchè aggiungo pochissimi commenti.... a volte proprio niente.

apro il flow chart e li ci stà scritto tutto.

per me non ha senso neanche scrivere la descrizione dello step. o meglio la vedo come una perdita di tempo.

i miei nikname per esempio sono: "G01S001" che significa gruppo 01 step 001

alcuni gruppi hanno anche 60-70 step. passerei intere giornate a scrivere commenti.

una cosa che non mi è ancora chiara e come gestite lo start e stopo delle vostre macchine.

io personalmente ho un bit in work per ogni gruppo che mi indica quando il gruppo stà eseguendo qualcosa.

quando tutti i gruppi hanno il loro bit in work a zero significa che posso andare in stop.

ho visto macchinari con fotocellule dove quando l'operatore infila un braccio nella macchina tutti i movimenti si congelano. e ripartono non appena le fotocellule sono di nuovo libere.

io avrei problemi a fare una cosa del genere perchè se la mia sequenza non va a buon fine dopo un certo tempo attivo un allarme....

[batta]

Per cicli complessi creo un diagramma di flusso in un documento a parte, mentre per cicli più semplici inserisco semplicemente la descrizione come commento in Step7 (vale, ovviamente, per qualsiasi plc) ed il diagramma rimane visualizzato nella mia mente.

Personalmente cerco di dare dei sinonimi più chiari possibili ad ogni bit che uso. Se il sinonimo non è sufficientemente chiaro (ma quasi sempre anche se è chiaro abbastanza) inserisco nella descizione altre informazioni.

Ogni operazione, a meno ché non sia banalissima, è descritta in modo il più chiaro possibile. Ci possono essere segmenti contenenti poche righe di programma ed una lunga descrizione.

Molte FC ed FB iniziano con un segmento che contiene solo 20-30 righe di descrizione.

Il tempo perso a scrivere descrizioni è tutto tempo guadagnato quando si dovrà intervenire, magari a distanza di tempo, sullo stesso programma. Scrivere, secondo me, aiuta anche a ragionare meglio su quello che si sta facendo. Se non sono in grado di descrivere un ciclo significa che non l'ho capito, e se non l'ho capito non potrò mai fare un programma che funzioni. Scrivendo si ragiona più lentamente, si fissano meglio i ragionamenti fatti ed è più facile accorgersi di dettagli che con un'analisi veloce del ciclo erano sfuggiti.

Nei miei programmi per sapere se un merker è stato utilizzato non è neanche necessario consultare i riferimenti incrociati: se è documentato è usato, se non è documentato non è usato. Infatti sono abituato a dare sempre prima un nome al merker. Solo dopo averlo nominato (nominato nel senso che gli ho dato un nome, non nel senso dei reality ) lo utilizzo nel programma, mai viceversa.

[Savino]

Ciao,

ma mi dite quale macchina automatica non fa operazioni sequezniali? sono nate x quello o sbaglio?

In "automation" , non sarebbe giusto parlare di macchine sino di processi. In qualsiasi macchina, dei processi continui ce ne sarebbero cosi tanti quanti ce ne sarebbero dei processi sequenziali .

Poi, secondo te la denominazione macchina e' solo per quelle capaci di eseguire delle operazioni in sequenza.. beh non direi. Comunque non puoi pensare a programmare tutto in sequenza.

anche perchè aggiungo pochissimi commenti.... a volte proprio niente.

Bisogna sempre riuscire a documentare il piu' possibile, anche se saresti te stesso l'unica persona a leggere il programma nel prossimo futuro. Flow chart, schemi a blocchi, ciclogrammi di movimenti, layout di massima, tabelle di variabili, commenti, tutto va bene. Il tempo che spendi oggi per documentarti, ecc.. ti tornera' domani sicuramente.

ho visto macchinari con fotocellule dove quando l'operatore infila un braccio nella macchina tutti i movimenti si congelano. e ripartono non appena le fotocellule sono di nuovo libere.

io avrei problemi a fare una cosa del genere perchè se la mia sequenza non va a buon fine dopo un certo tempo attivo un allarme....

Caro Silver, che il movimento sia sequenziale non vulodire che non potrebbe fare una pausa....Se l'operatore infila un braccio nella macchina e la ferma , per evitare che questa vada in allarme di timeout di esecuzione passo , devi fermare il contatore per il suo tempo di controllo che era partito a contare nel momento cha ha avuto inizio il passo stesso. Quindi, salvi il valore del elapsed time, reseti il timer.Quando la fotocellula e libera, carichi il tempo salvato, imposti il timer e lo attivi ancora....

Certamente che questo esempio e' una delle tante ipotesi possibili e supponendo che tutto si esegue in condizione di sicurezza assoluta.

ma con i plc che uso io non credo ci siano queste possibilità vero?. in particolare io utilizzo GE90-30 AB SLC500 e SIEMENS S7 300.

SFC for S7

CFC for S7

RSLogix5000 ( quick info)

Fanuc ( legge la voce "Programming Software", in basso).

Io attualmente mi trovo lavorando in SFC- CFC - Math con APT sulle CPU Siemens Ti. Tra qualche mese ne andro' a utilizzare quello dell' AB. Provaci... visto che ti piaciono i flow chart....mi sa che sono fatti per te

Siemens API for Ti

APT references

Math

Modificato: 19 settembre 2006 da Savino

[JumpMan]

Il tempo perso a scrivere descrizioni è tutto tempo guadagnato quando si dovrà intervenire, magari a distanza di tempo, sullo stesso programma. Scrivere, secondo me, aiuta anche a ragionare meglio su quello che si sta facendo. Se non sono in grado di descrivere un ciclo significa che non l'ho capito, e se non l'ho capito non potrò mai fare un programma che funzioni. Scrivendo si ragiona più lentamente, si fissano meglio i ragionamenti fatti ed è più facile accorgersi di dettagli che con un'analisi veloce del ciclo erano sfuggiti.

Nei miei programmi per sapere se un merker è stato utilizzato non è neanche necessario consultare i riferimenti incrociati: se è documentato è usato, se non è documentato non è usato. Infatti sono abituato a dare sempre prima un nome al merker. Solo dopo averlo nominato (nominato nel senso che gli ho dato un nome, non nel senso dei reality ) lo utilizzo nel programma, mai viceversa.

Condivido al 100%

[yupanqui]

si savino è chiaro che in qualche modo riesco a congelare la mia sequenza e poi ripartire...

volevo solo sapere se esisteva un modo semplice per implementare una cosa del genere, è vero anche che questa è una cosa abbastanza particolare. finora non ho mai avuto il bisogno di fare niente del genere.

grazie per i link mi informo meglio!

[Simone70]

è vero anche che questa è una cosa abbastanza particolare

Non generalizzerei troppo. Dipende dal tipo di impianto che fai. I miei impianti possono essere arrestati in qualsiasi momento istantaneamente e devono ripartire dallo stesso punto.

[Luca Bab]

Come avevo gia' postato

con una memoria di partenza, una di stop

e con le due ne faccio una terza di attivazione del movimento ( in autoritenuta poiche' gia' scottato da S e R )

nel segmento che attiva il movimento ( bobina per il contattore del motore )

in serie ho la memoria di attivazione del movimento , la M di macchina in marcia e le M che bloccano il movimento ma senza far cadere la M di attivazione .

In questo modo puoi discriminare le condizioni che fermano il movimento senza farlo piu' ripartire , da quelle che fermano momentaneamente , che quando se ne vanno fanno finire il ciclo al movimento.

Ciao

Luca

[yupanqui]

Non generalizzerei troppo. Dipende dal tipo di impianto che fai. I miei impianti possono essere arrestati in qualsiasi momento istantaneamente e devono ripartire dallo stesso punto.

Bene Simo perchè non ci spieghi come fai??

[Simone70]

Fondamentalemnte no uso le memorie di passo. Uso una o più memorie che mi indicano che l'operazione è stata eseguita e poi faccio la sequenza dei movimenti usando lo stato degli attuatori. Sul movimento positivo nego la memoria di lavorazione effettuata e metto in AND i segnali degli attuatori che devono già essere in posizione, nel movimento negativo metto in OR tutte le stesse condizioni interrogando gli operandi nello stato inverso. Diciamo che questa è una spiegazione terra-terra, dopo lo specifico è un po' + difficile da spiegare. Comunque ripeto che, IMHO, tutto dipende dal tipo di attrezzatura che si automatizza e dal tipo di attuatori che si hanno.

[Piero Azzoni]

nota per tutti

perche' non ci esprimiamo secondo isa, cosi' tutti capiscono

anzi, chi non capisce deve studiare isa e capire

per esempio

kop fuk ed altre emita' di svariati vendor NON SONO ISA

ladder per esermpio E' isa

gli indirizzi fisici quanto riportate il listato DEVONO ESSERE PRECEDUTI DAL %

i simbolici devono cominciare con una lettera

gli ingresso, le uscite, i marker e le memorie hanno una radice standard che li definisce

%i. %q. %m

DIGITALE VUOL DIRE UN'ALTRA COSA CHE NON C'ENTRA UNA BEATA FAVA CON GLI INGRESSI E LA USCITE A BIT

SI CHIAMANO "DISCRETI" OPPURE "LOGICI"

-----------------------------------------------------

altrimenti e' come se un lappone parlasse con un africano

gli standar non devono essere presi come leggi quando indicano una possibile metodologia esecutiva ma devono essere usati come attrezzo quando definiscono una forma espressiva che tutti devono perlare

--------------------------------------------------

per quanto riguarda la problematica dei set e reset piutttosto che l'autoritenuta

e' da capire in funzione della variabile

non e' assolutamente vero che l'autoritenuta ha una necessaria radice elettromeccanica

se il %m che attuo deve rimanere imperituro nel tempo fino a quando lo resetto usero' sempre il set e reset, tendenzialmente rendero' questo %m ritentivo di fronte alla caduta di tensione della cpu

se il %m deve rimanere memorizzato in specifiche circostanze ma, in sicurezza positiva deve cadere, non usero' mai il set e reset ma usero' l'autoritenuta curando che il flag non sia ritentivo al reset della cpu

questi due casi base danno luogo alle due eccezioni dove la ritenzione e' operata rovescia per casi particolari, per un totali di 4 casistiche per un semplice flag binario

--------------------------------------------------

Questo semplicemente per dimostrare che non si puo' parlare con semplicita' oppure entrare profondamente nell'argomento ma

non si puo' banalizzare e pontificare contemporaneamente

[batta]

Non mi pare che ISA sia universalmente utilizzato.

Se dovessi descrivere un programma per Step 7 usando la sistassi ISA non ci si capirebbe un bel niente.

Poi, che un bit lo chiami %m, oppure lo chiami M, oppure lo chiami semlicemente bit, non mi pare cambi molto.

Che un ingresso lo chiami I oppure %i mi pare cambi altrettanto poco.

Lo standar ISA potrà essere giudicato uno standar solo quando tutti i costruttori di plc si saranno adeguati, ma mi pare che la strada da percorrere sia ancora lunga. Molto lunga.

Comunque, se posti un link dove poter scaricare od acquistare un manuale per potermi informare su questo grande(?) standard, te ne sarei grato. Sembra che lo standar sia così diffuso che, da una ricerca su internet, ho trovato di tutto tranne quello che cercavo.

Per quanto riguarda la denominazione di ingressi "digitali" oppure "discreti", in quanti cataloghi trovi la dicitura "scheda di ingressi discreti"? Ed in quanti trovi invece "scheda di ingressi digitali"?

[rguaresc]

ISA ha avuto rigine negli USA, Link_ISA in attesa di montare in casa nostra la presa ISA possiamo continuare a programmare con altri standard....

[Piero Azzoni]

evidente che se nel sottoforum siemens qualcuno avesse parlato di kop non avrei nulla a che dire

ma ti ricordo che questa discussione si chiama "confrontarsi con gli altri"

confrontarsi con gli altri parlando un dialetto di una lingua proprietaria che parla solo un vendor nal mondo mi pare una contorsiona mentale non da poco

[Piero Azzoni]

e' peraltro preoccupante anche

Se dovessi descrivere un programma per Step 7 usando la sistassi ISA non ci si capirebbe un bel niente

io quando sono proprio obbligato ad usare step 7 lo imposto nel linguaggio standard [che peraltro ha qualche "licenza poetica"]

mi rifiuto di impiarare quello strano dialetto che non somiglia neanche lontanamente a qualcosa di quasi standard

[giannit]

Secondo me il confronto và fatto nel concetto di programmazione il linguaggio è solo un sistema per esprimere la propria struttura di programma.

Io utilizzo strumenti diversi per programmare ma il concetto della gestione del programma è uguale, per assurdo dove possibile potrei fare una parte di programma con un linguaggio un'altra con un'altro, ci sono controlli e PLC che permettono di farlo.

[batta]

Se voglio descrivere un certo modo di gestire una sequenza e dico che uso dei bit di memoria di passo ed attivo e disattivo i passi utilizzando le istruzioni set/reset, se questo bit lo chiamo %m capiscono tutti. Se invece lo chiamo M, capiscono tutti lo stesso.

[Savino]

...

non e' assolutamente vero che l'autoritenuta ha una necessaria radice elettromeccanica

Infatti si tratta di una logica LATCH.

 
C := ( A OR C) AND NOT (B );

mi rifiuto di impiarare quello strano dialetto che non somiglia neanche lontanamente a qualcosa di quasi standard

Va bin piero.... se con il tuo dialetto ci riesci a campare bene, niente da dire....

Vedi Piero, in PLC development Siemens ti offre LAD - STL - FBD - CFC - SFC - MATH (PASCAL) - C - BASIC .. non posso essere d'accordo con te su questo aspetto della mancanza nello standard !

Modificato: 22 settembre 2006 da Savino

[walterword]

set e reset sparsi in giro per il programma non fanno altro che complicare il debug , secondo me.

L'esempio di savino e' piu che sufficiente per farti capire la differenza tra set - reset e autoritenuta,

anche se forse dovrebbe essere capovolto il blocchetto RS , per dare predominanza al reset , ultimo a scrivere nel ciclo .

Set e reset dovrebbero stare vicini per poter debuggare bene e capire gli errori .

Anche io uso dei set e reset per memorizzare istanti o condizioni di cicli , non ho mai detto che e' proibito .

In certe logiche pero , prima di arrivare a al bit di uscita ci sono diverse situazioni , annidamenti e

derivazioni da ogni parte , quinid ritengo che sia piu scorrevole lpa bobina piuttosto che il set -reset.

Per quanto riguarda gli step di ciclo , usare i bit e' piu impegnativo per i miei occhi e consuma piu bit che

usare un intero .

Se devi fare una macchina con 200 stati o fasi di automatico devi buttare 200 bit , col rischio di prenderti gli occhi e sbagliare gli indirizzi , mentre un intero a 16 bit ti da 65000 e rotti fasi ed piu immediato

nient' altro che un case-switch di un intero che scivi e leggi ed in ogni suo valroe che ti interessa

fai quello che devi fare .

Opinioni personali

ciao

walter

Modificato: 23 settembre 2006 da walterword

[Savino]

Opinioni personali

Altro che walterword....

Sono affermazioni ampliamente condivisibili

ciao.

[batta]

Se devi fare una macchina con 200 stati o fasi di automatico devi buttare 200 bit , col rischio di prenderti gli occhi e sbagliare gli indirizzi , mentre un intero a 16 bit ti da 65000 e rotti fasi ed piu immediato

Vero, ma anche qui non si può generalizzare. Si deve analizzare l'applicazione da realizzare. Se ho bisogno di fare una sequenza con ramificazioni è ancora più comodo utilizzare un bit per ogni passo e poter così attivare più passi contemporanei. Se nel ciclo ci sarà sempre solo un passo attivo, allora è più comodo lavorare con un intero.

[Roberto Gioachin]

Condivido e "Sostengo" la necessità di commentare tutte le parti di programma, e di aggiungere anche altra documentazione scritta anche a mano per migliorare la comprensibilità di quanto realizzato.

Alcuni PLC dispongono di un tool grafico per editare in SFG (grafcet o altri nomi per vari costruttori), quando non si hanno a disposizione questi strumenti io disegno a mano tutta la sequenza della macchina, salvo poi riscriverla con un programmino trovato in giro per poter stampare e archiviare.

Visto che il titolo è "Confrontarsi con gli altri", vorrei proporre ancora un argomento.

Come generate e gestite gli allarmi, una volta poi visualizzati su un pannello operatore, in quali condizioni li cancellate??

Credo anche per questo argomento non ci sia un solo modo di operare, cerco quindi di capire quale sia il modo più performante, non per il programmatore, ma per l'utilizzatore della macchina.

Robero

[Livio Orsini]

Secondo me tutto trae origine.....dall'origine del PLC come strumento che va a sostituire una logica cablata di tipo elettromeccanico.

Se si pensasse, come è giusto, che il PLC altro non è che un computer dotato di un particolare SO e di un compilatore che ne facilita (o dovrebbe) la programmazione, molti dubbi e molte incongruenze non avrebbero più ragione di esistere.

Troppo spesso, anzi direi quasi sempre, la programmazione viene eseguita in un modo che definire "alla garibaldina" è un eufemismo riduttivo. Si parte a scrivere istruzioni senza un'analisi non dico seria, ma neanche accennata. Poi si cerca di far funzionare il tutto usando la mazza da spaccapietre.

Prima di iniziare a scrivere istruzioni bisognerebbe attivare il cervello, compiere un'analisi della macchina o dell'impianto, stendere delle specifiche di funzionamento (la prassi corretta vuole che le prime specifiche siano redatte in fase di offerta). Da queste se ne ricavano le specifiche software generali da cui discendono le specifiche dettagliate, funzione per funzione.

Agendo in questo modo, secondo i canoni di buona progettazione, si ottengono molti vantaggi:

- riduzione del tempo totale di consegna dell'impianto (sembra strano ma è così)

- magiore affidabilità totale e del software

- indipendenza dal linguaggio di programmazione

- facilità di debug e manutenzione

- possibilità di lavoro in team

- documentazione completa, corretta e affidabile.

Purtroppo da alcuni anni a questa parte (troppi a mio giudizio) è invalsa l'uso di tagliare quelle che si ritengono spese superflue, mentre sono costi necessari, credendo di aumentare la redditività del lavoro. Quindi non si effettuano lavori di progettazione, si commissionano lavori di programmazione a personale con professionalità teorico-pratica inadeguata, collaudi e prove inesistenti, si tagliano tutti i lavori di analisi e documentazione.

Le conseguenze si pagano poi: messe in marcia che richiedono il doppio dle tempo, qualità e affidabilità della macchina al di sotto del sufficiente, perdita di mercato.

Che poi si programmi in AWL o in ladder diagram o in altro modo ha poca importanza. Io auspico che si arrivi finalmente all'uso del "C" anche per i PLC. E' solo una questione di volontà dei maggiori produttori di PLC.

Purtroppo ci si scontra con la meschina cura del proprio orticello; si pensa che usando un dialeto proprietario l'utente non cambierà marca.

Legare il cliente con questi mezzucci presto o tardi deventa controproducente. Basterebbe che due dei cinque maggiori produttori mondiali di PLC decidessero di adottare un compilatore "C" per i propri dispositivi e, nel giro di pochi anni, o gli altri si adeguano o perderebbero significative quote di mercato.

Basta pensare a tutti i vantaggi di questa scelta: portabilità, documentabilità, manutenibilità e via elencando.

Però tutto è immobile e noi si sta qui a discutere se, per rendere universale la comprensibilità, sia meglio scrivere %m o M. Io ho risolto la questione a modo mio da tempo, applico il dizionario tipico di chi usa programmare: uso termini simbolici.

Le variabili sono indicate da un acronimo descrittivo e sono precedute dai classici indicativi:

- l == long

- i == intero

- r == real

- b == boolean (bit)

- f == flag (è un boolean che indica uno stato di macchina o di programma)

Poi un bel discorso andrebbe fatto sull'uso di variabili locali e globali, statiche e dinamiche, ritentive e no.

Però questo è un discorso che trascende questa discussione e su cui si sono scritti ottimi testi di programmazione. Testi che dovrebbero studiare anche i programmatori di PLC

[Savino]

...

Personalmente cerco di dare dei sinonimi più chiari possibili ad ogni bit che uso.

Dunque, in fase di dichiarazione del simbolico sarebbe molto importante associarli in corrispondenza con i nomi dei simboli presente su gli schemi elettrici, in modo di potere avere un "quick tracking" e facile identificazione delle parti. Poi, sarebbe logico continuare a mantenere questa linearita' associativa nella nominazione degli elementi legati all'ogetto master e di conseguenza, anche sulle pagine del HMI.

Per esempio un DEVICE chiamato sullo schema elettrico 520cl (cylinder) viene dichiarato come tale nel PLC...

/////////////////// DEVICE  : CSD Cylinder dual drive / dual feedback
Name                      : 532CL
Extend command            : Y_532ECL 
Retract command           : Y_532RCL 
Extended limit switch     : 532CL_ELS  
Retracted limit switch    : 532CL_RLS  
Cylinder error flag       : 532CL_ERRF                  
Extended timer ctrl       : T_532CL_ELS       
Retracted timer ctrl      : T_532CL_RLS
Delay for com. ext.       : T_532ECL            
Delay for com. retr.      : T_532RCL     
...

La assegnazione degli indirizzi dovrebbe anche rispettare una logica lineare di locazione HW associata per gruppo zona, stazione etc.

kop fuk ed altre emita' di svariati vendor NON SONO ISA

kop = LAD ( Ladder Diagram)

fup = FBD (Function Block Diagram)

Queste rappressentazioni sono in corrispondenza con lo standard IEC 61131-3 PLC programming tools.

La definizione simbolica per gli I/O, coils, memorie varie, flags.... non sarebbe escludente allo standard.

esempio

%C0000 = %M0000 = M 0.0 = M00

%C0001 = %M0001 = M 0.1 = M01

.....

%C0016 = %M0016 = M 1.7 - M17

Ciao

Modificato: 23 settembre 2006 da Savino

[Piero Azzoni]

esempio

%C0000 = %M0000 = M 0.0 = M00

%C0001 = %M0001 = M 0.1 = M01

.....

%C0016 = %M0016 = M 1.7 - M17

oltre al discorso sull'uso di definizioni standard aggiungo:

%m001 discende da una visiona moderna del plc cha, come per gli umani (spero) e' decimale

m.0.0 discende da una visiona arcaica del plc, su base ottale che poi, per determinate macchina diviene esadecimale

infatti il tuo esempio e' anche sul piano formale assolutamente errato

%m000 non esiste

m.1.7 non risponde affatto a m17 ne' a %m16

la corrispondenza e' la seguente

   decimale     ottale   esadecimale
    %m001     m.00.0     m.00.00
    %m002     m.00.1     m.00.01
    %m003     m.00.2     m.00.02
     |          |           |
    %m008     m.00.7     m.00.07
    %m009     m.01.0     m.00.08
    %m010     m.01.1     m.00.09
    |           |            |
     %m016    m.01.7     m.00.15
     %m017    m.02.0     m.01.00
     %m018    m.02.1     m.01.01
    |           |            |
     %m064    m.07.7     m.03.15

cio' evidenzia la necessita' operativa di usare nei plc come nella vita la notazione STANDARD DECIMALE e non le stranezze

%m064 e' il sesantaquattresimo merker falg interno, mi pare ovvio

anche m.07.7 & m.03.15 lo sono ma e' un pochetto piu' cervellotico capirlo

in relazione invece al tuo precedente discorso

Vedi Piero, in PLC development Siemens ti offre LAD - STL - FBD - CFC - SFC - MATH (PASCAL) - C - BASIC .. non posso essere d'accordo con te su questo aspetto della mancanza nello standard !

tu stesso ti contraddici

il lad c'e' ma per misteriose ragioni non si chiama lad ma kop

il booleiano c'e' ma si chiama awl

le subroutine si chiamano fb, fc ed altre fantasie

ecc. ecc.

[Savino]

infatti il tuo esempio e' anche sul piano formale assolutamente errato

Su questo ti do' subito ragione..... e' stato un lapsus. ( se ragioniamo sul lato formale pero')

tu stesso ti contraddici

il lad c'e' ma per misteriose ragioni non si chiama lad ma kop

Non e misterioso piero, e' soltanto tedesco.

Loro chiamano KOP al LAD, che ci vuoi fare.

Per quanto riguarda a ragionare che da 0 a 9 ci sono 10 elementi non e' dopotutto cosi diverso a 1-10=10 elementi, dai.

Modificato: 23 settembre 2006 da Savino