Come misurare/scegliere il tempo di scansione su STEP 7

[brody09]

Salve,

 

come da titolo, gentilmente qualcuno può aiutarmi a dire come misurare/scegliere il tempo di scansione su step 7? Tutto questo serve in seguito per calcolarmi il tempo di risposta.

Grazie mille.

[JumpMan]

Usi Simatic manager o TIA?

In Simatic Manager clicca su cartella blocchi poi premi CTRL+D (oppure tasto dx sulla cartella blocchi>sistema di destinazione>stato dell'unità), nella finestra che appare c'è una cartella "tempo di ciclo".

Se il dato ti serve anche all'interno del programma apri OB1, abbassa la tendina e trovi OB1_PREV_CYCLE che ad ogni ciclo riporta il valore del t.ciclo precedente.

 

[brody09]

Salve,

 

si utilizzo simatic manager.

OK grazie mille. 

Ma il tempo di ciclo sarebbe il tempo di scansione?

Inoltre, per calcolare/scegliere il tempo di risposta senza conoscere il tempo di scansione come fare?

Grazie mille

[JumpMan]

Ni.... il tempo di ciclo è il tempo di scansione di OB1 + il tempo dedicato alla lettura dell'immagine di processo degli ingressi + il tempo dedicato alla scrittura dell'immagine di processo delle uscite.

E' come se ci fosse un cronometro che parte assieme alla prima istruzione di OB1 e rileva il tempo-giro ogni volta che ripassa per quel punto, quindi viene calcolato non solo OB1 ma anche tutto il resto.

Quote

senza conoscere il tempo di scansione 

Lo conosci, è nella variabile OB1_PREV_CYCLE.

 

Se hai esigenze particolari puoi impostare un tempo per OB35 che è elaborato ad intervalli regolari, a differenza di OB1 che non è mai costante.

[brody09]

Grazie mille, gentilissimo.

Quindi conosciuto il tempo di ciclo, si può dire che il tempo di risposta è circa il doppio, giusto?

Oppure per calcolare praticamente il tempo di risposta (cioè il tempo che impiega il processore del PLC a rispondere ad un evento) bisogna utilizzare un cronometro?

Ad esempio: data una fotocellula che rileva un oggetto,per ricavare il tempo di risp devo cronometrare il tempo che impiega il processore a verificare l'evento (cioè il tempo che impiega la fotocellula per rilevare l'oggetto? ) ??

Grazie ancora

[Livio Orsini]

Quote

Quindi conosciuto il tempo di ciclo, si può dire che il tempo di risposta è circa il doppio, giusto?

 

Si e no.

Quote

 

Ad esempio: data una fotocellula che rileva un oggetto,per ricavare il tempo di risp devo cronometrare il tempo che impiega il processore a verificare l'evento (cioè il tempo che impiega la fotocellula per rilevare l'oggetto?

 

 

 

partiamo da questo caso.

La fotocellula è interfacciata ad un ingresso digitale normale.

Quando l'uscita della fotocellula cambia stato il suo segnale entra nell'ingresso digitale, viene ritardato dal filtro di ingresso. Il tempo di ritardo è una caratteristica della scheda ed è specificato sul suo manuale.

Dopo questo ritardo il segnale è presente nella periferia esterna ma sarà disponibile per l'elaborazione solo dopo che il sistema operativo avrà copiato gli stati degli ingressi nella tabella immagine.

La copia della tabella immagine avviene all'inizio di ogni ciclo di elaborazione.

Ora supponiamo un tempo di ciclo pari a 5ms, tanto per fissare dei numeri.

Nel caso pessimo lo stato della fotocellula cambia appena un nanosecondo dopo che il sisstema operativo ha acquisito gli ingressi; quindi dovranno trascorrere 5 ms prima che questa variazione sia acquisita dalla CPU, poi bisogna attendere che il programma elabori l'informazione. Questo tempo dipende da dove è situato nel ciclo di programma, ma questo è poco importante perchè gli effetti si vedono solo al termine del ciclo.

Quindi nel caso pessimo il ritardo tra evento ed effetto di questo evento è pari a due cicli di programma. Nel nostro caso 10ms.

 

Nel caso di segnali impulsivi è indispensabile, per avere la certezza di elaborare il segnale, che l'impulso rimanga stabile in uno stato per un tempo maggiore a 2 cicli di programma.

Ad esempio se leggo una ruota fonica ed il mio tempo di ciclo massimo è paria 5ms, è necessario che gli impulsi abbaino una durata > 10ms sia nell stato di "1" che in quello di "0", totale >20ms, ovvero se i segnali son o perfettamente quadri, 50% on e 50% off, la frequenza nassima di conteggio è <50Hz.

 

Ci sono metodi per rendere più veloce l'acquisizione dei segnali.

• Interfacciare il segnale ad un ingresso veloce che scatena un interrupt; in questo caso il ritardo è solo il tempo di latenza dell'interrupt ed il ritardo del filtro di ingresso della scheda.
• Leggere direttamente il segnale con accesso diretto alla periferia, ovvero il programma non elabora l'immagine in memoria ma legge l'ingresso fisico.
• Leggere direttamente il segnale con accesso diretto alla periferia più volte durante l'elaborazione del ciclo di programma.

 

Dimenticavo.

Se si vuol misurare il tempo reale tra la variazione del segnale di ingresso e l'effetto dell'elaborazione, per esempiol tra l'impgno della fotocellula e la chiusura di un'uscita si confrontano con un oscilloscopio i fronti dei 2 segnali, però non si ha la certezza di misurare il caso pessimo. Compiendo una serie numerosa di misure si può stimare il tempo medio di risposta. Il caso pessimo lo si detrmina solo facen do i conti considerando il tempo di ciclo massimo.

 

