Assegnazione parametri con FC annidate (AWL)

[Cafard]

Buongiorno,

 vorrei capire perchè non posso eseguire la seguente operazione:

 

Ho un DB costituito da elementi dello stesso tipo (DB5 con elementi UDT5).

Creo una funzione FC1 nella quale dichiaro come IN_OUT un tipo di dato UDT5  (lo chiamo pippo). Quando richiamo FC1 posso assegnare all' IN_OUT "DB5".elemento1 , ovvero:

 

CALL FC1

pippo:="DB5".elemento1

 

All'interno di FC1 richiamo FC2 che ha come  IN_OUT un tipo di dato UDT5  (lo chiamo pluto).  Quando richiamo FC2 non posso assegnare pippo a pluto 

Io vorrei fare così:

CALL FC2

pluto:= pippo      //pippo non viene accettato "assegnazione di parametri non ammessa per pluto"

 

Se per FC1 dichiaro una  TEMP di tipo UDT5 (la chiamo pippo_temp)  posso fare

 

CALL FC2

pluto:=pippo_temp

 

Posso anche fare:

 

CALL FC2

pluto:="DB5".elemento1  //così però non mi serve

 

Potrei anche adottare la soluzione "pippo_temp", ma in FC1 dovrei copiare tutti i dati singolarmente da "pippo" a "pippo_temp", richiamare FC2 e poi trasferire i dati da "pippo_temp" a "pippo" (non posso usare SFC20 perchè "pippo" non viene accettato nè come SRCBLK prima del richiamo di FC2 nè come DSTBLK dopo il richiamo di FC2 -"pippo_temp", invece, va bene ).

Potrei eseguire le operazioni che effettua FC2  direttamente in FC1 cos' da non doverlo richiamare, ma vorrei evitarlo perchè FC2 è una funzione piuttosto elaborata scritta in SCL mentre tutto il resto è in AWL. 

 

Perchè all' IN_OUT di tipo UDT5 di FC2 non posso assegnare l' IN_OUT di tipo UDT5 di FC1? 

Perchè non posso usare SFC20 per trasferire i dati da pippo a pippo_temp  e viceversa? (SRCBLK e DSTBLK non accettano parametri dichiarati come IN_OUT) . 

 

Qualcuno può aiutarmi?

 

Grazie.

 

[acquaman]

Step7 classic o TIA?

[Cafard]

Step7 classico.

[acquaman]

Non é permesso, il modo più semplice secondo me è copiare il contenuto del segmento di FC2 in FC1 e creare un terzo FC che li contiene tutti e 2.

[Cafard]

Grazie per avermi risposto.

 

Dici di riportare le istruzioni di FC2 in FC1? 

Il problema è che FC1 è in AWL mentre FC2 è in SCL ed è abbastanza complesso. 

Piuttosto trasferisco i dati da "pippo" a "pippo_temp" e viceversa, ma anche qui c'è il problema che non posso usare SFC20 per pippo e dovrei quindi assegnare singolarmente ciascun elemento di pippo a pippo_temp.

Ho provato anche a scrivere una funzione che trasferisca dati di tipo UDT5 da una sorgente a una destinazione (praticamente un SFC20 ma con srcblk e dstblk dichiarati come in_out di tipo UDT5), ma anche in questo caso non accetta "pippo". 

 

Quindi mi chiedo:  una FC richiamata all'interno di un' altra FC accetta solo le variabili TEMP della FC chiamante come parametri?  

 

 

 

  

 

 

 

 

 

 

[batta]

La differenza non è tanto tra Simatic Manager (Step7 classico) o TIA, ma è nella CPU. Con il 300 non si può fare (nemmeno nel TIA), con il 1200/1500, sì.

Temo che il modo più semplice per fare ciò che desideri sia lavorare con i puntatori.

 

Però, la domanda che mi sorge spontanea è: perché, nel 2020, stiamo ancora lavorando con Simatic Manager e CPU S7300?
Spero si tratti di una modifica ad un impianto esistente, perché se è un nuovo lavoro, significa aver scelto di complicarsi inutilmente la vita.

Modificato: 11 marzo 2020 da batta

[Cafard]

Buongiorno batta,

non mi è chiaro in che modo suggerisci di usare i puntatori..  intendi dire per copiare i dati da "pippo" a "pippo_temp"? 

 

scusa, ma ho pochissima esperienza.

 

(CPU S7300 per impianto nuovo)

 

Grazie.

 

[batta]

1 ora fa, Cafard ha scritto:

non mi è chiaro in che modo suggerisci di usare i puntatori..  intendi dire per copiare i dati da "pippo" a "pippo_temp"?

Questa è una delle soluzioni possibili.
Ma quanto è lunga la struttura "pippo"? Se sono poche variabili, ti conviene copiarle una per una.
Il lavoro con i puntatori e un loop ha senso solo se la struttura è lunga.

 

Oppure, potresti passare il numero del DB, byte di inizio e lunghezza dell'area dalla FC1 alla FC2 (la quale FC2 è in SCL), e lavorare nella FC2 con indirizzamenti indiretti (vedi WORD_TO_BLOCK_DB).
Numero del DB, inizio e lunghezza dell'area potresti passarli alla FC1 in formato ANY, e ricavarli all'interno della FC1 per passarli alla FC2.

 

Sono solo idee, spunti, non soluzioni definitive.

 

1 ora fa, Cafard ha scritto:

(CPU S7300 per impianto nuovo)

Posso chiederti chi è il responsabile di questa scelta scellerata?
Il phase out del 300 era previsto per il 2020, poi rimandato, mi pare, di un paio di anni, ma comunque non lontano.
Il 300 ed i suoi moduli, a parità prestazioni, costano più dell'analogo 1500.
Il 1500, inoltre, come dimostra anche questo problema, non è migliore solo sotto il punto di vista prestazionale, ma è anche più evoluto.
Anche il Simatic Manager è un sistema di sviluppo che risale a circa 25 anni fa. Il TIA ha fatto molti passi avanti.
Anche la programmazione in SCL con il TIA è infinitamente più semplice che con il Simatic Manager.

 

Sarei proprio curioso di conoscere le motivazioni che hanno spinto qualcuno a scegliere un S7-300 per un lavoro nuovo.

[Cafard]

La struttura ha una cinquantina di elementi, per ora li ho trasferiti singolarmente . Se potrò dedicarci altro tempo proverò con il puntatore come hai descritto sopra.

 

 

2 hours ago, batta said:

Sarei proprio curioso di conoscere le motivazioni che hanno spinto qualcuno a scegliere un S7-300 per un lavoro nuovo.

 

Lavoro da poco, non so dirti cosa spinga a questa scelta chi prende la decisione.

 

Grazie per l'aiuto.

 

[Cesare Nicola]

Il 11/3/2020 alle 10:40 , batta ha scritto:

Però, la domanda che mi sorge spontanea è: perché, nel 2020, stiamo ancora lavorando con Simatic Manager e CPU S7300

Da noi lo si fa per utilizzare software già ben collaudati su macchine repliche o quasi di altre fatte in passato. Stiamo smettendo, per fortuna. 🙂