Come fare senza AWL?

[STEU]

Buongiorno

ho una serie di macchine che hanno il ciclo IDENTICO, ma hanno, per motivi che è troppo lungo spiegare, uscite e ingressi con indirizzi diversi.

quindi l'uscita , che per comodità chiamo EV1, in una maccnima è A10.0  in un' altra macchina A12.5.

Il problema è risolvibile assegnando un bit di una DB,es DB20.dbx12.0, che fa la funzione di EV1.

poi ho un FC dove scrivo l'indirizzo della valvola via HMI, es MD20

quindi per 10.0 MD20=1010000 (bin)(10.0), per 12.5 MD20=1100101 (bin)(12.5)

 

quindi scrivo per l' uscita

U DB20.DBX12.0

= A[MD20]

 

in questo modo lo stesso programma va bene per tutte le macchine basta inserire nell'HMI il valore giusto di MD20.

Funziona perfettamente.

 

Come fare tutto ciò senza AWL?

Grazie mille in anticipo per l'aiuto

 

Modificato: 13 maggio 2021 da STEU

[acquaman]

in SCL

A[MD20] := DB20.DBX12.0;

[STEU]

Grazie ma mi da errore, sia mettendo i valori assoluti che i nomi delle variabili

[STEU]

Tra l'altro , non so se sbaglio quanlcosa, ma non mi accetta nemmeno questa istruzione, sembra che in SCL non si possa indirizzare in modo assoluto , nè con accesso ottimizzato che non ottimizzato.

 

A0.0 := true;

 

non è accettato

[Mattia Spoldi]

prova a guardare le funzioni peek_bool e poke_bool

[walterword]

l'indice di un array in SCL dovrebbe essere un intero non doppio intero almeno per quello che so io.

Prova con %Q0.0:=true; in TIA portal  ti crea automaticamente il simbolico come "tag_x";

I soliti casini quando bastava scrivere ogni uscita come cosa a se. 

Prova a creare un array di appoggio in un DB e tramite l'indice imposti quello desiderato. e poi scrivi le uscite singolarmente da ogni elemento.

 

"DB_USCITE".Out[ indice]:=valore_booleano;

 

Q0.0:= "DB_USCITE".Out[ 0];

Q0.1:= "DB_USCITE".Out[ 1];

Q0.2:= "DB_USCITE".Out[ 2];

...etc

 

Modificato: 13 maggio 2021 da walterword

[STEU]

@walterword piuttosto cambio indirizzo alla tabella variabili di volta in volta, o quasi sicuramente lascerò AWL

@Mattia SpoldiAndrò a vedere queste istruzioni e farò sapere

 

Per intenderci il vantaggio di usare questo sistema è che caricato PLC caricato HMI , il collaudatore senza rompermi le scatole mette indirizzi di ingressi e uscite nell'HMI e si fa le sue prove.

[batta]

Potresti fare con POKE_BOOL.

 

Ma non è più facile risistemare la lista I/O?

 

Ooops... qualcuno lo aveva già suggerito.

Modificato: 13 maggio 2021 da batta

[STEU]

@battaNo perchè devo farlo 10, e la parte di HMI diventa inutile. mentre con il sistema HMI il collaudatore , che è un meccanico, con lo schema in mano compila la tabella in 5 minuti e fa partire la macchina

[peppe77k]

Ciao,

ti indicizzi le uscite digitali definendo un nuovo "tipo di dati PLC"

 

poi ti definisci una nuova variabile del tipo

 

 

e accedi alla i-esima uscita digitale (indice) tramite l'istruzione SCL

 

indice := MD20;

 

e poi setti l'uscita corrispondente

 

MAIN_PLC_Output.Q[indice] := 1;

 

 

 

[STEU]

Capisco cosa vuoi dire ma che relazione posso avere con l'indice dell'array e l'indirizzo, come faccio ad avere per l'indic 0 dell'arrai l'indirizzo 10.0 , e sulla prossima macchina l'indice 0 rapportarlo con l'indirizzo 24.3?

Forse modificando un po di codice dell' HMI potrei utilizzare le istruzione Peek o poke suggerito da @Mattia Spoldi.

Anche se la legge non vieta di utilizzare un FC in AWL

[batta]

Potresti anche creare un tipo di dati con un array di bool che contenga tutte le uscite.
Poi, nella tabella delle variabili, come tipo di dati dichiari il tipo di dati creato per le uscite, e metti l'indirizzo della prima uscita.