[brody09]

wauuu  Grazie, grazie, grazie!  Gentilissimo.

 

Un ultima cosa...per misurare il tempo (stimato) tra la variazione del segnale d'ingresso e l'effetto dell'elaborazione, ad esempio di una fotocellula, come bisogna fare? Impossibile cronometrare xD. C'è un modo per farlo direttamente con step 7? Grazie ancora.

 

Buona giornata.

 

[Livio Orsini]

Te l'ho scritto in fondo al messaggio.

[brody09]

E come misuro con l'oscilloscopio? Non c'è un modo pratico su step7?

[Livio Orsini]

Quote

Non c'è un modo pratico su step7?

Non credo.

Quote

E come misuro con l'oscilloscopio?

 

Te l'ho scritto misuri il ritardo tra i 2 fronti.

A questo punto la domanda la faccio io: sai usare un oscilloscopio?

[brody09]

OK. Si, ma non è presente in lab. Grazie ancora

[DesmoGiec]

Io provo a buttare un idea, ma al lato pratico non so quanto possa essere affidabile.

OB1, richiama sfc64 ed appoggia a md0 (esempio) (ovviamente il call a sfc4 lo metterai come prima operazione)

In FCx, ossia l'fc dove controlli l'ingresso che ti serve, al fronte dell'acquisizione del segnale richiami sfc64 ed appoggi a md4. Eseguirai poi una sottrazione tra md4 e 0 ed avrai la differenza in ms.

 

Sostanzialmente, in ob1 memorizzi il tempo interno della cpu al momento in cui parte a ciclare il programma.

richiamando sfc64 una seconda volta nell'fc di tuo interesse, memorizzerai il tempo interno al momento dell'acquisizione del segnale che ti interessa.

 

Ho fatto questo giochino proprio adesso per verificarne l'utilità, usando un vipa 200.

Il tempo di ciclo minimo è 17ms, il massimo 51ms.

Ho fatto in modo poi di verificare il ciclo precedente da ob1 e discosta di circa 5ms dal tempo che calcolo, quindi.. boh, sembra che funzioni.

(Il ciclo precedente lo memorizzo al ciclo successivo dall'operazione, così ho il "ciclo precedente" congruo al ciclo effettivamente utilizzato nel calcolo dello scostamento)

 

 

[Livio Orsini]

Quote

e discosta di circa 5ms dal tempo che calcolo,

 

E' un'eternità; errore che va da al 10% al 29% !

Il tempo di ciclo lo si può leggere senza fare conti.

Se lo si vuole misurare con precisione esatta come prima istruzione di OB1 si legge lo stato di un'uscita e la si riscrive negata.

Se si usa l'accesso diretto alla periferia oppure si alvora sulle tebelle immagini le cose non cambiano perchè tra una scansione e la successiva di OB1 ci sono sempre di mezzo gli aggiornaemnti degli I/O.

Con un'oscilloscopio si monitorizza il segnale prodotto dalla varaizione di stato dell'uscita e si ha la misura esatta del tempo di ciclo, volta per volta.

[DesmoGiec]

Certo Livio, ma senza oscilloscopio la vedo dura. Per rispondere se si possa fare a lato plc invece..

E' un eternità, è vero, ma con questo vipa con cui ho fatto la prova , a programma "fermo", ossia senza i/o che cambiano o variazioni sui calcoli etc, il ciclo va dai 17 ai 25 ms già per i fatti suoi (memoria occupata al 97%).

Oltretutto io ho triggerato l'evento per calcolare la differenza in mezzo ai richiami, non alla fine del programma, per questo ho detto "funziona".

Avessi triggerato alla fine del ciclo mi sarei aspettato una differenza minima in tutti i sensi (nel senso che se il ciclo=22ms, la differenza tra ob1 e il calcolo triggerato a fine ciclo sarebbe stato di 20/21ms), ma 5 ms calcolati con ancora da eseguire una ventina di fc mi sono sembrati "veritieri".

 

In sostanza, nel mio post precedente:

il ciclo era 22ms, da ob1 (tempo 0) al momento in cui ha elaborato il trigger, son passati 18ms, nei restanti ms ha finito il ciclo e rielaborato le immagini.

Se sia affidabile o meno? Boh!

[Livio Orsini]

Se l'evento lo leggi da tebella immagine è sempre comunque dipendente dal tempo di ciclo, quindi è inutile farsi degli scripoli e cercare di depurare l'elaborazione dal tempo di ciclo, quello che esce dalla finestra rientra dalla porta.

 

Anche se si fa l'accesso diretto dalla periferia il tempo di ciclo ricompare comunque nell'elaborazione perchè 2 letture/scritture consecutive son comunque legate al tempo di ciclo, a meno di fare letture multiple nel corso del programma.

 

la valuazione del caso pessimo del tempo di ciclo serve unicamente a determinare se un dato evento lo posso acquisire con sicurezza attraverso un ingresso normale o se è necessario ricorrere ad un ingresso ad interrupt.

 

PS Dai miei ricordi i pregi dei sistemi VIPA rispetto a Siemens erano, oltre al costo inferiore, una maggiore velocità delle CPU di pari livello. Quei tempi m i sembran verament lunghi; però se l'occupazione è del 97% e la CPU è di basso livello, potrebbero essere reali.