Db Di Tipo Passati A Fc

[a.rezzan]

Salve,

è possibile passare un DB di tipo UDT a una FC come parametro di ingresso?????

[walterword]

UDT sta per User Defined Type , o qualcosa del genere

Ti permette di definire dati composti , ma non rappresenta nessuna istanza reale di dati

Per cui devi creare un DB all'interno del quale specifichi uno o in parte o tutti i dati del tipo dell'UDT che hai definito

Nei blocchi FC ed FB puoi richiedere tipi di dati canche complessi per cui DB definiti

Se in un FC vuoi richiare un DB che ha una certa struttura definita da uno o piu UDT , devi all'interno del blocco FC dichiare la propria firma , cioè predisporre l'FC ad accettare il tipo di dati voluto

Prova ad abbassare la tendina superiore che c'e in un blocco FC e giocaci un po sopra .Vai nel tabpage In e dai un nome alla variabile input poi ti sposti a lato e clicchi su tipo di dato e vedrai una lista di tipo di dati tra cui DBnr, UDTnr ect .

Se l'udt lo ha gia dichiarato dovresti vederlo o al limite gli dai tu il nome o il numero assegnato nella tendina

Nei linguaggi di programmazione tipo il C , l'udt equivale al typedef e il DB equivale ad una struct che puo essere piu o meno complessa e contenere campi definiti nella typedef cioe nell'udt

ciao

Walter

[Gianluca5Landi]

Ciao, non puoi farlo direttamente... però puoi fare cosi:

1 - crei UDT e strutturi il DB con il/i richiami all'UDT(nnn)

2- nel FC crei nella parte TEMP una variabile che come tipo avrà UDT(nnn) e poi la elabori..

[a.rezzan]

Mi sa che sono stato un po' troppo sintetico e voi bravi a capirmi, cercherò di fare un esempio concreto.

Creo un UDT chiamiamolo UDT_Prova con due variabili A e B di tipo BOOL.