A questo punto le tue uscite sono tutte in un array, diventa facile:

Uscita[idArray] := "DB_Uscite".EV1;

 

Capisco il vantaggio di mandare solo un meccanico a collaudare una macchina, ma la lista I/O si può compilare tranquillamente anche in un foglio excel, e fare un copia/incolla nella lista I/O del TIA.

E si toglie tutta la parte di HMI che serve solo per mappare le uscite.

Tra l'altro, se il meccanico ti sbaglia un indirizzo, mi sa che per scovare l'errore ci vuole un po'.

 

 

Oggi è già la seconda volta che qualcuno mi precede 🙂

 

Modificato: 13 maggio 2021 da batta

[batta]

4 minuti fa, STEU scrisse:

Capisco cosa vuoi dire ma che relazione posso avere con l'indice dell'array e l'indirizzo, come faccio ad avere per l'indic 0 dell'arrai l'indirizzo 10.0 , e sulla prossima macchina l'indice 0 rapportarlo con l'indirizzo 24.3?

Supponendo che l'array delle uscite inizi da Q0.0, l'indice dell'array diventa semplicemente nrByte * 8 + nrBit.
Quindi, se l'uscita è 10.0, l'indice è 80; se l'uscita è 24.3, l'indice è 195.

[STEU]

@batta ma se l'uscita fosse 150.0?  Non è dichiarata nella tabella dovrei avere un array improponibile

[peppe77k]

6 minuti fa, STEU scrisse:

@batta ma se l'uscita fosse 150.0?  Non è dichiarata nella tabella dovrei avere un array improponibile

ti faresti un array di 150*8 elementi.

Non penso sia la fine del mondo per il PLC di oggi.

 

[batta]

1 ora fa, peppe77k scrisse:

Non penso sia la fine del mondo per il PLC di oggi.

Esatto. In fondo, si tratta solo di 151 byte (partendo da zero). Che poi non occupano nemmeno memoria, perché sono nell'area delle uscite.
Anche dovessi fare un array molto più grande, non è un problema.

 

E poi hai anche il vantaggio che, se apri l'array nella tabella I/O, vedi direttamente a quale uscita fisica corrisponde ogni elemento dell'array.

 

Potresti anche decidere di creare array diversi, per esempio, per le uscite nel rack della CPU, per quelle del primo nodo, per quelle del secondo, e così via.

 

Alla fine, diventa molto più facile da gestire rispetto al puntatore in AWL.

Modificato: 13 maggio 2021 da batta

[STEU]

Effettivamente  con il 1500 non ci sono problemi di memoria ci penserò , il mio obbiettivo è avere software AWL free

 

[batta]

5 minuti fa, STEU scrisse:

Effettivamente  con il 1500 non ci sono problemi di memoria ci penserò

Non ci sono nemmeno con il 1200, e neppure con il 300.
Con 1024 byte fai 8192 uscite. 1 KB.

Che poi, come detto, non occupano memoria, perché sono solo una dichiarazione nella tabella delle variabili, non sono byte di un DB.

[STEU]

4 ore fa, batta scrisse:

Tra l'altro, se il meccanico ti sbaglia un indirizzo, mi sa che per scovare l'errore ci vuole un po'.

E' la prima cosa che controllano loro , e poi io , non puo' non funzionare

 

[ifachsoftware]

Ciao , secondo me l'utilizzo di array è un approccio sbagliato.

 

Se hai delle valvole  ti crei degli udt tipo UDT_VALVOLA  in cui ci metti tutti i dati che la riguardano  (magari suddivisi un ulteriori sotto UDT richiamati in quello principale)

 

Per esempio :

 

UDT_VALVOLA

{

     UDT_VALVOLA_CFG CFG;

     UDT_VALVOLA_IN IN;

     UDT_VALVOLA_OUT OUT;

}

 

UDT_VALVOLA_CFG

{

     String Tag;  // Nome della valvola

      int Finecorsa;    // 0 = Nessuno / 1 = Finecorsa Aperto / 2 = Finecorsa Chiuso / 3 = Finecorsa Aperto + Chiuso

      

      String TagOpen; // Nome del micro di aperto

      String TagClosed; // Nome del micro di chiuso

}

 

UDT_VALVOLA_IN

{

      Bool MicroOpen;  // Ingresso del finecorsa Aperto (True = Aperto / False = Chiuso)

      Bool MicroClosed; // Ingresso del finecorsa Chiuso (True = Aperto / False = Chiuso)

}

 

