Lettura e scrittura dati tra DB

[davidearca02]

Buongiorno a tutti,

 

mi è stato dato il compito di leggere i valori delle variabili di una DB di un motore, gestito con "FB Motor G120c". 

Il mio obiettivo è di leggere e scrivere le variabili di queste "DB M**" (avremo 4 motori, ma volevamo creare qualcosa che sia compatibile anche con "n" motori), passarle in una "DB_HMI", che quest'ultima farà vedere i valori di queste variabili in un pannello operatore.

Inizialmente il mio collega mi ha detto che pensava di fare questo passaggio di dati creando una FC e utilizzando i "DB_ANY", quello che però volevo capire, era come passare tutta la struttura "parameters" e "Par", senza andare a riscrivere variabile per variabile. Da queste due DB dovrò poi essere abile a leggere e scrivere le variabili.

 

Se non sono stato chiaro fatemi pure domande. 

 

Grazie mille a tutti per l'aiuto!

[drn5]

Forse ho capito male io ... ma non basta questo ?

 

DB_HMI.Parameters := M41.Par;

 

anche se vedo che il DB M41 ha il Par non definito dallo stesso UDT del DB_HMi..... cosa che sarebbe giusto fare.

[dina_supertramp]

KOP, istruzione MOVE.
Drag&drop di tutta la struttura da leggere sull'ingresso del move, drag&drop di tutta la struttura da scrivere in uscita al move.

 

SCL

"DB_HMI".Paramteters := "DB_M41".Par;

 

Inutile dire che per fare quanto sopra le due struttura devono avere gli stessi dati e la stessa lunghezza, insomma, devono essere uguali.

 

AWL
Si usano i puntatori: Carica, punta, trasferisci 😅

 

Modificato: 29 agosto da dina_supertramp

[dina_supertramp]

11 minuti fa, drn5 ha scritto:

anche se vedo che il DB M41 ha il Par non definito dallo stesso UDT del DB_HMi..... cosa che sarebbe giusto fare.

Usa l'UDT anche nell'FB che gestisce i motori....resta tutto più allineato...

Inoltre se aggiorni l'UDT perchè togli o aggiungi dati, ti viene aggiornato in automatico in tutti i punti del programma in cui è usato, la struct no.

Modificato: 29 agosto da dina_supertramp

[ifachsoftware]

3 ore fa, dina_supertramp ha scritto:

Usa l'UDT anche nell'FB che gestisce i motori....resta tutto più allineato...

Inoltre se aggiorni l'UDT perchè togli o aggiungi dati, ti viene aggiornato in automatico in tutti i punti del programma in cui è usato, la struct no.

Confermo , utilizza il tuo UDT che deve essere il piu' generico possibile e lo utilizzi nella tua db e nell'FB

[davidearca02]

 

23 ore fa, drn5 ha scritto:

Forse ho capito male io ... ma non basta questo ?

 

DB_HMI.Parameters := M41.Par;

 

anche se vedo che il DB M41 ha il Par non definito dallo stesso UDT del DB_HMi..... cosa che sarebbe giusto fare.

 

22 ore fa, dina_supertramp ha scritto:

Usa l'UDT anche nell'FB che gestisce i motori....resta tutto più allineato...

Inoltre se aggiorni l'UDT perchè togli o aggiungi dati, ti viene aggiornato in automatico in tutti i punti del programma in cui è usato, la struct no.

 

18 ore fa, ifachsoftware ha scritto:

Confermo , utilizza il tuo UDT che deve essere il piu' generico possibile e lo utilizzi nella tua db e nell'FB

Buongiorno,

 

grazie mille per le risposte!

Allora, l'FB dei motori non posso cambiarla purtroppo, è stata fatta da un mio collega e guai a toccarla...

Facendo un semplice "Move" dei parametri, ovviamente tutto funziona come deve, però mi è stato detto che diventa complicato quando abbiamo diversi motori e bisognerà poi riscriverli uno ad uno, quindi si era pensato di utilizzare, per esempio, l'istruzione DB_ANY_TO_VARIANT, ma abbiamo visto che con le DB d'istanza legge il numero della DB ma ci da un errore.

Soprattutto perchè doveva diventare una cosa abbastanza strutturata, con anche la creazione di ricette spostando i parametri in un'altra DB a ritenzione.

 

Spero di essermi spiegato bene, grazie mille a tutti!

