Minimizzazione Tempo Di Ciclo

[hunter]

Ciao a tutti. Sto cercando di controllare un processo tempo-critico con un PLC SIEMENS S7-300 PtP. Ho letto il tempo di ciclo del PLC nella finestra "stato dell'unità", che è mediamente pari a 2ms.

Come potrei fare per ridurlo a 1.5ms?

Ho pensato di raggruppare tutti gli FB del programma sorgente e di evitare l'uso dei blocchi FC105 e FC106 per la scalatura; sono operazioni consigliabili o è meglio agire diversamente?

Per favore aiutatemi!!!

[Ospite Emmanuele Leoni]

I dati Forniti sono un po' pochi per dare una risposta.

Il programma come è fatto? si utilizzano FB parametrizzati, in multiistanza?? Oppure si utilizzano Fb non parametrizzati?

Nel programma si è cercato di non processare le istruzioni non necessarie secondo i dati forniti dal campo?

Ciao!

Emmanuele Leoni

[Gianmario Pedrani]

Se vuoi cercare di ridurre ancora il tempo di ciclo devi ottimizzare il più possibile il tuo programma, es evita di usare dove puoi numeri reali, visto che impegnano maggiormente la cpu, cerca di indicizzare il piu possibile, ed utilizza salti, tipo spb, spa sulle parti di programma che in quel momento non devono essere elaborate, in questo modo accorci le istruzioni che se anche non fanno niente vengono elaborate dalla cpu, portando via tempo prezioso, utilizza db in modo molto sequenziale aprendolo allìinizio con il comando auf ed accedendo hai vari dati , anche perche l'accesso

t db50.dbw0 apre il db 50 trasferisce il dato e lo chiude , se poi inserisci un altro l db50.dbw0 riapri il db lo leggo e lo chiudi.

Se invece metti un auf db50 e poi fai le tue operazioni il db rimarra in memoria fino a quando non trova un altro auf

ciao prova e poi facci sapere....

[beppeconti]

Se riesci a farti la scalatura in AWL senza usare i blocchi FC105 e FC106 sicuramente qualcosa nel tempo di ciclo lo guadagni.

CIAO

[wnc]

Se devi elaborare qualcosa di urgente puoi utilizzare gli interrupt (OB a tempo).

Saluti

[bigalex]

Scusate l'intromissione, ma mi pare di aver capito che attualmente la CPU gira a 2 ms chè è già un tempo di scasione molto basso per un PLC "general purpose" e molto probalbilmente la CPU serie 300 è già di buon livello prestazionale (nuove 315 in sù) e anche il software che gira deve avere dimensioni contenute con poca periferia .

