Jump to content
PLC Forum


Lettura e scrittura dati tra DB


davidearca02
 Share

Recommended Posts

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!

image.thumb.png.98ee389004c751606638699834e8af41.png

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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 😅

 

Edited by dina_supertramp
Link to comment
Share on other sites

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.

Edited by dina_supertramp
Link to comment
Share on other sites

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

Link to comment
Share on other sites

davidearca02
Posted (edited)

 

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!

Edited by davidearca02
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Edited by dina_supertramp
Link to comment
Share on other sites

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!

image.png.6c8df3de823fab58fd3ed63d99d539ef.png 

 

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

 

??

 

 

Edited by drn5
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

ifachsoftware

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...