UDT_VALVOLA_OUT

{

      Bool Cmd;

}

Poi ti crei una DB non ottimizzata (visto che stiamo parlando di 1500)

 

tipo 

 

DB_PLANT

{

       UDT_VALVOLA Valvola1;

       UDT_VALVOLA Valvola2;

       UDT_VALVOLA Valvola 3;

       UDT_VALVOLA Valvola 4;

}

 

Oppure se l'impianto ha piu' macchine , le raggruppi sempre tramite UDT dedicati per singola macchina

 

UDT_PRESSA

{

      UDT_VALVOLA ValvolaApre;

      UDT_VALVOLA Chiude;

}

 

DB_PLANT

{

       UDT_PRESSA Pressa1;

       UDT_PRESSA Pressa2;

}

 

Una volta strutturata in questa maniera la base dati 

 

Puoi fare un Fc di assegnazione variabili

 

FcSetInput()

{

      DB_PLANT.Pressa1.MicroOpen = I10.0;

      DB_PLANT.Pressa2.MicroClosed = I11.5;

      DB_PLANT.Pressa1.MicroOpen = I11.6;

      DB_PLANT.Pressa2.MicroClosed = I11.1;

 .....

}

Per esempio in queste assegnazioni siccome la logica prevede True = Aperto e False = Chiuso , se dovessi avere delle logiche negate in campo , qui semplicemente le aggiusti

      DB_PLANT.Pressa1.MicroOpen = I10.0; ->       DB_PLANT.Pressa1.MicroOpen = NOT I10.0;

 

 

FcSetOutputs()

{

      Q0.0 = DB_PLANT.Pressa1.Cmd;

      Q0.1 = DB_PLANT.Pressa2.Cmd;

 .....

}

 

E queste se le compila l'installatore , avendo dei nomi chiari in base alla posizione

 

in DB_PLANT si impostano come valori di avvio tutti i parametri della sezione CFG di ogni oggetto tipo 

 

Tag = "EV1"

 

 

 

 

A questo punto se devi gestire la tua pressa ti crei un FB tipo FB_PRESSA come parametro IN/OUT il campo Data di tipo UDT_PRESSA dove gestisci tutte le funzionalità della tua Pressa

 

Poi inserisci X istanze del tuo FB Pressa in cui passi i relativi parametri.

 

A questo punto hai gestito in maniera pulita il tuo impianto e per debuggarlo basta che ti metti in monitor sull'istanza dell'FB che ti interessa.

Senza considerare che potresti creare dei faceplates per gestire le impostazioni del tuo impianto , passando come dato la sola struttura principale (naturalmente utilizzando dei pannelli Comfort)

 

 

I vantaggi sarebbero :

 

1) estrema chiarezza delle variabili in campo

2) Un unico Fb per gestire la nostra funzionalità

3) Estrema leggibilità (ti metti in monitor sulla DB_PLANT e vedi tutto)

4) Se linki nel faceplate vedi immediatamente di che oggetto stai parlando in quanto che se visualizzi la stringa Tag ti dice il nome della valvola o del finecorsa associato

5) Debug per singola pressa

 

Lavorando con gli indici devi sapere che l'indice 159 corrisponde alla KV10 e l'indice 300 alla KV200 , secondo me è assurdo

 

Sicuramente ci vorrà del tempo per strutturare degli UDT , ma questo comporta il fare un'analisi del problema , ma ti ripagherà alla grande nell'evolversi di un progetto.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[walterword]

Ci vuole un corso universitario per aprire una valvola.....😄

 

[batta]

8 ore fa, ifachsoftware scrisse:

Se hai delle valvole  ti crei degli udt tipo UDT_VALVOLA  in cui ci metti tutti i dati che la riguardano

Non è questo ciò che è stato chiesto.

[walterword]

Ifach sei OT.....😄

 

[STEU]

Ti ringrazio Ifach, ma mi sembra un po' fuori tema ciò che scrivi.

Comunque il mio caso, che capisco sia più unico che raro, senza AWL si complica il codice, con AWL  avevo x uscite y ingressi e con una'array di indici lungo x + y risolvevo tutto, invece in SCL o KOP il codice diventa più ostico da capire.

[batta]

8 minuti fa, STEU scrisse:

invece in SCL o KOP il codice diventa più ostico da capire.

Perché dici che diventa più ostico? A me pare più semplice.