moka7 dbread

[Dannyy]

Buongiorno a tutti.

 

Esiste un limite in numero per la lettura dei DB in moka7?

 

Es:

Client.SetConnectionType(S7.OP);

int Result = Client.ConnectTo(IpAddress, Rack, Slot);

if (Result==0)

  while(true)

  {

   byte[] Buffer1 = new byte[60];

   int result1 = Client.ReadArea(S7.S7AreaDB, 1, 0, 60, Buffer);

   if (result1 !=0)

   break;

   …

   …

   byte[] Buffer2 = new byte[60];

   int result2= Client.ReadArea(S7.S7AreaDB, 2, 0, 60, Buffer2);

   if (result2 !=0)

   break;

   …

   …

   byte[] Buffer3= new byte[60];

   int result3 = Client.ReadArea(S7.S7AreaDB, 3, 0, 60, Buffer3);

   if (result3! =0)

   break;

   …

   …

   //ripetiamo il codice per n volte quanti sono i db da leggere.

   byte[] Buffer_n= new byte[60];

   int result_n = Client.ReadArea(S7.S7AreaDB, n, 0, 60, Buffer_n);

   if (result_n ! =0)

   break;

   …

   …

   }

Client.Disconnect();

 

In questo caso come gestisce la comunicazione il processore della CPU?

Esiste un modo più efficiente (senza pensare al tempo di elaborazione e creare nuovi DB) per ottenere lo stesso risultato?

 

 

Infinite grazie a Davide Nardella per il suo grande lavoro.

 

Grazie.

[dan64100]

Quote

Esiste un modo più efficiente (senza pensare al tempo di elaborazione e creare nuovi DB) per ottenere lo stesso risultato?

 

Un modo più efficiente esiste per Snap7 (Moka7 è una versione ridotta completamente in Java).

Con Snap7 puoi utilizzare Cli_ReadReadMultiVars (o Write) che può leggere più variabili posizionate in DB diverse in un unica funzione.

 

Ci sono comunque alcune controindicazioni:

1. Puoi leggere max 20 variabili per volta
2. La quantità complessiva dei dati deve rimanere all'interno del PDU.
3. Ogni variabile contiene un descrittore nel telegramma di andata e ritorno per cui il payload finale diminuisce.

 

Quindi verresti a perdere il vantaggio della lettura indipendente dal PDU cioè la caratteristica di Snap7 di splittare in più telegrammi una richiesta di molti byte.

 

Comunque non mi è chiaro cosa intendi per "creare nuovi DB".

 

Un altro modo per migliorare l'efficienza è quello creare più client connessi alla stessa CPU e gestirli i thread separati.

Considera però che:

 

1. hai bisogno di più risorse di comunicazione lato CPU, che magari hai già perché hai solo un HMI.
2. La CPU gestisce una coda interna di canali attivi, e non è dato sapere come, che varia da processore a processore, per cui per CP esterne o CPU vecchie guadagneresti ben poco. In genere comunque vale la pena provare.

 

 

Quote

In questo caso come gestisce la comunicazione il processore della CPU?

 

Esattamente come sono scritte nel codice : trasferimenti sequenziali e sincroni (il successivo parte quando è completo il precedente).

 

[Dannyy]

Eseguendo lo script nel programma java,  il processore di comunicazione della CPU vede un pannello operatore che interroga una serie di DB in maniera sequenziale ed ordinata, allocando le risorse di elaborazione per una sola unità OP, è corretto?

 

Per gestire in totale autonomia la riconnessione alla CPU ( in caso di spegnimento problemi di rete ecc.) pensavo di crere un thread separato che controllasse lo stato della

connessione, cosa ne pensi?

 

 

Nello scrivere "creare nuovi DB" intendevo,  creare DB dove copiare il contenuto dei byte da leggere in una sola operazione tramite dbread.

 

Appena ho un po di tempo vedo di studiare il magico C++

 

Grazie.

 

 

 

 

[Dannyy]

Scusate ma solo ora vedo che è presente la risposta alla domanda (riconnessione CPU) in questa discussione :

libreria Moka7: giusta la mia procedura di utilizzo??