Il mio parere è che se vuoi fare un analisi di processo con un tempo ancora più basso probabilmente devi cambiare tipo di hardware , infatti tieni presente che il tempo ciclo della CPU è comunque condizionato da molti fattori sia hardware (quanta periferia deve gestire e che tipo di periferia deve gestire) si firmware e software (mole di scambio dati con le schede a bordo rack e/o periferiche e comunicazione con l'esterno ).

Se il tempo è così critico immagino che sia importante anche la garanzia dell'esecuzione del ciclo scasione , quindi non devi andare in "ciclico" (tempo ciclo variabile) ma devi andare in "periodico" (tempo ciclo imposto) .

Comunque in assenza di ulteriori informazioni sul processo diviene particolarmente difficile dare consilgi operativi.

bigalex

[TRUNC]

hunter (spero sia un nick a caso e non la realtà... ), se mentre sei on-line hai 2ms, puoi ragionevolmente presupporre che in off-line tele tempo sia sensibilmente inferiore, perchè i processi di comunicazione influenzano il ciclo logica.

Fai una prova: prendi un'uscita digitale libera e fai un segmento che ne faccia il complemento a uno in OB1.

Da off-line, collega un oscilloscopio a tale uscita e calcolane il semiperiodo: quello è il tuo tempo di ciclo reale (se togli il tempo per l'esecuzione del complemento a uno, per la precisione ).

Se non ti va ancora bene, vendi i fucili e con i soldi comprati una CPU serie 400.

[gramma]

Ciao.

Si, sono d'accordo con Bigalex. Il tempo di ciclo a 2ms è già molto basso per questo PLC. Che CPU monti? 313 o 318? i tempi cambiano molto, anche le caratteristiche hardware. sostituire le FC105 e FC106 con una routine scritta in AWL sicuramente ti farà risparmiare tempo di esecuzione (sono molto pesanti), anche indicizzare, aprire i DB con AUF, ecc. come scritto nelle altre risposte, ma credo sia difficile che riesci ad diminuire il tempo di 1/4 rispetto quello attuale.

Ma scusa, perchè hai necessità di un tempo di esecuzione così basso? Devi forrse laggere dei segnali con una variazione così veloce? Attenzione, perchè credo che diminuire il tempo di ciclo non sia sufficiente in questo caso, gli ingressi Siemens hanno un ritardo di 50microsec (se ben ricordo), se non utilizzi ingressi veloci o ingressi speciali impostabili (come nelle CPU 31xC), non riesci ugualmente a leggere i segnali veloci!

Se la CPU è 315 o 318, puoi eseguire le tue routine veloci in interrup. parlo di questi CPU perchè quelle inferiori non eseguono interrupt sotto i 5ms (almeno era così fino all'ultima volta che ho provato ad utilizzarli), ma avrai comunque il problema degli ingressi.

facci sapre.

ciao

[rddiego]

io non credo proprio che la tua cpu giri in 2 ms.... ti sarai sbagliato... oppure il tuo programma ha 2 istruzioni. A parte questo mio dubbio, verifica con sicurezza che il tempo ciclo sia quello che leggi facendo anche attenzione che il tuo programma giri per intero. Ciò per dirti facendo un esempio: ho una routine richiamata ogni secondo la quale esegue un centinaio di istruzioni per un ciclo solo. Quando voglio vedere il tempo ciclo della mia cpu vedrò probabilmente sempre 5-6 ms. La stessa routine la faccio eseguire sempre, controllo il tempo ciclo e trovo 35 ms.

Quindi assicurati di questo. Siccome i plc Siemens non sono così veloci tra quelli in commercio mi rimane il dubbio dei tuoi 2 ms.

[Savino]

Ciao,

Io sono d'accordo con rddiego, 2ms di programma are nothing!

saluto.

[TRUNC]

Io sono d'accordo con rddiego, 2ms di programma are nothing!

Sono d'accordo anch'io, anche perchè, da prove che ho fatto su una 315, con un programma banale avevo già oltre 6ms.

Motivo in più per fare la prova che ho detto.

Ciao!

[Livio Orsini]

Fai una prova: prendi un'uscita digitale libera e fai un segmento che ne faccia il complemento a uno in OB1.

Da off-line, collega un oscilloscopio a tale uscita e calcolane il semiperiodo: quello è il tuo tempo di ciclo reale (se togli il tempo per l'esecuzione del complemento a uno, per la precisione  ).

Usare un'uscita digitale per misurare tempi di ciclo brevi introduce un errore significativo dovuto al ritardo del filtro HW dell'uscita stessa.

La procedura migliore è usare un uscita analogica.

Io scrivo un valore alto all'inizio della procedura che intendo verificare e, altermine della medesima, riscrivo l'uscita analogica con un valore basso. Ovviamente bisogna usare l'istruzione immediata, altrimenti interviene anche il ritardo del registro immagine.

[beppeconti]

io non credo proprio che la tua cpu giri in 2 ms

Perchè?

Se le istruzioni non sono tante si può arrivare a tempi di ciclo di 2ms

Comunque se dal pannelo di controllo Simatic viene indicato un tempo di ciclo MEDIO di 2ms perchè non bisognerebbe fidarsi?

CIAO

[gramma]

Se le istruzioni non sono tante si può arrivare a tempi di ciclo di 2ms

Faccio presente che i tempi di esecuizione di un'istruzione a bit su questo PLC si aggirano intorno ai 0,1microsec!!

è vero che ogni 1 ms viene eseguita una routine di sistema, ma 2ms non sono poi un tempo così breve!

Bella l'idea di misurare il tempo di ciclo con un'analogica! Complimenti!!

ciao.

[TRUNC]

Usare un'uscita digitale per misurare tempi di ciclo brevi introduce un errore significativo dovuto al ritardo del filtro HW dell'uscita stessa.

Anche se ho un'ammirazione trascendentale per te, Livio, e so che è rischioso contraddirti, sono ragionevolmente sicuro che se l'errore introdotto nella commutazione da 0 a 1 è paragonabile a quello introdotto nel passaggio inverso, il problema non si pone, dal momento che, ripeto, io farei un solo complemento a 1 dell'uscita ad ogni ciclo logica.

Per quanto riguarda il ritardo di trasferimento dell'immagine alle uscite, a mio avviso anche quello fa parte del ciclo logica, e merita di essere tenuto in considerazione.

Ciao!

[JumpMan]

Anche se ho un'ammirazione trascendentale per te, Livio, e so che è rischioso contraddirti, sono ragionevolmente sicuro che se l'errore introdotto nella commutazione da 0 a 1 è paragonabile a quello introdotto nel passaggio inverso

Sono d'accordo, bisogna vedere però se l'hardware permette a una uscita digitale di commutare ogni 2 ms. Altrimenti bisogna incrementare una word ciclicamente e mandarla in uscita (T PAW), sulle 16 uscite, dovremmo avere così 16 frequenze multiple da misurare (per esempio la 4^ uscita rimane ON per 8 cicli e OFF per altri 8).

(dico tutto in via teorica, non ho mai provato e mi sono sempre fidato dell'indicazione sul pannello di controllo)

[TRUNC]

bisogna vedere però se l'hardware permette a una uscita digitale di commutare ogni 2 ms

In questi giorni stavo seriamente pensando di passare a Siemens una volta per tutte, ma quando leggo queste cose mi passa la voglia.

[wnc]

In questi giorni stavo seriamente pensando di passare a Siemens una volta per tutte, ma quando leggo queste cose mi passa la voglia.

Lascia perdere.......

Saluti

[Livio Orsini]

Anche se ho un'ammirazione trascendentale per te, Livio, e so che è rischioso contraddirti, sono ragionevolmente sicuro che se l'errore introdotto nella commutazione da 0 a 1 è paragonabile a quello introdotto nel passaggio inverso, il problema non si pone, dal momento che, ripeto, io farei un solo complemento a 1 dell'uscita ad ogni ciclo logica.

Lasciamo perdere l'ammirazione e analizziamo secondo logica.

Il passaggio da on a off di un uscita digitale, che voglio credere sia allo stato solido, ha tempi di ritardo diversi, che possono essere anche dell'ordine del millisecondo o più.

Il tempo dovuto al passaggio attraverso le tabelle immagini è legato a tutte operazioni in back ground e for ground del PLC, quindi non è molto costante e ripetitivo.

Se usi sempre i medesimi valori sul convertitore D/A, p.e. 0 e 7ff, i tempi di conversione sono costanti, ripetibili, e dell'ordine dei microsecondi.

Porva, per curiosità, ad effettuare contemporaneamente e con istruzioni immediatamente seguenti il tuo test ed il mio. Ovviamente in un programma con diversi blocchi. Poi verifca i rispettivi tempi. Potresti avere delle sorprese non piacevoli...

[JumpMan]

Se volete indicazioni + precise fate click qui

e scaricate la documentazione (PDF) della cpu 31xC, io l'ho appena scaricato e dentro vi è un intero capitolo (5) che parla dei tempi di ciclo e di reazione.

Al capitolo 6.6.7 ci sono i dati delle uscite digitali:

- fMax Uscite veloci (ce ne sono 2 sulle cpu 31xC) = 2.5 kHz (0.4ms)su carico ohmico

- fMax Uscite normali = 100 Hz (10ms)su carico ohmico

- fMax Uscite normali = 0.5 Hz (2s)su carico induttivo

L'analogica risponde in circa 0.6ms.

Modificato: 25 settembre 2004 da JumpMan

[Livio Orsini]

Al capitolo 6.6.7 ci sono i dati delle uscite digitali:

- fMax Uscite veloci (ce ne sono 2 sulle cpu 31xC) = 2.5 kHz (0.4ms)su carico ohmico 

- fMax Uscite normali = 100 Hz (10ms)su carico ohmico 

- fMax Uscite normali = 0.5 Hz (2s)su carico induttivo 

Se Siemens da i valori corretti, e di norma lo fa, questi sono i valori limite, nella pratica corrente i ritardi possono essere più limitati.

Manca però un dato, che non viene menzionato perchè di difficile quntizzazione. Non viene detto niente al rigurado delle variazioni dei tempi di ritardo e del'influenza del carico capacitivo. L'influenza della componente capacitiva non è trascurabile, visti i valori di capacità parassita che può assumere un normale cablaggio all'interno del quadro (non consideriamo il bordo macchina perchè qui la faccenda si fa veramente pesante).

Volendo essere precisi mancano anche le considerazioni relative all'influenza della variazione del carico resistivo e induttivo. Un carico resistivo da 100 ohm non ha un comportamneto udentico ad uno di 2000 ohm.

L'uso dell'uscita analogica come indicatore per le misure di periodo offre un unlteriore vantaggio: la costanza quasi assoluta dei tempi di ritardo.

[TRUNC]

Porva, per curiosità, ad effettuare contemporaneamente e con istruzioni immediatamente seguenti il tuo test ed il mio. Ovviamente in un programma con diversi blocchi. Poi verifca i rispettivi tempi. Potresti avere delle sorprese non piacevoli...

Lo farò senz'altro, sono proprio curioso. Grazie Livio.

Ciao!

[hunter]

Ciao a tutti, sono HUNTER.

Vi ringrazio caldamente tutti per l'aiuto offertomi che mi servito molto.

Mi scuso se rispondo solo adesso ma in questo periodo mi sono occupato di altri problemi.

Ho misurato il tempo di ciclo mandando in una uscita analogica un'onda quadra in prossimità della fine del mio programma, e l'ho analizzata sull'oscilloscopio, all'incirca come indicato da ORSINI (che ringrazio molto per avermi in pratica risolto il problema).

L'onda quadra letta ha frequenza 332Hz; quindi il mio PLC lavora a 664HZ.

Ottimizzare il programma raggruppando 5 blocchi FB ed evitando di utilizzare le funzioni FC105 ed FC106 è sconsigliabile in quanto non apporta alcuna modifica al tempo di ciclo che presumibilmente sarà legato ai tempi di aquisizione/invio dati della scheda di I/O.

Non posso commentare altro perchè non ho le competenze necessarie.

Grazie a tutti e a buon rendere !!!!!!