Consiglio su metodo di programmazione

[sorecaro]

Buonasera a tutti, vorrei avere un consiglio su come impostare una parte di programma. Devo eseguire la scalatura di vari ingressi analogici (circa 30) e visualizzare su un pannello operatore il valore. Per fare questo ho pensato a 3 strade:

1) creare una FC dove eseguo la scalatura del valore analogico e usare una DB globale come memoria per il valore scalato da passare al pannello operatore

2) creare una FB con tante DB di instanza e usare le variabili static da passare al pannellino

3) creare un  FB con DB multinstanza e passare al pannello operatore le varibili static

Qual'e' secondo voi la "strada" migliore?

Grazie

[batta]

La numero 1.

[Livio Orsini]

Sicuramente la prima, è anche più ordinata.

[sorecaro]

Grazie per il consiglio nazionale visto che ci siamo chiedo ancora un'altra cosa. Quando usereste le altre 2 strade ?

[JumpMan]

Recentemente ho usato la soluzione 2 per un solo FB "gigante" di oltre 5k di codice AWL con una sola DB  di istanza forse ancor più grande (non ricordo esattamente il nr. di bytes).

Il rovescio della medaglia è che se modifichi l'FB, anche solo aggiungendo un parametro di ingresso rischi di sfasare tutti gli indirizzi delle STAT e l'HMI non funziona più! Per ovviare a questo devi predisporre degli array "Dummy" in modo che ci siano delle riserve per aggiungere parametri senza spostare le STAT.

Un altro rovescio (praticamente una medaglia con 2 rovesci ) è che quando S7 ti chiede di rigenerare la DB perchè hai aggiunto un parametro tutti i dati vengono reinizializzati, per ovviare a questo ho previsto due ingressi bool per il backup/restore (effettuato con blkmove) della struttura STAT in un altra DB.

 

La soluzione 3 non è che mi piaccia molto, a volte la uso se ho delle parti di impianto che si ripetono, ma in caso di modifiche non mi sono trovato molto bene...

 

Nel tuo caso opterei anch'io per la 1

 

 

[sorecaro]

Visto che mi consigliate la prima strada userò quella Un altra curiosità ( cominciano ad essere troppo ) Dovendo gestire 9 inverter (marcia, arresto, jog, visualizzazione riferimento velocità, visualizzazione corrente assorbita, impostazione velocità tramite pulsante su hmi) mi creo una FC e la richiamo 9 volte passandogli i valori dell'inverter che devo elaborare ed appoggiare tutti i dati in una DB globale. 

[batta]

Quote

Dovendo gestire 9 inverter (marcia, arresto, jog, visualizzazione riferimento velocità, visualizzazione corrente assorbita, impostazione velocità tramite pulsante su hmi) mi creo una FC e la richiamo 9 volte passandogli i valori dell'inverter che devo elaborare ed appoggiare tutti i dati in una DB globale. 

In questo caso potrebbe essere conveniente passare ad una FB da richiamare 9 volte, ogni volta con un diverso DB di istanza.

Oppure, potresti utilizzare ancora una FC alla quale passare come IN_OUT tutta una struttura di dati (all'interno della FC viene creato un puntatore, ma tu non te ne accorgi: ti sembra di lavorare con le variabili della FC). Per fare questo, è indispensabile che la struttura dichiarata come IN_OUT della FC sia assolutamente identica alla struttura di dati che andrai a collegare alla FC. Torna comodo utilizzare il "Tipo di dati" (il vecchio UDT).

 

A volte utilizzo i due metodi insieme: creo una FB all'interno della quale dichiaro nelle STAT le variabili di appoggio per uso interno, e come IN_OUT le strutture di dati che desidero non siano all'interno del DB di istanza.

Per esempio, se ho N. motori posso creare un unico DB all'interno del quale creo un array di N. strutture. Ogni struttura, per esempio, contiene tutti i dati di setup.

Quando richiamo la FB devo, ovviamente, associare il relativo DB di istanza (oppure usare la multiistanza) e collego i dati di setup del relativo motore.

In questo modo mi trovo nel DB di istanza tutti dati di scarso interesse per pannelli operatore e altri blocchi di programma, e tutti i valori di setup belli ordinati nel DB dedicato.

[sorecaro]

Grazie Batta.  Ho pensato anche io di usare una FB con relativi DB di istanza ma nel programma dovrò gestire anche 10 PID, facendo due conti avrò circa 25 DB. Non sono molte ma ho paura che il programmi risulta poco leggibile in questo modo. Cosa ne pensi?

[JumpMan]

Quote

Oppure, potresti utilizzare ancora una FC alla quale passare come IN_OUT tutta una struttura di dati (all'interno della FC viene creato un puntatore, ma tu non te ne accorgi: ti sembra di lavorare con le variabili della FC). Per fare questo, è indispensabile che la struttura dichiarata come IN_OUT della FC sia assolutamente identica alla struttura di dati che andrai a collegare alla FC. Torna comodo utilizzare il "Tipo di dati" (il vecchio UDT).

Molto interessante e molto pulita come soluzione!

Per farla identica la struct si può anche copiare dalla db e incollare nei parametri dell'FC.

 

[batta]

Quote

Non sono molte ma ho paura che il programmi risulta poco leggibile in questo modo. Cosa ne pensi?

Ti spaventi per 25 DB?

Basta che ai DB assegni dei nomi chiari e la leggibilità non sarà un problema.

 

Quote

Per farla identica la struct si può anche copiare dalla db e incollare nei parametri dell'FC.

Sì, certo. Io di solito utilizzo i tipi di dati (almeno per strutture un po' complesse e che magari utilizzo più volte), perché così se devo fare una modifica mi basta mettere le mani al tipo di dati e aggiornare i vari utilizzi del tipo di dati.

[sorecaro]

No no che spavento. era solo per avere un parere da persone esperte come voi.  Quindi ritornando alla domanda principale la strada da seguire è la 2. Fb e DB istanza e variabili STATIC per visualizzare i dati sul pannello operatore