Creo un DB di tipo UDT_Prova, chiamiamolo DB_Prova (Se apro il DB vedo in grigetto le due variabili A e .

Creo una FC, chimiamola FC_Prova.

Dichiaro una variabile IN_OUT di nome MIA_VAR di tipo UDT_Prova.

Salvo il tutto.

Vado in OB1 porto dentro FC_Prova, mi dice che gli serve il parametro di IN_OUT, gli metto come parametro DB_Prova e una volta inserito tale nome assume il colore rosso, ossia non gli va bene!

Come faccio, sempre se si può fare, a inserire il DB direttamente come parametro?

N.B.

Di solito dichiaro un DB che ha una variabile di nome ex. MIA_VAR di tipo UDT e quindi il gioco funziona, ma visto che si può dichiarare un "DB di tipo" mi sono messo a fare delle prove per capire come lo posso utilizzare, e nello specifico volevo tentare di inserirlo come parametro di ingresso ad una FC.

[Gianmario Pedrani]

se vuoi passare una db ad un fc devi creare usare una variabile di tipo any, nell'help di step 7 ti scipega come è definito una parametro any, se no puoi usare un altra soluzione.

crei una variabile di tipo db dentro nel tuo fc e come inizio della tua operazione usi il comando auf numero della db da aprire, poi nel resto del programma

usi dbw o dbd o dbx .

[a.rezzan]

Utilizzando il kop?

[Gianmario Pedrani]

Esiste il comando open in kop se guardi sulla sinistra dove trovi tutti i comandi che puoi usare

db1

-----------(opn)

oppure al posto di db1 metti la variabile che hai creato nell'interfaccia del blocco ed è definita come Block_DB

ciao

[a.rezzan]

Usare OPN dentro una FB, nel contesto indicato prima, non è che mi sembra corretto.

Questa funzione limita la FB, se la utilizzo dovrei creare tante FB (uguali) quante ad esempio sono i motori da comandare, dovrei essere ingrado di indicizzate il DB, ma non mi sembra sia possibile.

Tra l'altro vedo che una volta utilizzata la OPN le variabili le utilizzo scrivendo ad esempio DBX0.0 che non mi da le stesse informazioni di ad esempio Motore.Start

A me sembra che un DB di tipo abbia poco senso....

Poi ... una cosa che ho notato è la differenza sostanziale della memoria di lavoro utilizzata tra una FC e FB che facciano le stesse cose, la FC risulta molto più pesante (FC -> 6522 e FB ->1162), sai il perchè?

[dan64100]

Credo di aver capito cosa vuoi fare.

Innanzitutto non puoi passare a una FC direttamente la DB creata come DB di tipo però puoi fare qualcosa di molto simile per avere il vantaggio di lavorare con i riferimenti simbolici nella funzione.

Crea un UDT (ad es. UDT1000 "motore") con al suo interno tutti i campi che vuoi.

Dopo crea DB1000 (motore_1) come DB globale e non come DB di tipo, una DB "normale" per intenderci.

All'interno di DB1000 inserisci un'unica variabile DATA (o la chiami come vuoi) di tipo UDT1000.

Allo stesso modo puoi creare altre DB (motore_2, motore_3) sempre con solo DATA di tipo UDT1000 al loro interno.

Nella tua FC (supponiamo FC1000) inserisci un parametro di in_out (ad esempio inst_mot) di tipo UDT1000.

Ora puoi richiamare la tua FC da OB1 quante volte vuoi passandogli come parametro "motore_1".DATA oppure "motore_2".DATA ecc...

All'interno di FC1000 lavorerai sempre con #inst_mot.campo_1, #inst_mot.campo_2 ecc..

In questo modo hai creato una FB "simulata" cioè una funzione con memoria persistente.

Lo svantaggio principale è che non hai la possibilità di usare la multi-instanza.

Il vantaggio (motivo per cui anch'io uso spesso questa tecnica) è che in una DB puoi aver molte variabili di tipo UDT anche diverse fra loro.

Io uso una FC cilindro per gestire i cilindri pneumatici (movimenti, timeout ecc..) con 200 cilindri dovrei avere 200 DB di istanza, con questo metodo ho un'unica DB "cilindri" con 200 variabili al suo interno.

Ciao

[a.rezzan]

Anch'io faccio così, ma è sempre una tecnica che ha limitazioni nel caso utilizzi le varibili che costituiscono l'UDT nel OB1 e successivamenti modifichi l'UDT.

Dico questo perchè se ad esempio hai creato degli UDT diversi tra loro o uno solo e poi crei un DB contenente più di una variabile di tipo UDT come fai tu( e come faccio io tra l'altro) e poi se dovessi aver bisogno di modificare la struttura dell'UDT aggiungendo altri campi, nel progetto in OB1 troveresti i riferimenti "sfasati" e quindi è per questo che dico che è limitato.

Tu potresti dire che in questa situazione sarebbe utili dichiarare delle variabili diciamo "libere" da poter utilizzare in futuro, beh... dico ... sì, vero, ma è sempre un compromesso, che potrebbe comunque non andare bene, sarebbe una bella cosa che S7 riorganizzasse il programma dopo cambiamenti nell'UDT senza "incasinare tutto".

Tu potresti dire che nel caso L'UDT non bastasse più si potrebbe crearne un altro come ampliamento di questo, vero, in questo modo non sono limitato al numero di dichiarazioni di variabili al suo interno, magari ci si perde in leggibilità. Una cosa più semplice no?

E' per questo che sto cercando un modo, sempre se c'è, di rendere la cosa fattibile e semplice, senza dover inventarmi tecniche ...

Potrei dichiarare un DB con un solo UDT, quindi per n motori ho un UDT e n DB, ha senso? Sicuramente è da preferire a un DB con n UDT al suo interno, almeno se modifichi l'UDT non ti si incasina il programma.

Si accettano consigli, grazie.

[dan64100]

Una DB con un solo UDT è esattamente quello che ti ho consigliato

E' quello che più si avvicina alla FB con DB d'istanza. Io uso questa tecnica per evitare la "proliferazione" delle DB e in presenza di strutture extra-standard, altrimenti uso direttamente FB.

In ogni caso l'indirizzamento simbolico di Step 7 è solo un "alias", alla fine stai sempre lavorando con indirizzi assoluti, per cui in caso di modifiche UDT/DB d'istanza/interfaccia delle funzioni scoppia tutto quanto è concatenato, a meno di non lavorare sempre (cosa scomodissima) con la conversione/ricompilazione dei sorgenti awl.

Ho paura che più di tanto (ma magari mi sbaglio) non si possa fare

[a.rezzan]

Anche per me mi sa che stiamo "raschiando il barile", grazie dan64100 per aver seguito questa discussione e anche Pedrani, se vi viene in mente altro ben venga.

Ciao e grazie ancora.