Indicizzazione al nome della variabile

[JulesTechnic]

Buongiorno,

 

in questo periodo pre-natalizio, nell'azienda dove lavoro abbiamo un momento di tregua. Ci siamo allora messi a guardare come rendere più in stile "TIA Portal" alcune funzioni che implementiamo sempre nei nostri software e che sono derivate dai vecchi PLC serie 300.

 

In queste funzioni ovviamente viene fatto largo uso dei puntatori ANY, con linguaggio AWL. Qualcuno di voi si è percaso imbattuto in una soluzione per puntare in modo indicizzato ai nomi delle variabili invece che all'indirizzo? Provo a spiegarmi meglio:

 

Mettiamo che nel mio impianto io abbia 3 DB, ciascuna contenente i dati di una ricetta. Mettiamo che le 3 DB si chiamino "Ricetta 1", "Ricetta 2" e "Ricetta 3". Le 3 DB sono identiche e supponiamo che contengano ciascuna i seguenti dati:

 

Io posso scrivere nel mio codice qualcosa di questo tipo:

 

È possibile rendere "Ricetta 1" una variabile indicizzata? In modo da poterla cambiare in "Ricetta 2" e "Ricetta 3"?

 

Spero di essermi spiegato, so che è possibile fare gli array e puntare tramite essi, ma non è la soluzione che cerchiamo.

 

Spulciando l'aiuto in linea di Siemens mi sono anche imbattuto nelle cosidette "Array DB", qualcuno le usa? Nella guida dice:

 

Qualcuno le usa? Possono aiutarmi a ottenere il risultato che cerco?

 

Grazie mille intanto per l'attenzione.

Modificato: 13 dicembre 2019 da JulesTechnic

[Simone.Salarsi]

io farei una roba del genere :

 

Credo un tipo di dati della ricetta

 

 

Creo una DB con all'interno un array del numero di elementi con tipo di dato UDT_Ricetta che mi servono

 

 

e poi lo andrei ad indicizzare così

 

[JulesTechnic]

Grazie Simone,

certo sarebbe il metodo più comodo, però ci troviamo anche a lavorare su impianti grandi dove chiedono più di 20 ricette, con dentro valori in REAL, stringhe di testo ecc. Quindi col problema di sforare le dimensioni massime della DB, per questo cercavo se c'era la possibilità di indicizzare il nome della DB e non tramite array.

[batta]

 

certo sarebbe il metodo più comodo, però ci troviamo anche a lavorare su impianti grandi dove chiedono più di 20 ricette, con dentro valori in REAL, stringhe di testo ecc. Quindi col problema di sforare le dimensioni massime della DB

Lavorando con DB ottimizzati, nella più piccola CPU della serie 1500, la dimensione massima di un DB è di 750 KB.
Lavorando con DB non ottimizzati, la dimensione massima di un DB (credo uguale per tutte le CPU) è di 64 KB.
In pratica, nella peggiore delle ipotesi, per 20 ricette, significa circa 800 variabili REAL per ogni ricetta.

 

[JulesTechnic]

Grazie @batta, comunque mi confermi che non c'è un modo per lavorare con una DB ottimizzata per ogni ricetta? L'unica soluzione è fare come prima, DB non ottimizzate e  puntatore ANY.

[batta]

