Fb, Db Di Istanza - Gestione delle risorse E,A,T....

[TMlm]

Ciao a tutti, sto scrivendo una porzione di codice per gestire una linea di 6 presse identiche ed ho optato per la soluzione che la guida in linea chiama "Un DB di istanza per ogni istanza ".

In pratica sto scrivendo il codice di questo FB101 richiamato più volte all'interno di OB1 (per esempio) ed ogni volta che viene richiamato lavora con un DB di istanza diverso.

In ogni DB di istanza sono contenuti dei valori specifici per ogni pressa, tra cui alcuni temporizzatori.

E proprio nella gestione dei temporizzatori e degi ingressi e delle uscite sto notando che seppur il mio FB101, una volta terminato, viene usato per gestire anche le altre 5 presse, la leggibilità del codice inizia a venir meno.

Per esempio:

come interfaccia INPUT dell'FB101 ho dichiarato una variabile che identifica il numero della pressa

all'inizio dell'FB elaboro il numero della pressa copiando gli ingressi su dei bit locali

al posto delle uscite elaboro dei bit locali che alla fine dell'FB101 copio sulle opportune uscite

il tutto risulta poco leggibile: i bit locali o del DB di istanza compaiono senza commenti al simbolo.

per quanto riguarda i temporizzatori sto pensando di pre-elaborarli prima delle chiamate all'FB101

LA DOMANDA E' QUESTA: è necessario fare tutto ciò che sto facendo o qualcuno ha già trovato soluzioni più eleganti e leggibili?

grazie in anticipo e auguri a tutti, ma soprattutto a chi lavorerà nei prossimi giorni(la maggior parte credo).

[Matteo Montanari]

non riesco a capire perchè dici che è poco leggibile...

non avendo sottomano il codice da te creato non posso dirti o consigliarti come fare, posso però farti un esempio banale di come ho scitto alcuni codici:

FUNCTION_BLOCK FB 1
TITLE =
VERSION : 0.1


VAR_INPUT
  ingresso : BOOL;    
  tempo1 : S5TIME;    
  temp_01 : INT;    
END_VAR
VAR_OUTPUT
  uscita : BOOL;    
END_VAR
VAR_TEMP
  aux_word : WORD;    
END_VAR
BEGIN
NETWORK
TITLE =

      L     #temp_01; 
      T     #aux_word; 
