Utilizzo Di Merker All'interno Di Un Programma - Quante volte si possono ripetere?

[Reverendo bit]

Ciao a tutti

Vorrei chiedevi una piccola delucidazione in merito alla possibilità di utilizzare più volte nello stesso programma o nello stesso FC la stessa Merker.

Premesso che:

fino a qualche giorno fa ero convinto che la stessa merker usata come risultato finale dell' RLC in segmenti diversi non era possibile farlo.

Esempio

Seg_1

U E0.0

U E0.1

= M0.0

Seg_2

U M0.0

CALL FC10 (FC parametrizzato)

Seg_3

U E0.2

U E0.3

= M0.0

Seg_4

U M0.0

CALL FC10 (FC parametrizzato)

Come vi dicevo fino a qualche giorno fa ero convinto che durante l'esecuzione del programma se il risultato del Seg_3 poneva M0.0 =0, anche nel Seg_1 M0.0=0

come del resto accade per le uscite fisiche.

Potreste spiegarmi come e possibile?

Ciao Reverendo

Modificato: 13 maggio 2010 da Reverendo bit

[mubeta]

Anche una uscita fisica la puoi ripetere più volte nel programma ... alla fine del ciclo OB1 verrà inviato all'uscita hardware l'ultimo valore che aveva assunto.

Non c'è nulla di speciale, le tue convinzioni, forse, derivano dal pensare alla logica del programma, come logica a relè. Nulla di più sbagliato.

Una brevissima spiegazione: gli ingressi e le uscite vengono letti e scritti solo una volta, per ogni elaborazione completa del programma. Quando OB1 ha completato tutte le elaborazioni, richiami, ecc, e completa l'ultimo segmento, il controllo del programma torna al firmware, che inizia a scrivere sulle periferie tutti i risultati memorizzati temporaneamente in quella che si dice "immagine delle uscite"; contestualmente, esegue le lettura, quasi simultanea, di tutti gli ingressi, che memorizza in quella che si chiama "immagine degli ingressi". Non è ne più ne altro che una zona di RAM, come è una zona di RAM l'area dei merker, e tutto il resto, d'altro canto.

ogni segmento (ed anche le fasi intermedie), sono fini a loro stessi. Elaborano delle istruzioni e memorizzano in qualche modo il risultato: un merkr, un'uscita, un ingresso, una variabile. (Già, anche un ingresso. Se il compilatore non lo impedisce, puoi scrivere il risultato di una elaborazione anche in un ingresso). Ed il tutto può variare quante volte vuoi ... nei limiti delle capacità mnemoniche per le dimensioni del programma, puoi scrivere un poco tutto cosa vuoi. Alla fine, come dicevo, quanto il ciclo di OB1 sarà completo, quello che resta nella immagine di processo, viene trasferito alle uscite. (Problema tuo se hai ripetuto una uscita e ti sembra che il programma non funzioni; problema tuo se hai sovrascritto, impropriamente detto "sporcato", un ingresso, od altro, e nella elaborazione successiva non ha più il valore che ti spettavi).

Insomma, l'elaborazione del programma, (tolte istruzioni particolarissime), si basa sulla manipolazioni di dati in memoria RAM, che non costa nulla dal punto di vista della fattibilità e del numero di volte. Può darsi che alle volte ti imbatti in errori riconosciuti tali, o dichiarati, dal compilatore, perché qualcuno ha pensato di limitare un poco i "danni" derivanti da cattiva programmazione; ma nulla di più. Non sempre la programmazione è cattiva, alle vlte è desiderata, e si litiga col PC.

[batta]

Non c'è un limite al numero di volte che puoi leggere o scrivere lo stato di un merker.

Devi però tenere presente che, quando andrai ai interrogare lo stato del merker, lo stato sarà quello della precedente assegnazione.

Esempio:

Nel segmento 1 assegni a M0.0 lo stato TRUE.

Nel segmento 2 interroghi lo stato di M0.0 che sarà, quindi, TRUE.

Nel segmento 3 assegni ad M0.0 lo stato FALSE.

Nel segmento 4 interroghi lo stato di M0.0 che sarà, quindi, FALSE.

Più logico di così...

Diversa è invece la questione della visualizzazione dello stato di M0.0 in una VAT.

Se nella stessa scansione lo stato di M0.0 continua a cambiare, cosa dovrebbe essere visualizzato???

Lo stato visualizzato nella VAT sarà quello di M0.0 ad inizio o a fine della scansione, secondo configurazione.

[Reverendo bit]

Chiaro

Ma ad un dubbio risolto ne nascono di nuovi, ad esempio, l'utilità di usare sempre le stesse memorie per un richiamo sistematico dello stesso FC parametrizzato, può di certo limitare la quantità di memorie utilizzate all'interno del programma, ma come detto da batta implica una più difficile lettura delle stesse all'interno della VAT.

secondo voi è più pratico utilizzare sempre le stesse memorie limitando il numero di memorie occupate

o utilizzare memorie diverse aumentando le memorie utilizzate ma avendo la possibilità di controllare in maniera più precisa il software?

[Mike65]