Al momento, una soluzione per fare quello che vorresti non mi viene in mente.
Non capisco però perché tu voglia avere un DB per ogni ricetta.
Con un solo DB, con un array di STRUCT (dove ogni elemento dell'array è una ricetta), tutto diventa estremamente semplice, anche in ladder. Meglio ancora se lavori in testo strutturato.
Questa storia di un DB per una ricetta mi pare solo una complicazione inutile, non riesco a capirne il vero motivo.
Comunque, se vuoi procedere su quella strada, prova a valutare anche la possibilità di lavorare in testo strutturato con le istruzioni PEEK e POKE.
Prova anche a guardare i dati di tipo Variant, DB_ANY, conversioni da DB_ANY a Variant.

Modificato: 20 dicembre 2019 da batta

[batta]

Guarda anche le istruzioni ReadFromArrayDB e WriteToArrayDB.

Dovresti riuscire a fare quello che desideri, ma sono sempre dell'idea che si tratta solo di una complicazione inutile.
Tra l'altro quando crei una nuova ricetta, crei il nuovo DB in runtime, con l'istruzione CREATE_DB?

Anche questa è una complicazione che eviteresti, gestendo tutte le ricette in un solo DB di dimensioni generose.

[JulesTechnic]

Grazie ancora @batta... Quella degli Array è una soluzione che avevo già proposto in azienda, ma non aveva convinto, allora ho provato a chiedere. Vedremo se accetteranno di iniziare a lavorare nel modo che proponi giustamente tu.

[ken]

io uso sempre gli array con tia.

ora mi ci sono trovato costretto ad usare 4 DB perchè vengono scritte con una query sql con dei dati di lavorazione che arrivano da ufficio.non sono scritti da me e per comodità vengono scritte in uno dei 4 db identici.

ho fatto alla fine un tipo di dato e nei dati temporanei ho creato un area con lo stesso tipo di dato. una scelta con un IF e vado a scrivere nei dati locali il db che mi serve. da li lavoro poi ad array come sempre. è più dispendioso perchè mi creo un ulteriore db temp ma così lavoro più facilmente.

nel mio caso però sono solo 4.

[Cesare Nicola]

 

Con un solo DB, con un array di STRUCT (dove ogni elemento dell'array è una ricetta), tutto diventa estremamente semplice, anche in ladder. Meglio ancora se lavori in testo strutturato.

Confermo. Lo faccio abitualmente per un cliente in particolare ma poi l'ho adottato anche per altri ed è comodissimo. Crei un UDT con la struttura della ricetta, poi usi una STRUCT per la ricetta attualmente visualizzata su HMI, una STRUCT per la ricetta in lavorazione e un array di n STRUCT per l'archivio ricette. Comodissimo e in poche righe di SCL o KOP sposti, leggi, fai quello che vuoi con le tue ricette. Per dare un'idea delle dimensioni, uso 99 ricette da circa 50 byte l'una, su CPU 1500 di diverse taglie.

Modificato: 21 dicembre 2019 da Cesare Nicola

[batta]

 

Quella degli Array è una soluzione che avevo già proposto in azienda, ma non aveva convinto

Convincili: è il modo migliore. Assurdo avere un DB per ogni ricetta.

[Cesare Nicola]

 

Quella degli Array è una soluzione che avevo già proposto in azienda, ma non aveva convinto

Sarei curioso di sapere il perché non convincono. Qui trovi un esempio, è per Mitsubishi ma sarebbe identico per Siemens:
 

(********************************************************

DESCRIZIONE

Lettura, salvataggio e messa in esecuzione delle ricette.
Le ricette sono salvate in memorie ritentive del PLC anzichè nel pannello come di solito accade, a partire da D2500.

********************************************************)

// Il numero 0 come archivio ricetta non è ammesso
IF Ricetta_HMI.Numero = 0 THEN
    Salva_ricetta := FALSE;
    Legge_ricetta := FALSE;
    Carica_ricetta := FALSE;
END_IF;

IF Ricetta_HMI.Numero > 0 THEN
    // Salvataggio ricetta da HMI ad archivio nel PLC
    IF Salva_ricetta THEN
        Salva_ricetta := FALSE;
        Archivio_ricette[Ricetta_HMI.Numero] := Ricetta_HMI;
    END_IF;

    // Lettura ricetta da archivio nel PLC a HMI
    IF Legge_ricetta THEN
        Legge_ricetta := FALSE;
        Ricetta_HMI := Archivio_ricette[Ricetta_HMI.Numero];
    END_IF;

    // Messa in esecuzione ricetta da HMI a PLC
    IF Carica_ricetta THEN
        Carica_ricetta := FALSE;
        Ricetta := Ricetta_HMI;
    END_IF;
END_IF;

 

In 36 righe, intestazione, commenti e spazi compresi, fai:

• Salvataggio da HMI in archivio
• Lettura da archivio ad HMI
• Messa in esecuzione da HMI

Con poche righe in più faresti anche "cancella ricetta" e "sovrascrivi ricetta", che qui non erano necessari. In KOP occuperebbe più spazio a video, per la natura "grafica" del KOP, ma sarebbe concettualmente identico. Ovviamente ognuno la vede come vuole, ci mancherebbe, ma sostenere che non sia efficace mi sembra piuttosto difficile.

---

[JulesTechnic]

@Cesare Nicola i motivi erano 2 principalemente:
1. Aveva già risposto Batta ed era relativo alle dimensioni finali delle DB;
2. La paura di perdere i dati di tutte le ricette se si fa la ca**ata di aggiungere qualcosa o modificare un commento al tipo di dati senza avere da parte un'istantanea dei valori in DB. Dopo quando carichi ti chiede di reinizializzare e hai perso i dati attualmente in uso

[batta]

Se si teme di poter perdere tutti i dati a seguito reinizializzazione del DB, si può sempre fare una copia completa in un "DB di backup".

Poi, a dirla tutta, io sono contrario alla gestione delle ricette nel PLC. Tutti i pannelli operatore (esclusi solo quelli di livello molto basso) e tutti gli SCADA hanno strumenti dedicati, e permettono anche l'archiviazione delle ricette su supporti esterni (USB, rete, ecc.). Perché non usare queste funzioni? 

[Cesare Nicola]

1 ora fa, batta ha scritto:

Perché non usare queste funzioni?

Nel caso di un mio cliente credo che sia per rendersi indipendente dal pannello utilizzato. In altri casi in cui ho scelto io di fare le ricette nel PLC era per macchine molto semplici, per evitare di dover imparare la gestione ricette di un pannello che non conosco e che magari non userò più per n anni (ridurre i costi di sviluppo, insomma) oppure per pannelli la cui gestione ricette è un po' cervellotica (anche qui, quindi per ridurre i costi di sviluppo). A me non dispiace, se ci sono le condizioni, lavorare così. L'esigenza di un backup, è vero, può esistere; al momento non è arrivata nessuna richiesta dai clienti per i quali ho usato tale sistema, è sempre andato bene così. Nel caso del cliente che mi impone tale scelta, si tratta di una multinazionale con dei suoi standard, non sono nemmeno stato a sindacare, onestamente: lego l'asino dove vuole il padrone. 🙂

 

[ifachsoftware]

Quote

Perché non usare queste funzioni?

Per esempio quando si abbia la necessità di editare ricette sia da pannello operatore (direttamente in macchina) che magari dall'ufficio.

[leleviola]

6 ore fa, batta ha scritto:

Se si teme di poter perdere tutti i dati a seguito reinizializzazione del DB, si può sempre fare una copia completa in un "DB di backup".

Poi, a dirla tutta, io sono contrario alla gestione delle ricette nel PLC. Tutti i pannelli operatore (esclusi solo quelli di livello molto basso) e tutti gli SCADA hanno strumenti dedicati, e permettono anche l'archiviazione delle ricette su supporti esterni (USB, rete, ecc.). Perché non usare queste funzioni? 

Come non condividere, in passato ho utilizzato pannelli con ricette da 4000passi cadauna, farlo su PLC non sarebbe possibile, poi la possibilità sui pannelli di usare chiavette USB è anche comodo per il cliente che può elaborarsi le ricette salvate su chiavetta e modificarle in un secondo momento su PC

[Cesare Nicola]

Nel caso di HMI su PC anziché su pannello operatore, io mi sono trovato molto bene anche a gestire le ricette su file di testo; ogni ricetta è un file txt. E' sicuramente laborioso la prima volta, bisogna creare un po' di script, ma in seguito hai il vantaggio di avere ricette dalla lunghezza e quantità quasi illimitata, puoi creare la funzione "cerca ricetta" che non esiste in Siemens (cerca introducendo una parte del nome o anche con un barcode), il backup diventa un semplice copia/incolla di una cartella, puoi editare o creare le ricette al di fuori dell'HMI con un semplice editor di testo.

[leleviola]

Si come crearle in .csv puoi tranquillamente modificarle con editor di testo o Excel, così il cliente fa come vuole e le modifica a piacere per poi ricaricarle