//;
      U     #ingresso; 
      L     #tempo1; 
      SE    T [#aux_word]; 
//;
      U     T [#aux_word]; 
      =     #uscita; 
END_FUNCTION_BLOCK

DATA_BLOCK DB 1
TITLE =
VERSION : 0.0

 FB 1
BEGIN
   ingresso := FALSE; 
   tempo1 := S5T#0MS; 
   temp_01 := 0; 
   uscita := FALSE; 
END_DATA_BLOCK

DATA_BLOCK DB 2
TITLE =
VERSION : 0.0

 FB 1
BEGIN
   ingresso := FALSE; 
   tempo1 := S5T#0MS; 
   temp_01 := 0; 
   uscita := FALSE; 
END_DATA_BLOCK

DATA_BLOCK DB 3
TITLE =
VERSION : 0.0

 FB 1
BEGIN
   ingresso := FALSE; 
   tempo1 := S5T#0MS; 
   temp_01 := 0; 
   uscita := FALSE; 
END_DATA_BLOCK

ORGANIZATION_BLOCK OB 1
TITLE = "Main Program Sweep (Cycle)"
VERSION : 0.1


VAR_TEMP
  OB1_EV_CLASS : BYTE;    //Bits 0-3 = 1 (Coming event), Bits 4-7 = 1 (Event class 1)
  OB1_SCAN_1 : BYTE;    //1 (Cold restart scan 1 of OB 1), 3 (Scan 2-n of OB 1)
  OB1_PRIORITY : BYTE;    //Priority of OB Execution
  OB1_OB_NUMBR : BYTE;    //1 (Organization block 1, OB1)
  OB1_RESERVED_1 : BYTE;    //Reserved for system
  OB1_RESERVED_2 : BYTE;    //Reserved for system
  OB1_PREV_CYCLE : INT;    //Cycle time of previous OB1 scan (milliseconds)
  OB1_MIN_CYCLE : INT;    //Minimum cycle time of OB1 (milliseconds)
  OB1_MAX_CYCLE : INT;    //Maximum cycle time of OB1 (milliseconds)
  OB1_DATE_TIME : DATE_AND_TIME;    //Date and time OB1 started
END_VAR
BEGIN
NETWORK
TITLE =

//      UN    A      0.0; 
//      =     E      0.0; 

//      UN    A      0.1; 
//      =     E      0.1; 

//      UN    A      0.2; 
//      =     E      0.2; 


      CALL FB     1 , DB     1 (
           ingresso                 := E      0.0,
           tempo1                   := S5T#1S,
           temp_01                  := 0,
           uscita                   := A      0.0);

      CALL FB     1 , DB     2 (
           ingresso                 := E      0.1,
           tempo1                   := S5T#2S,
           temp_01                  := 1,
           uscita                   := A      0.1);

      CALL FB     1 , DB     3 (
           ingresso                 := E      0.2,
           tempo1                   := S5T#3S,
           temp_01                  := 2,
           uscita                   := A      0.2);




END_ORGANIZATION_BLOCK

questo esempio è banalissimo, con un ingresso attivi un timer, trascorso il tempo impostato attivi uscita...

è riciamato 3 volte con diversi valori...

[Werner]

Anchio non capisco la poca leggibilita'.

Le variabili locali sono tutte commentabili

Gli ingressi e le uscite , forse, ti conviene usarli come parametri di ingresso e di uscita della FB stessa, se non sono 100.

Nella FB se tieni subito dei parametri di IN/OUT liberi cosi se fai delle modifiche non devi ricrearti la DB di istanza.

Se usi le FB con istanza, e' chiaro che il tempo di campionamento del PLC aumenta sensibilmente, anche se con le "nuove" CPU si hanno prestazioni ottime, almeno per le mie applicazioni.

[emanuele.croci]

Io concordo con Luca: se usi le FB con istanza, non dico che siano POCO leggibili, sicuramente sono MENO leggibili dell'accesso diretto al DB (perché con il DB di istanza le INFORMAZIONI SUL SIMBOLO non le vedi, ed esse sono un aiuto importante durante la programmazione).

Diciamo che il programma risulta UN PO' meno leggibile per l'autore e MOLTO MENO leggibile per un'eventuale altra persona che ci debba lavorare.

D'altronde il vantaggio di poter riusare il software in molti casi ti ripaga abbondantemente di ciò.

Un trucchetto che io talvolta uso durante la scrittura del programma è quello di usare l'accesso diretto al DB la prima volta, poi faccio una cosa del tipo "trova/sostituisci DB101.DBX con DBX e passo tutto al DB di istanza....)

Certo la leggibilità è un concetto psicologico individuale, quindi è un'interpretazione personale...

Ciao, Emanuele

[Lc001]

ciao, prima di tutto non parlo troppo bene italiano..

secondo me (quanto capisco io) la tua via e la via piu esatta possibile, io sempre uso questo metodo.

solo devi sapere per essere online in un fb che si usa nei altri posti fai cosi =>

apri il blocco fb 101 , vai alla debug (a sopra 4. menu dopo il file) la ce operation clicci la , adesso al sotto picchi quel instance db che vuoi vedere con il blocco oppure lo scrivi (numero di blocco) al sotto ..

per esempio quando lavori in settore di automobile ci sono i roll band che muovono l'auto ,tu crei un fb e lo chiami 500 volte ... come ho detto prima il tuo metodo e il metodo piu bello..

io scrivo come cosi ob1 > fc di parte (per esempio painting) > fb ,fb,fb (i roll band) * questo e la struttura piu adatta sempre..

scusate per il mio italiano ciao

[TMlm]

prima di tutto bentornati e auguri per il Natale appena passato e per l'anno che sta per iniziare.

Grazie a keosmm per le seguenti righe che non ero riuscito a trovare sui manuali:

      L     #temp_01; 
      T     #aux_word; 
//;
      U     #ingresso; 
      L     #tempo1; 
      SE    T [#aux_word];

grazie a questo evito la preelaborazione dei temporizzatori.

quando dico che è poco leggibile, mi riferisco al fatto che quando si usano le variabili locali, anche selezionando "Visualizza-->Finestra con-->Informazioni sul simbolo"; effettivamente le informazioni sui simboli delle variabili locali non vengono visualizzate (step7 versione K5.2.1.3 e come confermatomi da Emanuele)

Le 6 presse che gestisco sono idrauliche e quindi abbastanza complesse da darmi una 50ina I/O cadauna più valvole proporzionali ecc, quindi parametrizzarli tutti diventa un un po' frustrante.

Se poi ci si mettono anche i costruttori a non montare tutti i sensori richiesti e nelle posizioni richieste, ecco che il simbolo assegnato ad una variabile temporanea si può confondere con il simbolo di un ingresso o di un'uscita parametrizzati.

E' molto bello lavorare con i db di istanza, con l'ovvio inconveniente dei tempi di esecuzione dovuti al riallocamento dell'immagine di processo, ma come al solito step7 si perde sulle piccolezze:

-impossibilità di visualizzare informazioni sui simboli delle variabili locali (che me lo fanno mettere a fare il commento sul simbolo locale?)

-impossibilità di vedere i riferimenti incrociati delle variabili locali

se c'è qualche amministratore o moderatore che sta leggendo questo post, perchè non si crea tutti insieme un database dei bugs e dei consigli per il miglioramento di step7? (forse sto arrivando tardi... ).

giusto per fare qualche nome: Progea, la software house dello scada movicon accoglie tutti i commenti e consigli che gli si inviano all'indirizzo e-mail di supporto; personalmente mi sono visto realizzare le mie segnalazioni ed i miei consigli sempre nell'arco di una o due build-release.