Indirizzi nelle Tabelle dei TipiDatiPLC (Ex UDT)

[fiorezzz]

Salve a Tutti 

Esiste qualche "magia" per poter visualizzare (come nelle UDT Step7) nelle tabelle dei TipiDatiPLC l'indirizzamento o offset delle singole variabili che si vanno a inserire 
(a volte sarebbe comodo soprattutto quando si devono creare strutture dati di dimensioni certe e posizioni variabili certe per scambio dati con altri dispositivi)   

Ad oggi io lo scrivo manualmente nel commento !!!!  ma quando si hanno 10/20/30 segnali la cosa non è molto agevole e si presta ad errori 

[acquaman]

Gli offset li trovi sono nelle DB non ottimizzate, gli udt li puoi usare sia nelle DB non ottimizzate che con quelle ottimizzate, quindi non hanno la colonna degli offset.

[Simone.Salarsi]

mi sembra che sia lo stesso argomento che avevi proposto tempo fa ed a cui avevi ricevuto esaurienti risposte

 

 

[fiorezzz]

Si questo lo avevo capito 

A volte sarebbe + comodo avere subito nell'UDT o TipoDato un riscontro sui byte occupati dall'UDT e sulla corrispondenza Variabile indirizzo assoluto in UDT 

(Almeno io la vedo cosi in alcuni casi mi sarebbe + comodo ; se poi il TipoDato finisce insieme ad altri TipiDati in una DB mi perdo il riferimento assoluto della variabile nella UDT ..spero di essermi spiegato)  )  

[batta]

2 ore fa, fiorezzz ha scritto:

A volte sarebbe + comodo avere subito nell'UDT o TipoDato un riscontro sui byte occupati dall'UDT e sulla corrispondenza Variabile indirizzo assoluto in UDT

Secondo me, sarebbe più utile abituarsi ad abbandonare gli indirizzi assoluti.

[drn5]

Quando poi usi il tipo dati dentro un db non ottimizzato vedi in chiaro gli offset dei singoli elementi.  Però rimanere attaccato agli indirizzi assoluti ti frena a crescere. Con scl ed i vettori indicizzabili, gli indirizzi assoluti non hanno più senso. Neanche in termini di memoria o di velocità di esecuzione del codice.... Poi ognuno, giustamente, fa quello che vuole.

[batta]

18 ore fa, Yiogo ha scritto:

secondo me bisogna mettere in primo piano la definizione simbolica e vedere gli indirizzi assoluti come un aspetto secondario che serve a

Personalmente utilizzo l'indirizzamento assoluto solo ed esclusivamente quando sono obbligato a farlo, quando proprio non se ne può fare a meno.
Per esempio, se devo scambiare dati con sistemi che richiedono l'indirizzamento assoluto.

Per tutto il resto, oramai da parecchi anni non scrivo più una sola riga di codice che faccia riferimento ad un indirizzo assoluto.
Intendiamoci, non è che gli indirizzi assoluti siano un male da evitare a tutti i costi, ma sviluppare senza usare indirizzi assoluti offre parecchi vantaggi.
Io sono fondamentalmente un pigro, poi ho anche raggiunto una certa età, e non ho più voglia di fare fatiche che mi posso risparmiare.
Solo per organizzare i dati di un DB, con idirizzamento assoluto devi tenerti variabili di riserva, per evitare di dover spostare indirizzi in caso di aggiunta di variabili.
Poi va sempre a finire che, par quanto ti sembri di essere stato abbondante con le riserve, invece non ti bastano, e devi ricercare nel programma gli indirizzi da modificare.
A me, solo vedere qualla colonna con gli indirizzi, causa un certo fastidio.
Se parliamo di Siemens poi, l'accesso ai dati "non ottimizzati" è parecchio più lento (fino a 5-6 volte).

[batta]

Il 21/4/2023 alle 21:46 , Yiogo ha scritto:

gli integratori veri quelli che "anche se" hanno tre o quattro preferenze sono integratori veri

Io non la vedo così. Anzi, diffido di chi sostiene di essere in grado di programmare 4-5 (o più) plc diversi.
Un tempo era fattibile, quando le differenze tar un plc ed un altro si limitavano alla sintassi di alcune istruzioni e alla gestione della memoria.
Io, da anni, ho abbandonato tutto il resto, e già fatico quasi a stare al passo con un solo PLC. E di questo PLC mica conosco il 100%.
Poi, perché considerare "vero integratore" solo chi gestisce marche diverse? Come dire che una autofficina monomarca non è un'autofficina.
E, personalmente, non mi piacciono nemmeno i collage fatti con tante marche diverse.
Perché mai dovrei mettere un PLC di marca X, la periferia di marca Y, gli inverter di marca Z, i pannelli operatore di marca W, e via di seguito?
Per risparmiare una manciata di euro che spendo tre volte con il tempo che perdo per mettere insieme dispositivi di marche diverse, e lo scaricabarile dei vari fornitori in caso di problemi?
In quanto al ladder, non è mai stato il mio linguaggio preferito, ma per logica booleana non mi puoi dire che il debug in strutturato sia più semplice.
Una cosa che trovo molto utile di Siemens (e che, se non sbaglio, pochi altri hanno), è la possibilità di inserire segmenti in strutturato all'interno di un blocco in ladder, senza dover creare e richiamare una funzione, magari solo per fare un calcolo un po' complesso.
Se non ci fosse questa possibilità, userei molto meno il ladder ma, visto che si può fare, non rinuncio alla comodità di un misto di ladder e strutturato.

[Livio Orsini]

3 minuti fa, batta ha scritto:

Per risparmiare una manciata di euro che spendo tre volte con il tempo che perdo per mettere insieme dispositivi di marche diverse, e lo scaricabarile dei vari fornitori in caso di problemi?

 

Concordo in tutto e per tutto!

4 minuti fa, batta ha scritto:

In quanto al ladder, non è mai stato il mio linguaggio preferito, ma per logica booleana non mi puoi dire che il debug in strutturato sia più semplice.

 

Concordo anche in questo.

Anch'io ho sempre usato il ladder per le logiche booleane proprio perchè il controllo funzionale è immediato e facilissimo, oltre che velocissimo.

[batta]

15 ore fa, Yiogo ha scritto:

il debug con il ladder è "più velocissimo" se non conosci bene ST

Per quanto riguarda "l'integratore", ognuno ha le sue idee. Io so che farò un lavoro migliore se utilizzo prodotti che conosco bene. Se poi il cliente insiste per fare un collage eterogeneo, se accetto il lavoro comunque metto in chiaro che ci saranno maggiori difficoltà di sviluppo software e maggiori probabilità di riscontrare problemi.

Sul fatto che il debug in ladder sia più immediato del debug in ST solo per chi non conosce bene ST, non crederò mai che tu ne sia convinto veramente. Piuttosto, io direi l'esatto contrario: solo chi ha grossi problemi con il ladder preferisce (mi riferisco sempre a logica booleana) il debug in ST. Un segmento di logica booleana In Ladder non devi nemmeno ragionare, a colpo d'occhio vedi subito cosa non va.

Diverso se mi parli di calcoli o gestione dati in generale, che è assurdo il solo pensare di farla in ladder.