Creazione UDT per DB istanza

[GenPocoto]

Salve a tutti,

Non ho trovato discussioni in merito al mio "problema"

Sto lavorando su un progetto in Tia portal v18 e man mano ceerco di semplicifarlo e "standardizzarlo" per quello che si può. Detto ciò mi sono fatto una domanda.... Quando si crea un FB, viene generata la sua DB di istanza in automatico, e fin qua... E qui ho ragionato e la prima domanda che mi è sorta, visto che questo FB da me creato lo uso più volte, si può creare una DB "generale" che mi contenga tutte le istanze di questi FB?

E se si, posso creare direttamente un UDT con contenenti queste istanze? cosi poi da potermi direttamente portare in giro questa DB e eventualmente usare l UDT creato come ingresso a un ulteriore FB

 

Vi ringrazio

[dina_supertramp]

Ciao, io ero solito lavorare cosi:

 

Es.
FB "Pompa" (per gestire una pompa)
DB "Pompa0" (DB d'istanza dell'FB Pompa, che gestisce la pompa 1)
DB "Pompa1" (DB d'istanza dell'FB Pompa, che gestisce la pompa 2)
DB "Pompe" (dove all'interno ho tutti i DB d'istanza da modo di controllare tutte le pompe a colpo d'occhio)

Non fare confusione, gli UDT sono tipi di dati definiti dall'utente per la gestione del programma, non sono variabili caricate nel PLC

Provo a spiegarmi:

Tu puoi definire un UDT chiamato: UDT "InputByte0ModuloInput" composto da 8 bit, dove ogni bit si chiamerà: Ingresso0, Ingresso1, .... Ingresso7
Ora mettiamo che crei un FB per la gestione del tuo modulo di input

FB "ModuloInput"
VAR IN: BYTE UDT "InputByte0ModuloInput" (lo accetterà perchè l'udt è formato da 8 bit, cioè un byte)

L'alternativa sarebbe stata 
FB "ModuloInput"
VAR IN: BOOL "Input0"
              BOOL "Input1"
              .....
              BOOL "Input7"

Modificato: 16 novembre 2023 da dina_supertramp

[dina_supertramp]

User Defined Data Types (UDT) - Purpose, Need, Tutorial (instrumentationtools.com)

[GenPocoto]

Temo di aver frainteso la tua risposta o tu la mia domanda.

Vado a spiegare meglio la mia questione

Io Uso 10 FB "step" e si creano le 10 DB d istanza, con "Input/Output/InOut e ecc..ecc.." inerenti a questi 10 FB che ho usato...

La mia domanda è:

Si può creare una DB unica che contenga queste 10 istanze? esempio:

DB General

- Step 1 con al suo interno "Input/Output/InOut e ecc..ecc..e appoggiarlo al FB Step1

- Step 2 con al suo interno "Input/Output/InOut e ecc..ecc..e appoggiarlo al FB Step2

e cosi via

Meglio ancora, se io creo un tipo di dati che contenga la struttura cuatat qua sopra per i miei 10 FB, riesco ad agganciare direttamenta la DB general a un eventuale FB "Control Step" con InOut il tipo di dati da me creato, cosi da agganciarmi direttamente la DB general e avere all'interno di FB Control step tutti gli step in un passo solo

 

[Mattia Spoldi]

la cosa bella secondo me, sarebbe dichiarare tutti gli fb step in multiistanza del blocco dove poi vai ad usarli effettivamente,

 

altrimenti puoi fare una cosa così,

dichiari un fb di appoggio, es FB Generali,

tra le statiche dichiari tutte le N istanze di step,

istanzi generali da qualche parte

nel blocco dove usi il tuo blocco Step, punti all'istanza di step contenuta nel db di istanza di generali

 

 

Modificato: 16 novembre 2023 da Mattia Spoldi

[dina_supertramp]

2 ore fa, GenPocoto ha scritto:

Temo di aver frainteso la tua risposta o tu la mia domanda.

 

Mi sono espresso male, dove dico DB all'interno di un altro DB, intendevo fare quello che ti ha scritto @Mattia Spoldi.
Creare un FB "Funzione" e richiamarlo n-volte come multi-istanza nell FB "GestioneFunzioni", di modo da avere tutto annidato nel DB d'istanza dell'FB "GestioneFunzioni".

 

[GenPocoto]

1 ora fa, Mattia Spoldi ha scritto:

la cosa bella secondo me, sarebbe dichiarare tutti gli fb step in multiistanza del blocco dove poi vai ad usarli effettivamente,

 

altrimenti puoi fare una cosa così,

dichiari un fb di appoggio, es FB Generali,

tra le statiche dichiari tutte le N istanze di step,

istanzi generali da qualche parte

nel blocco dove usi il tuo blocco Step, punti all'istanza di step contenuta nel db di istanza di generali

 

 

Si è una soluzione a cui ho pensato.

Ma il mio intendo è poi utilizzare alcuni bit di queste istanze in giro per il prigramma, sensa doverle una ad una appoggiarle a un ulterione DB creata solo per quello.

Allego la mia situazione, se vi fa capire meglio

[dina_supertramp]

28 minuti fa, GenPocoto ha scritto:

Ma il mio intendo è poi utilizzare alcuni bit di queste istanze in giro per il prigramma, sensa doverle una ad una appoggiarle a un ulterione DB creata solo per quello.

Devi appoggiarli, altrimenti faresti una cosa senza senso secondo me.

Creare FB ed usare al loro interno variabili globali, è permesso, ma non "bello" diciamo.

Gli FB nascono con lo scopo di isolare ed essere richiamati n-volte, vedere un FB che accede direttamente a variabili globali mi fa venire una fitta al fegato.

Creare un FB ed usare una sua variabile (Static/Temp) direttamente all'esterno non so se sia permesso (non l'ho mai fatto sinceramente 🤨).
Per tirare fuori qualcosa da un FB ho sempre creato una variabile nei parametri Out dell'FB, scritta all'interno dell'FB, e ci ho sempre appoggiato qualcosa di esterno scritto esclusivamente dall'FB a cui l'ho appoggiato.

Modificato: 16 novembre 2023 da dina_supertramp

[GenPocoto]

17 minuti fa, dina_supertramp ha scritto:

Devi appoggiarli, altrimenti faresti una cosa senza senso secondo me.

Creare FB ed usare al loro interno variabili globali, è permesso, ma non "bello" diciamo.

Gli FB nascono con lo scopo di isolare ed essere richiamati n-volte, vedere un FB che accede direttamente a variabili globali mi fa venire una fitta al fegato.

Creare un FB ed usare una sua variabile (Static/Temp) direttamente all'esterno non so se sia permesso (non l'ho mai fatto sinceramente 🤨).
Per tirare fuori qualcosa da un FB ho sempre creato una variabile nei parametri Out dell'FB, scritta all'interno dell'FB, e ci ho sempre appoggiato qualcosa di esterno scritto esclusivamente dall'FB a cui l'ho appoggiato.

