Gestione ricette su files

[Roberto]

Utilizzo i Vs sistemi SlimLine per realizzare dei controlli su iimpianti industriali, ora avrei la necessità di gestire un ricettario.

Esistono dei blocchi funzione che permettono in modo semplice di realizzare la gestione di un ricettario.

[Sergio Bertana]

E’ possibile utilizzare il blocco funzione FileMemoryDump (Manuale utente), il cui scopo è di eseguire il dump di una zona di memoria su di un file su disco e/o di leggere un dump da un file su disco e trasferire i valori in una zona di memoria.

In pratica definita un’area di memoria dove sono allocati tutti i parametri di una ricetta con l’FB è possibile trasferire i valori presenti in quest’area di memoria su di un file su disco salvandoli con il nome della ricetta. E’ possibile quindi avere più files con nomi diversi che contengono le diverse impostazioni di ogni ricetta.

Il file salvato è in formato ascii, quindi è editabile con un comune text editor, accedendo al file system di SlimLine in FTP è possibile trasferire i files di ricetta sul proprio PC e/o viceversa.

Allego un progetto LogicLab che dimostra come realizzare una semplice gestione di ricette, nell’esempio tutti i parametri della ricetta sono stati definiti all’interno di una struttura dati, in questo modo basterà effettuare il dump su disco della intera struttura dati per salvare la ricetta (Stampa programma, Programma sorgente).

[Roberto]

Ho guardato l’esempio ma non comprendo come faccio ad adattarlo alla mia esigenza, il programma è già fatto e i dati non sono in una struttura. A me servirebbe la possibilità, di salvare l’area ritentiva o parte di essa in un file.

[Sergio Bertana]

L’esempio riporta come dovrebbe essere fatta una gestione di ricette, di solito si definisce una struttura dati con tutti i parametri della ricetta. La struttura dati verrà allocata in area RETAIN, se deve essere accessibile da modbus verrà allocata nella zona tampone della DB100.

Ma il mio è solo un esempio, se tu leggi bene il manuale del blocco funzione FileMemoryDump scopri che non vi sono limiti sull’area di memoria su cui eseguire il dump. Se vuoi salvare una parte oppure anche tutta l’area ritentiva della DB100 basterà definire come MBufferPtr l’indirizzo di inizio dell’area tampone e in MBufferSize la dimensione in bytes che vuoi salvare. Ecco nell’esempio salvi/carichi tutti i 2048 bytes dell’area tamponata.

    RMng(); (* Gestione dump memoria *)
    RMng.Enable:=TRUE; (* FB enable *)
    RMng.Read:=FALSE; (* Comando lettura ricetta *)
    RMng.Write:=FALSE; (* Comando scrittura ricetta *)
    RMng.Filename:=’Storage/Recipe.txt’; (* Nome file ricetta *)
    RMng.MBufferPtr:=ADR(%MX100.2048); (* Pointer buffer parametri *)
    RMng.MBufferSize:=2048; (* Dimensione buffer parametri *)

[Roberto]

Ho realizzato il dump dell’area di memoria RETAIN da DB100.2048 per 2048 bytes, ora mi ritrovo il file nel file system di SlimLine nella cartella Storage. Ho scaricato il file usando un client FTP ed adesso posso editare il file sul mio PC con un comune text editor.

Ora il problema è quello di interpretare i dati scritti in questo file, come posso fare.

[Sergio Bertana]

Il blocco funzione di dump memoria esegue la copia del valore di ogni byte di memoria sul file, il valore è scritto in esadecimale usando due digit per ogni byte, vengono riportati 16 bytes per ogni riga del file. Nel file l’indirizzo parte sempre da 00000000 ma devi tenere presente che in realtà quell’indirizzo corrisponde all’offset a partire dal valore che tu hai definito in MBufferPtr. Nel tuo caso che esegui il dump di tutta l’area RETAIN a partire da DB100.2048 per 2048 bytes, avrai definito:

RMng.MBufferPtr:=ADR(%MX100.2048); (* Pointer buffer parametri *)
RMng.MBufferSize:=2048; (* Dimensione buffer parametri *)

Il file di dump ottenuto partirà da indirizzo 00000000 e all’ultima riga riporterà l’indirizzo 000007F0. Ecco un esempio di file (Sono state omesse tutte le righe tranne le prime due e l’ultima):

00000000: 01 78 E0 2E 00 00 C0 D4 | 01 00 00 00 48 41 00 00
00000010: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
………….
000007F0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00

Quindi l’indirizzo 00000000 corrisponde al byte di memoria %MX100.2048 ed ha valore 16#01, l’indirizzo seguente corrisponde al byte di memoria %MX100.2049 ed ha valore 16#78 e così via. L’indirizzo 000007F0 corrisponde al byte di memoria %MX100.4080 e l’ultimo indirizzo della riga corrisponde al byte di memoria %MX100.4095.

[Sergio Bertana]

Per quanto riguarda la comprensione dei valori riportati occorre fare mente locale con la posizione delle variabili nella memoria. Prendendo ad esempio una definizione come quella riportata nello screenshot, avremo le variabili:

BOOLVar, allocata ad indirizzo DB100.2048, con valore TRUE
USINTVar, allocata ad indirizzo DB100.2049, con valore 120 (16#78)
UINTVar, allocata ad indirizzo DB100.2050, con valore 12000 (16#2EE0)
UDINTVar, allocata ad indirizzo DB100.2054, con valore 120000 (16#1D4C0)
REALVar, allocata ad indirizzo DB100.2058, con valore 12,5 (16#41480000)

La prima cosa da notare è che la variabile UDINTVar è allocata ad indirizzo DB100.2054 (Vengono lasciati liberi due bytes DB100.2052 e DB100.2053) questo perchè le variabili a 16 bits vanno sempre allocate ad indirizzi divisibili per 2 e le variabili a 32 bits vanno sempre allocate ad indirizzi divisibili per 4. Il file dump è il seguente:

00000000: 01 78 E0 2E 00 00 C0 D4 | 01 00 00 00 48 41 00 00

Come si nota il primo valore è 16#01 e corrisponde alla variabile BOOLVar, poi segue il valore 16#78 che corrisponde alla variabile USINTVar, queste sono variabili ad un solo byte e quindi non vi è il problema della endianness dei dati.

Per le variabili a 16 e 32 bits occorre ricordare che SlimLine è basato su un ARM, e sfrutta una architettura Little-Endian, quindi il byte meno significativo si trova ad indirizzo più basso rispetto al byte più significativo. La variabile UINTVar viene riportata con i valori 16#E0 e 16#2E. La variabile UDINTVar viene riportata con i valori 16#C0, 16#D4, 16#01, 16#00.

Per la variabile REALVar il discorso è ancora più complesso, le variabili REAL utilizzano 4 bytes (32 bits) il valore è espresso nel formato IEEE 754-1985 (1 bit di segno, 8 bits di esponente, 23 bits di mantissa) (Vedi post). Il valore 12,5 è rappresentato in esadecimale con 16#41480000 che nel file di dump viene riportato con i valori 16#00, 16#00, 16#48, 16#41.

[Fabio]

Seguendo quanto detto sopra più in alto:

La prima cosa da notare è che la variabile UDINTVar è allocata ad indirizzo DB100.2054 (Vengono lasciati liberi due bytes DB100.2052 e DB100.2053) questo perchè le variabili a 16 bits vanno sempre allocate ad indirizzi divisibili per 2 e le variabili a 32 bits vanno sempre allocate ad indirizzi divisibili per 4.

Mi risulta che anche 2052 sia divisibile per 4, per cui non capisco perchè se vado a riempire solo 2 bytes con la  UINTvar devo sprecare altri due saltandoli per poter metterci quella a 32.

[Autore]

Post