CPU1500 Tipi Dati "buco tra due var "

[fiorezzz]

Salve a tutti 

Utilizzando i TipiDati se vado a definire una variabile di tipo  byte  alla quale viene assegnato un indirizzo "pari" e successivamente creo una variabile word quest'ultima parte sempre da una locazione di indirizzo "pari"  lasciando tra le due var.un "buco" (ve ne accorgete quando all'interno della DB si va ad inserire il TipoDati 

Ora la faccenda è piuttosto fastidiosa quando utilizzo questo TipoDato per interfacciarmi vs.protocolli "terzi" per cui tra una var.byte e una var.word non ci sono spazi 

Non so se mi sono spiegato (Allego foto ) 

Sapete se c'è qualche trucco utilizzando sempre TipoDati per cui anche il TIA   non lasci "spazi" 

 

[pigroplc]

metti la DB ottimizzata, il che potrebbe darti noia se gli stessi tag li leggi da pannelli che funzionano con le DB non ottimizzate.

[fiorezzz]

C'è modo di "verificare" senza provare se con DB ottimizzata non ci sono "buchi" tra le due var ? 

Nel caso però che volessi utilizzare questo tipo dato direttamente nella tabella variabili associandolo a degli IO che logicamente non sono "fisici" ma rispecchiano 

un protocollo di  scambio dati con un altra periferica il problema si ripresenterebbe ( certo risolvibile caricando in una DB Ottimizzata tramite la DPR_DAT gli Input  da gestire)  

[batta]

38 minuti fa, fiorezzz ha scritto:

C'è modo di "verificare" senza provare se con DB ottimizzata non ci sono "buchi" tra le due var ? 

In un DB ottimizzato la memoria viene gestita dal sistema in modo, appunto, "ottimizzato". Le variabili non hanno un indirizzo fisico ( o ce l'hanno ma non è noto).
Se alle variabili devono accedere sistemi che puntano all'indirizzo della variabile, non puoi usare dati ottimizzati.
Con le variabili non ottimizzate, il fatto di iniziare dagli indirizzi pari non è una novità. Semplicemente, si deve tenerne conto quando si definiscono le variabili.
Dopo un byte, metti un byte spare se desideri rendere più evidente che non c'è il byte dispari libero.

Iniziare sempre dal byte pari è buona regola anche in sistemi che ti permettono di assegnare gli indirizzi a piacere. Anzi, qualcuno ti direbbe di partire da indirizzi multipli di 4 in caso di variabili della dimensione di 4 byte (DInt, Real, ecc.).

[fiorezzz]

8 minuti fa, batta ha scritto:

Quindi unica alternativa è  cambiare il protocollo di scambio dati lasciando ovviamente un byte di spazio tra le due variabili .Ad oggi funziona poichè mappando direttamente nella Tabellavariabili  senza usare TipoDato  non c'è questa necessità    

 

[batta]

7 ore fa, fiorezzz ha scritto:

Ad oggi funziona poichè mappando direttamente nella Tabellavariabili  senza usare TipoDato  non c'è questa necessità

A parte che non mi pare di aver scritto queste cose, ma sei proprio sicuro che, non usando il Tipo di Dati, ti lasci partire con una INT con indirizzo dispari?
A me non risulta.

[fiorezzz]

Intendevo questo scritto nella TabellaVariabili .Il  byte1371 e la word 1372 fanno parte di un "protocollo" di comunicazioni  con  una periferia esterna 

[Slayer90]

Buongiorno,

Volevi forse fare un move block dall'immagine degli ingressi a un DB? ovviamente se l'offset del db non è contiguo come gli ingressi qualcosa si sfalsa.

3 Soluzioni:

1 - fare il move di una variabile alla volta su un db ottimizzato o meno così non sbagli

2 - se usi una versione TIA >= V16 puoi dichiarare sulla Tabella delle variabili un tipo di dato uguale alla struttura degli ingressi da leggere: ad esempio "UDT mio dato" composto da 1 byte e 1 word. Dichiari Var1 come tipo di dato "UDT mio dato" che parte da E1371.0 e dovrebbe tornarti la stessa struttura.

3 - Leggi con la funzione DPRD_DAT

 

Saluti