Immagino che esportando anche le statiche e le temporanee le si possa modificare al difuori del FB.

Ma non è questa la mia intenzione, A me interessa capire, se nel mio FB Start Cycle, dove all interno di esso, interrogo tutti i vari step, e si può riesco a leggere i risultati calcolati all'interno dell FB start Cycle, presenti nelle DB di istanza del vari FB step, senza dover appunto creare un Out per ogni FB step e vari casi

[dina_supertramp]

21 minuti fa, GenPocoto ha scritto:

Immagino che esportando anche le statiche e le temporanee le si possa modificare al difuori del FB.

Ma non è questa la mia intenzione, A me interessa capire, se nel mio FB Start Cycle, dove all interno di esso, interrogo tutti i vari step, e si può riesco a leggere i risultati calcolati all'interno dell FB start Cycle, presenti nelle DB di istanza del vari FB step, senza dover appunto creare un Out per ogni FB step e vari casi

Vuoi interrogare direttamente ad es. la variabile "Stato_Step_Succ" nell'FB "StartCycle" senza dovergli appoggiare nulla all' FB "Fb_Steps" richiamato nell'FB "StartCycle".
 

Ho capito giusto?

[drn5]

2 ore fa, GenPocoto ha scritto:

alcuni bit di queste istanze in giro per il prigramma, sensa doverle un

Parete personalissimo....così ritorni indietro ai millemila Meeker di 20anni fa.Gli fb nascono per essere isolati, mondi divisi che interagiscono grazie ai parametri in I/O sulle chiamate. Se il codice è scritto in modo per lo meno ragionevole non servono questi artefici. Non c'è nemmeno più la necessità di risparmiare 4 bytes o 1msec di ciclo, almeno con le CPU odierne. Io da sempre uso il sistema di @Mattia Spoldi e non ho mai avuto problemi di "trasportabilità". È un sistema pulito, chiaro e ben documentabile...

[dina_supertramp]

26 minuti fa, drn5 ha scritto:

Parete personalissimo....così ritorni indietro ai millemila Meeker di 20anni fa.Gli fb nascono per essere isolati, mondi divisi che interagiscono grazie ai parametri in I/O sulle chiamate. Se il codice è scritto in modo per lo meno ragionevole non servono questi artefici. Non c'è nemmeno più la necessità di risparmiare 4 bytes o 1msec di ciclo, almeno con le CPU odierne. Io da sempre uso il sistema di @Mattia Spoldi e non ho mai avuto problemi di "trasportabilità". È un sistema pulito, chiaro e ben documentabile...

Condivido.

@GenPocoto la risposta diretta alla tua domanda è si.
Farlo non è che sia sbagliato, ma è come se stessi usando uno strumento (l'FB) sviluppato per isolare, atomizzare, e gestire funzioni ripetute in modo efficente, nel modo improprio.

Il cruccio è proprio li, quando fai programmi grossi, e per grossi intendo programmi che supervisionano intere linee di produzione, oppure impianti complessi, devi per forza isolare (devi essere sicuro che solo quello che vuoi tu scriva una variabile, e non altri fattori esterni, anche in caso di errore di programmazione) e atomizzare (alla fine ti devi trovare a debuggare poche righe di codice per volta o pochi rami di contatti, non puoi trovarti a debuggare 5-600 righe tutte insieme sennò te ne vai ai matti).

Io ho applicato la filosofia del PackML a quasi tutte le macchine (pochissime di esse erano macchine di packaging) che ho fatto, e devo dire che gli FB e la programmazione ad oggetti si sposano perfettamente con questo standard.

Modificato: 16 novembre 2023 da dina_supertramp