Credo che utilizzare diverse volte la stessa memoria sia uno stile di programmazione che deriva dalle scarse risorse dei primi PLC, ora non è più necessario, tanto più che si possono usare come memorie anche i blocchi dati, e la velocità delle moderne CPU è tale da non penalizzare assolutamente il tempo ciclo.

Ciao a tutti

[lucios]

Due cose basilari di cui tener conto quando fai un programma (non importa in quale linguaggio e di quale piattaforma) sono:

1 Facilità di lettura

Occorre che, anche dopo anni dallo sviluppo, tu riesca a rileggerlo e a metterci le mani senza impazzire, quindi: linearità di progettazione, simbolici ben fatti e soprattutto tanti commenti! Su questi si che è meglio non risparmiare memoria.

2 Facilità di debug

Evitare quindi: giri strani, utilizzo sapiente di puntatori, merker, fb parametriche, ecc.

I 2 punti, come capirai, sono coincidenti, e, soprattutto se programmi in AWL (che come ho precedentemente accennato in altri post) lo considero un linguaggio da giramento di zebedei sono fondamentali.

[Reverendo bit]

Premessa

Il software che sto leggendo non l'ho scritto io, lo devo interpretare per fare delle modifiche, leggendolo ho notato che sono state usate per dei richiami sistematici sempre le stesse memorie.

Facilità di lettura, Facilità di debug

Concordo con quanto detto da Lucios, e prendo per buono quanto detto da Mike (visto che non ho mai programmato un PLC di vecchia generazione ma ho iniziato con gli S7 300).

Dalla mia poca esperienza credo di poter dire che se si vuole una più facile lettura del software (anche tramite una vat) bisogna usare più merker in modo da poterne controllare lo stato per ogni singolo richiamo.

soprattutto se programmi in AWL lo considero un linguaggio da giramento di zebedei

All'inizio è un po ostico, ma se entri nella filosofia AWL, letteralmente scrivi quello che vuoi far far al software.

Saluti.

[batta]

Si deve distinguere se lo stesso merker è comandato più volte nel programma ma ha sempre la stessa funzione, oppure se assume di volta in volta funzioni diverse.

Nel primo caso, specialmente se si utilizzano le istruzioni S/R direi che è assolutamente normale, anche se è meglio evitare di "sparpagliare" in giro per tutto il programma miriadi di istruzioni S/R dello stesso merker.

Nel secondo caso, salvo l'utilizzo come bit di appoggio da riutilizzare immediatamente dopo (ma allora preferisco usare variabili locali), direi che è da evitare come la peste.

All'inizio è un po ostico, ma se entri nella filosofia AWL, letteralmente scrivi quello che vuoi far far al software.

Concordo in pieno.

Anzi, rispetto al KOP, specialmente per i calcoli, permette di fare le stesse cose in modo più lineare e con un sacco di istruzioni in meno.

[Reverendo bit]

Si deve distinguere se lo stesso merker è comandato più volte nel programma ma ha sempre la stessa funzione, oppure se assume di volta in volta funzioni diverse.

Allora il Software comanda una ventina di utenze tra valvole e motori, queste utenze sono gestite tutte da un FC parametrizzato che viene richiamato di volta in volta.

Naturalmente l'FC ha delle variabili di ingresso ed uscita (variabili locali), una delle variabili d'ingresso è il consenso alla marcia in automatico, che per tutti i richiami di questo FC, e appoggiata sempre alla stessa Merker, che però, per ogni utenza e generata da ingressi fisici diversi.

Esempio

seg1

u e0.0

ue0.1

=m0.1 \\appoggio marcia in automatico utenza x

seg2

call fc10 (gestione utenze)

marcia_aut = m0.1

start = a0.0

seg3

u e0.2

ue0.3

=m0.1 \\appoggio marcia in automatico utenza y

seg4

call fc10 (gestione utenze)

marcia_aut = m0.1

start = a0.1

seg5

u e0.3

ue0.5

=m0.1 \\appoggio marcia in automatico utenza z

seg2

call fc10 (gestione utenze)

marcia_aut = m0.1

start = a0.2

etc..etc..

e cosi via ripetuto per tutte e venti le utenze, ma in questo modo mi e impossibile controllare da una vat, se un'utenza è abilitata alla partenza in automatico oppure no, posso farlo solo se apro l'FC e vado in dinamica ma non è molto pratico

Nel primo caso, specialmente se si utilizzano le istruzioni S/R direi che è assolutamente normale, anche se è meglio evitare di "sparpagliare" in giro per tutto il programma miriadi di istruzioni S/R dello stesso merker.

Chiaro ed è normale anche per me, anche perchè cosi la usi per riportare lo stato del set-reset in un'altra parte del programma, non credo sia questo il caso.

Nel secondo caso, salvo l'utilizzo come bit di appoggio da riutilizzare immediatamente dopo (ma allora preferisco usare variabili locali), direi che è da evitare come la peste.

credo propio che le memorie sono state utilizzate con questo fine rendendo il software di difficile lettura quando è in esecuzione.

Modificato: 17 maggio 2010 da Reverendo bit