Modificato: 30 agosto da davidearca02

[drn5]

Quando si fanno le cose a metà oppure si evolvono, bisogna avere il "coraggio" di sistemare le cose e non di rattopparle.

[dina_supertramp]

40 minuti fa, davidearca02 ha scritto:

Allora, l'FB dei motori non posso cambiarla purtroppo, è stata fatta da un mio collega e guai a toccarla...

...neanche avesse scritto l'FB per controllare un motore a reazione...chissà mai quale codice intoccabile ci sarà scritto dentro...🤣

 

40 minuti fa, davidearca02 ha scritto:

Soprattutto perchè doveva diventare una cosa abbastanza strutturata, con anche la creazione di ricette spostando i parametri in un'altra DB a ritenzione.

Appunto per questo consigliamo di usare gli UDT, tutto resta strutturato e allineato!

Modificato: 30 agosto da dina_supertramp

[davidearca02]

6 ore fa, drn5 ha scritto:

Quando si fanno le cose a metà oppure si evolvono, bisogna avere il "coraggio" di sistemare le cose e non di rattopparle.

 

6 ore fa, dina_supertramp ha scritto:

...neanche avesse scritto l'FB per controllare un motore a reazione...chissà mai quale codice intoccabile ci sarà scritto dentro...🤣

 

Appunto per questo consigliamo di usare gli UDT, tutto resta strutturato e allineato!

 

 

Questo era quello che voleva fare il mio collega con i due DB...

[ifachsoftware]

Il 29/08/2024 alle 09:56 , drn5 ha scritto:

Forse ho capito male io ... ma non basta questo ?

 

DB_HMI.Parameters := M41.Par;

 

anche se vedo che il DB M41 ha il Par non definito dallo stesso UDT del DB_HMi..... cosa che sarebbe giusto fare.

Questo funziona se le due db hanno nella stessa sequenza gli stessi tipi di dati  (anche se è una porcata).

La cosa giusta è farlo con gli stessi identici UDT

Il lavorare ancora nel 2024 con gli indirizzi delle DB per non voler sistemare gli UDT come Dio Comanda lo ritengo a dir poco assurdo (oppure è semplice ignoranza legata all'abbiamo fatto sempre fatto così e funziona)....

Personalmente metto sempre al primo posto la leggibilità del codice , ma per farlo capisco che bisogna studiare e sapere come lavorano i mezzi a disposizione e non pensare di tener buono quello che funzionava con gli S5

 

[drn5]

7 ore fa, ifachsoftware ha scritto:

Questo funziona se le due db hanno nella stessa sequenza gli stessi tipi di dati  (anche se è una porcata).

La cosa giusta è farlo con gli stessi identici UDT

Il lavorare ancora nel 2024 con gli indirizzi delle DB per non voler sistemare gli UDT come Dio Comanda lo ritengo a dir poco assurdo (oppure è semplice ignoranza legata all'abbiamo fatto sempre fatto così e funziona)....

Personalmente metto sempre al primo posto la leggibilità del codice , ma per farlo capisco che bisogna studiare e sapere come lavorano i mezzi a disposizione e non pensare di tener buono quello che funzionava con gli S5

 

??

 

 

Modificato: 31 agosto da drn5

[ifachsoftware]

DB_HMI.Parameters := M41.Par;  funziona ANCHE se hai due UDT che si chiamano in modi diversi , a patto che abbiano gli stessi tipi di campi nello stesso ordine .

La cosa CORRETTA sarebbe di assegnare due UDT che si chiamino anche nello stesso modo

 

[drn5]

19 ore fa, ifachsoftware ha scritto:

funziona ANCHE se hai due UDT che si chiamano in modi diversi , a patto che abbiano gli stessi tipi di campi nello stesso ordine .

giusto. Quello che conta è la struttura identica. che siano  UDT o no.

19 ore fa, ifachsoftware ha scritto:

La cosa CORRETTA sarebbe di assegnare due UDT che si chiamino anche nello stesso modo

non necessariamente, ma da un punto di vista di chiarezza e riusabilità si.

 

che poi è quello che dicevo..

Il 29/08/2024 alle 09:56 , drn5 ha scritto:

cosa che sarebbe giusto fare

 

[ifachsoftware]

Il fatto che il compilatore Siemens non consideri il nome dei due UDT diversi lo considero un baco