Variabili temp in blocchi FC richiamati da FB in TIA Portal v14.1

[marcopez]

Buongiorno a tutti,

volevo sottoporre alla vostra attenzione questa particolarità nell'uso delle variabili temp nei blocchi FC in ambiante TIA Portalv14.1.

Attualmente sto utilizzando delle funzioni di libreria tipo FC da me scritte e che richiamo in blocchi FB in configurazione multistanza.

Nelle FC eseguo calcoli o operazioni logiche utilizzando delle variabili temp di appoggio nei calcoli intermedi, le variabili temp sono definite all'interno del blocco FC.

Ho potuto osservare che facendo un richiamo incapsulato ad esempio di una FC1 da parte di una FB10 che a sua volta è richiamata da una FB15, la FC1 non funziona regolarmente dato che si comporta come se le temp al suo interno definite, fossero delle costanti pari a zero. Per risolvere tale problema è stato necessario condividere le variabili intermedie della FC1 come IN/OUT ed appoggiarle alle temp di FB10 oppure alle static di FB10.

Ho guardato sulla documentazione Siemens ma non sono riuscito a trovare informazioni su problemi di chiamate iterative multiple di blocchi FC da parte di blocchi FB.

A qualcuno è mai capitato un problema simile? Non capisco se è un limite dell'ambiente di sviluppo oppure uso Io impropriamente i blocchi FC.

Ogni vostra considerazione è ben gradita.

Vi ringrazio anticipatamente per l'attenzione.

Saluti

 

Marco Pezzetta 

[batta]

Secondo me, stai usando le variabili temp in modo errato.

Puoi pubblicare il codice della FC?

[marcopez]

Ciao, ecco il codice

 

dichiarazioni variabili:

InOut:

Random - UInt

temp:

    k   -  Word            
    temp  -  Array[0..15] of Bool            
    LSB  -  Bool            

 

codice

#k := UINT_TO_WORD(#Random);
SCATTER(IN := #k,
        OUT => #temp);
#LSB := #temp[15] XOR #temp[13] XOR #temp[12] XOR #temp[10] ;
#Random := SHL_UINT(IN := #Random, N := 1) + BOOL_TO_UINT(#LSB);
 

si tratta di un banale random generator.

quello che si osserva è come se l'array #temp fosse sempre nullo...

Grazie

Ciao da Marco

[marcopez]

Dimenticavo anche #LSB è sempre nullo...dato che si osserva lo shift verso sinistra del dato senza modifica del bit 0

Grazie

Ciao da Marco

[batta]

Il codice sempba corretto, per quanto riguarda l'uso delle variabili temp, ma non capisco il funzionamento.

Fino a quando non vengono impegnati i bit 10, 12, 13 e 15 di Random, viene solo effettuato uno shift a sinistra di un bit.
Poi, dopo lo shift, può essere sommato 1 oppure 0.

Se Random contiene zero, rimarrà sempre a zero.
Per me, il problema è a monte.
Hai verificato il valore di #Random (e quindi di #k), quando entri nella funzione?

[marcopez]

Ho verificato i valori di #Random, #k, #temp ed #LSB facendoli emettere come Out dalla FC e il valore di #Random è passato giusto, tutti le altre variabili sono zero.

Hai ragione sul fatto che se #Random è zero rimarrà a zero. A livello di implementazione la variabile #Random viene caricata con un valore di default diverso da zero, in generale è un fatto che l'algoritmo che ho riportato non contempla lo zero, infatti se tutto funziona regolarmente dovrebbe generare dei numeri casuali da 1 a 65535 con distribuzione uniforme.

In pratica il bit0 del nuovo #Random generato viene popolato dalla parità dei bit 10, 12, 13 e 15 del #Random precedente.

Ribadisco la cosa bizzarra che osservo è che le variabili temp della FC1 sembrano non sopravvivere ad un annidamento ricorsivo di tre chiamate all'interno di FB.

Inserendo ad esempio la FC1 in una singola FB tutto funziona regolarmente.

Per quanto sono riuscito a documentarmi sui manuali Siemens, non si parla di vincoli nell'inclusione di FC all'interno di FB.

Grazie

Ciao da Marco

[batta]

Ho fatto un test come segue:
 

FB_A
  | FB_B
      | FB_C
          | FB_D
              | FB_E
                  | FB_F
                      | FC_Random
 

Le FB sono tutte annidate come multistanza.
Tutto funziona.

 

Rimangono le mie perplessità sulla funzione Random.
Se parti con valore 1, fino a quando non verranno impegnati i bit 10, 12, 13, 15, è solo uno shift a sinistra di un bit, che equivale a moltiplicare per 2.
E poi, chi mi garantisce che, casualmente, non possa assumere valore zero e non ripartire più?
Un metodo che, a volte, si usa nei PLC per avere un numero pseudocasuale, è andare a leggere l'unitù più piccola dell'ora di sistema.
Con Siemens, per esempio, nel formato DTL leggi i nanosecondi in formato UDInt.
Impossibile, anche volendo, sincronizzare una scansione sui nanosecondi, quindi, questo valore, per quanto non abbia nulla di casuale, essendo letto in istanti casuali, si può assumere come valore casuale.
Potresti valutare solo le 3 o 4 cifre meno significative, ed avere un valore pseudo casuale da 0 a 999, o da 0 a 9999.

Se ti interessa questa soluzione, la data e ora di sistema la puoi leggere con RD_SYS_T.

 

[marcopez]

Ti ringrazio per le varie considerazioni, credo che sia il simulatore a questo punto ad essere il problema.

Capisco la tua perplessità ma la funzione Random non và mai a zero, ammesso che la si faccia partire con un valore diverso da zero, questo l'ho verificato per dove ho potuto per ora.

Molto interessante la soluzione con l'orologio di sistema, non pensavo che contenesse informazione fino ai nanosecondi, sicuramente è un'ottima alternativa.

Verifico meglio il simulatore, mi conforta il fatto che almeno tu sei riuscito a far girare la FC con un grado di annidamento 6, confido che il problema sia di altro tipo

Per ora ti ringrazio molto e grazie per il supporto.

Un caro saluto

 

Marco

[batta]

1 ora fa, marcopez ha scritto:

credo che sia il simulatore a questo punto ad essere il problema.

Io ho provato con il simulatore PlcSim V16 upd2.

[walterword]

io evito di annidare e non uso FB per le rotuine.

I DB di istanza per i timer TON etc li dichiaro in DB globali in forma vettoriale per disaccoppiare parti di impianto e non avere il problema di dichiarare DB di istanza

Fossi in te proverei a mettere giù l'algoritmo senza troppi intoppi di FB -> FC e annidamenti vari.

Fai un FC con DB globale o un FB con DB istanza e variabili statiche e provi . Le temp le uso solo per "allungare un RLC " su più segmenti.

Hai tanta memoria ram da buttare usala.

L'annidamento è un problema che riguarda lo stack e l'heap dei processori, annidare troppo rischi di ritrovarti problemi.

In step 7 queste cose le ritrovavi dopo qualche anno, aprivi un DB di istanza e ti risultava tutto rosso con la scritta delle variabili "Stat" ....perdevi qualche bulbo di capello rimasto ed eri nella m....a.

Non capisco nemmeno a cosa possa servire una funzione random in un sistema di automazione industriale.

Tutt'al più se c'e', e c'e' sempre, un livello 2 su pc che fa da bridge al livello 3 etc , lo fai fare al pc il random e ti fai inviare le missioni o i dati.

il plc va usato per certi scopi, la distribuzione delle carte da scopa d'assi non la vedo una cosa fattibile, però se vuoi giocare ....