Apertura Db S7 300

[kamikaze]

195 ms???

Personalmente non accetterei mai un tempo ciclo del genere, per quanto poco critica sia l'applicazione.

Caro Ecup, nel principio l'handling e' abbastanza semplice, ma il tracking fatto con 18 stazioni MOBY-M , mi portava via un casino di tempo ciclo per la sicronizzazione dei moduli.

Poi la sua parte la faceva il programma , molto voluminoso.

Cambiare CPU, era una cosa a cui mi ero psicologicamente preparato

Ma fortunatamente le prestazioni del collaudo non hanno dato esito negativo.

Anzi, e' 3 anni che funziona! Egregiamente.

Ivan

[Ecup]

Caro Ecup, nel principio l'handling e' abbastanza semplice, ma il tracking fatto con 18 stazioni MOBY-M , mi portava via un casino di tempo ciclo per la sicronizzazione dei moduli.

Effettivamente 18 stazioni MOBY-M sono molte... per quanto mi riguarda c'è stato un progetto dove ne usavo 4 in accoppiata a 4 lettori di barcode, e due stampanti di barcode. Se ricordo bene ero comunque intorno ai 20ms (CPU317)... un tempo 10 volte più alto non lo accetterei mai io per mia coscienza personale, anche se posso capire che in certe situazioni possa essere accettabile.

ciao

[kamikaze]

Ciao Ecup,

solo per precisare, quando mi riferivo a 195 ms, mi riferivo al tempo massimo misurato.

Il tempo medio di scansione era la meta'.

Appunto come ti dicevo, il numero elevato di RFID , mi aveva creato un problema , che a volte non facevano il loro dovere.

Quindi, ciclicamente nell'OB1 al lancio di un job di scrittura o lettura, aspettavo in un loop segni di vita dall'unita' per evitare problemi, questo e' il motivo fondamentale per il picco di 195ms (leggere ed aspettare il life bit da 18 MOBY).

non lo accetterei mai io per mia coscienza personale

Come sei esigente.

Meno male che non sei il mio capo!

nche se posso capire che in certe situazioni possa essere accettabile.

Troppo buono....

Ivan

[Ecup]

Ciao Ecup,

solo per precisare, quando mi riferivo a 195 ms, mi riferivo al tempo massimo misurato. Il tempo medio di scansione era la meta'.

Così è decisamente più ragionevole, anche se 100ms di tempo medio, IMHO è comunque troppo alto

Appunto come ti dicevo, il numero elevato di RFID , mi aveva creato un problema , che a volte non facevano il loro dovere.

Quindi, ciclicamente nell'OB1 al lancio di un job di scrittura o lettura, aspettavo in un loop segni di vita dall'unita' per evitare problemi, questo e' il motivo fondamentale per il picco di 195ms (leggere ed aspettare il life bit da 18 MOBY).

Forse ho inteso male, ma non capisco la necessità di "attendere in un loop"... se ben ricordo c'è un bit di stato che mi dice che il MOBY è pronto; a quel punto, quando ne ho la necessità, lancio il comando (lettura e scrittura che sia) e faccio altro, proseguendo con il mio ciclo di gestione dell'impianto... senza aspettare in un loop che il MOBY mi risponda... quando mi risponderà agirò di conseguenza. Se entro un certo tempo dal comando non ricevo la risposta di comando eseguito (senza errori), allora do un allarme di timeout e agisco di conseguenza (c'è anche un bit di comando per fare una sorta di reset). Ma forse la tua situazione era diversa...

In ogni caso, anche escudendo questi job di controllo che ti davano i picchi a 200ms, un tempo medio di 100ms secondo me è veramente altissimo, e per come la vedo io significa che c'è qualcosa che non va, o nella programmazione, o nella scelta della CPU... con tutto rispetto per il tuo lavoro... probabilmente sei anche molto più bravo di me (io 18 MOBY non li ho mai gestiti, mi sono fermato a 4: magari con 18 avrei lo stesso problema), ma cerco di seguire una certa filosofia di lavoro, e certe cose lo ho imparate per esperienza diretta da persone che mi stanno intorno e che stimo per quello che riescono a fare.

Come sei esigente. laugh.gif

sotto molti punti di vista si...

Meno male che non sei il mio capo! laugh.gif

Non preoccuparti... non ho la stoffa per fare il capo (non ora perlomeno).

.

Troppo buono.... worthy.gif

Questione di punti di vista... 200ms è un tempo che uso frequentemente per filtrare alcuni sensori e decidere come proseguire le movimentazioni su certi tipi di macchine (movimenti idraulici): un tempo ciclo di grandezza paragonabile sarebbe semplicemente inaccettabile. Tieni presente che una CPU, di default, ha un controllo di tempo massimo di ciclo impostato a 150ms; certo, lo puoi sempre cambiare, ma secondo me si tratta di un dato che ha un certo significato, non un numero messo lì a caso...

ciao

PS: trovo molto "pericolosa" anche l'idea dello "short loop", anche se sotto certi aspetti è geniale

[Luca Bab]

solo per precisare, quando mi riferivo a 195 ms, mi riferivo al tempo massimo misurato

per curiosita' , come lo misuri ???

Anche nei miei casi 195ms e' uno sproposito ( non riesco ad immaginarmi cosa bisogna fare per ottenerlo ) , poche volte vado sopra i 15ms

Se mi mettessi a fare dei calcoli del genere diventerei piu' folle di quello che gia' sono

anch'io non mi metto a fare conti del genere , pero' li tengo in considerazione ( quando posso ovviamente )

faceva saltare il 90% del codice durante il posizionamento , riducendo il tempo ciclo a 65ms.

questa e' una cosa che temo molto e cerco di evitare il piu' possibile , mi piace molto un SW con un tempo di scansione piu' stabile possibile

ciao

Luca

[kamikaze]

Ciao Ecup,

se ben ricordo c'è un bit di stato che mi dice che il MOBY è pronto; a quel punto, quando ne ho la necessità, lancio il comando (lettura e scrittura che sia)

Tutto giusto, ma non mi bastava.

senza aspettare in un loop che il MOBY mi risponda... quando mi risponderà agirò di conseguenza

A quel punto era troppo tardi, potevo anche aver sbagliato l'interpretazione del codice.

Per motivi di sicurezza , dovevo creare un sistema ridondante , sui job di scrittura e lettura.

Dovevo , lanciare il job, attendere lo stato di job in corso -->fine job, prelevare il valore della DB , aggiornare il puntatori delle arre di memoria , recuperare tutte le informazioni sul prodotto, generare i dati per il file di stampa che veniva inviato via MPI al PC di area , e poi indirizzare il pezzo alla posizione esatta di stoccaggio, con certezza del 100%.

Purtroppo da prove fatte inizialmente con una gestione semplice non avevo questa garanzia , forse 18 nodi profibus solo per i Moby erano vermente troppi (anche questo motivo per cui ero preparato a sostituire la CPU da 315 a 317).

Luca,

solo per precisare, quando mi riferivo a 195 ms, mi riferivo al tempo massimo misurato

per curiosita' , come lo misuri ???

Nello stato dell'unita' ciclo di clock , ti appare una finestra con tre valori, min, max e attuale del tempo ciclo.

Anche nei miei casi 195ms e' uno sproposito ( non riesco ad immaginarmi cosa bisogna fare per ottenerlo ) , poche volte vado sopra i 15ms

Adesso non facciamo tutti i santi,

Se faccio un programma semplice semplice OK, ma se comincio a metterci , indicizzazione delle variabili, ricette, puntatori calcoli in virgola mobile, gestione schede conteggio veloce, gestione CP di comunicazione, ed ammennicoli vari ....ed un programma di oltre 64k, che il cliente "a capitolato!!" ti chiede che sia il piu' possibile in LADDER e' facile arrivare a tempi di scansione pesantucci.

Poi il discorso della CPU.....uno cerca di ottenere il massimo da quello che ha.

Non credo che vi sia un premio "per il miglior ciclo di scansione". Magari esiste per il peggiore?

15ms?

Se registro un tempo cosi' vado a vedere se mi sono dimenticato di caricare tutto il programma...

Ivan

[Savino]

Adesso non facciamo tutti i santi

Se faccio un programma semplice semplice OK, ma se comincio a metterci , indicizzazione delle variabili, ricette, puntatori calcoli in virgola mobile, gestione schede conteggio veloce, gestione CP di comunicazione, ed ammennicoli vari ....ed un programma di oltre 64k, che il cliente "a capitolato!!" ti chiede che sia il piu' possibile in LADDER e' facile arrivare a tempi di scansione pesantucci.

Poi il discorso della CPU.....uno cerca di ottenere il massimo da quello che ha.

Of course!! In programmi complessi un tempo ciclo per il Runtime PLC entro i 200 ms sarebbero piu' che accettabili..

P.D.: Penso la discussione sarebbe gia' andata OT da un bel po'...se si vorrebbe continuare a parlare appunto di tempo ciclo allora ne suggerirei di aprire una apposta!

[Luca Bab]

Nello stato dell'unita' ciclo di clock , ti appare una finestra con tre valori, min, max e attuale del tempo ciclo.

Questo non e' il modo piu' corretto , poiche' cosi' hai hanche il tempo che la cpu riserva per la comunicazione con il PC

Adesso non facciamo tutti i santi,

Assolutamente , e' solo per conoscere realta' diverse

indicizzazione delle variabili, ricette, puntatori calcoli in virgola mobile, gestione schede conteggio veloce, gestione CP di comunicazione, ed ammennicoli vari ....ed un programma di oltre 64k, che il cliente "a capitolato!!" ti chiede che sia il piu' possibile in LADDER e' facile arrivare a tempi di scansione pesantucci

Sono tutte cose abbastanza standard anche nelle macchine che faccio io

15ms?

Se registro un tempo cosi' vado a vedere se mi sono dimenticato di caricare tutto il programma

io invece comincio a guardare cosa posso fare per farlo abbassare .

Penso la discussione sarebbe gia' andata OT da un bel po'...se si vorrebbe continuare a parlare appunto di tempo ciclo allora ne suggerirei di aprire una apposta!

sicuramente OT , sicuramente interessante ( almeno per me ) sono favorevole a continuarla

Ciao

Luca

[kamikaze]

In programmi complessi un tempo ciclo per il Runtime PLC entro i 200 ms sarebbero piu' che accettabili..

Grazie Savino......

Pensavo quasi di cambiare lavoro......

Ivan

[Luca Bab]

Pensavo quasi di cambiare lavoro

NO , kamikaze non cambiare lavoro

ovviamente sia Io che Ekup abbiamo esigenze diverse

penso che sarebbe interessante anche dare dei dati , del tipo ( reale ) :

314C-2DP

2 x 32 IN dig

2 X 32 OUT dig

FM 352

CP 340

4 et200s ( 200 IN 120 OUT 2 SSI )

4 611 in 2DP

40k di programma / 16K di dati

SCANSIONE = 8ms MAX 11ms

Ciao

Luca

[Ecup]

>se ben ricordo c'è un bit di stato che mi dice che il MOBY è pronto; a quel punto,

>quando ne ho la necessità, lancio il comando (lettura e scrittura che sia)

Tutto giusto, ma non mi bastava.

Non posso entrare nel merito, perché non conosco l'impianto in questione, ma onestamente non capisco perché non dovrebbe bastarti: se è pronto lancio il comando, se non è pronto sono già in allarme, senza lanciare task di verifica che mi portano il tempo ciclo a 200ms...

>senza aspettare in un loop che il MOBY mi risponda... quando mi risponderà agirò

>di conseguenza

A quel punto era troppo tardi, potevo anche aver sbagliato l'interpretazione del codice.

Ribadisco: non posso entrare nel merito del tuo caso particolare, ma se non mi risponde, non vedo come potrei interpretare in maniera errata una risposta che ancora non ho ricevuto... "sbagliare l'interpretazione del codice" cosa significa? Il programma che hai scritto dovrebbe avere delle memorie che indicano che hai inviato un comando, e attendere una risposta prima di interpretare qualsiasi cosa: se la risposta non arriva->allarme, ma non vado certo ad interpretare dei dati se non sono certo di aver ricevuto una risposta ad un mio preciso comando. Non posso permettermi di "interpretare il codice" liberamente: devo avere informazioni precise sullo stato della mia macchina/impianto in ogni istante, e anche dei comandi che ho impartito.

Dovevo , lanciare il job, attendere lo stato di job in corso -->fine job, prelevare il valore della DB , aggiornare il puntatori delle arre di memoria , recuperare tutte le informazioni sul prodotto, generare i dati per il file di stampa che veniva inviato via MPI al PC di area , e poi indirizzare il pezzo alla posizione esatta di stoccaggio, con certezza del 100%.

Questo lo faccio anch'io abitualmente (non solo col MOBY), ma per fare questo mica bisogna mettere il PLC in loop per 200ms. Una volta che hai memorizzato il fatto che hai impartito il comando, sai già che non dovrai prelevare i dati finché il MOBY non ti risponde... perché attendere in un loop...?

Non è che il tempo ciclo già lungo di suo (cioé intorno ai 100ms escludendo questi task) ti causava qualche problema nell'interpretazione delle risposte del MOBY? Se così fosse il problema stava a monte, e tu non l'hai risolto ma solo aggirato (in maniere, IMHO, errata)...

PS: sto sparando a ruota libera visto che non conosco i dettagli dell'impianto; l'unico dato certo è che quel tempo ciclo, per come la vedo io, e per le macchine che faccio di solito, sarebbe abissale...

Purtroppo da prove fatte inizialmente con una gestione semplice non avevo questa garanzia , forse 18 nodi profibus solo per i Moby erano vermente troppi (anche questo motivo per cui ero preparato a sostituire la CPU da 315 a 317).

CVD: se il il tempo ciclo è troppo alto, o c'è qualcosa che non torna nella programmazione, o la scelta della CPU è errata. Con 18 MOBY e molti dati da muovere, probabilmente avrei scelto direttamente la 317. Con una 317 ho fatto il controllo di un impianto abbastanza complesso, su quale non vorrei scendere in dettaglio... ti dico solo che c'erano 20 "stazioni mobili" ognuna con una propria "ricetta" di funzionamento (lunga 500 byte), una DB di dati storici del ciclo in corso e una bufferizzata (lunghi altettanto), ognuna dotata di azionamenti collegati in profibus, e ognuna con schede particolari (non MOBY, ma altrettanto "pesanti" da gestire), controllate non con le funzioni Siemens, ma con funzioni mie scritte ad-hoc. Ovviamente tutto era indicizzato, e il tempo ciclo, se forse era sopra i 20ms, sicuramente non arrivava a 30ms e neanche ci si avvicinava troppo.

Adesso non facciamo tutti i santi, dry.gif

Se faccio un programma semplice semplice OK, ma se comincio a metterci , indicizzazione delle variabili, ricette, puntatori calcoli in virgola mobile, gestione schede conteggio veloce, gestione CP di comunicazione, ed ammennicoli vari ....ed un programma di oltre 64k, che il cliente "a capitolato!!" ti chiede che sia il piu' possibile in LADDER e' facile arrivare a tempi di scansione pesantucci.

Poi il discorso della CPU.....uno cerca di ottenere il massimo da quello che ha.

Il programma che ti dicevo sopra è lungo più del doppio (circa 140k, DB escluse) e fa largo uso di puntatori e indici (che tra l'altro, se usati bene, dovrebbero aiutare a ridurre il tempo ciclo, non ad aumentarlo: per esempio, invece di spostare i dati tra le DB, aggiorni gli indici). Se il programma è complesso, scelgo una CPU adeguata alla sua complessità, non aumento il valore di controllo sul limite del tempo ciclo.

C'è da dire che io non uso mai il ladder, solo AWL, e nei limiti del possibile (tempo/costi/difficoltà) cerco di evitare le funzioni Siemens per scriverne di mie, più snelle e veloci (metto solo quello che mi serve) e sulla quali ho maggiore controllo (l'ho fatta io... so come girano i dati all'interno...). I calcoli in virgola mobile li uso solo se necessario: nell'esempio di cui sopra erano usati solo per scalare i valori dei segnali analogici

Non credo che vi sia un premio "per il miglior ciclo di scansione". laugh.gif

Non stiamo facendo a gara a chi fa il tempo ciclo più corto: il discorso è che un tempo di scansione alto può causare non pochi problemi. Su molte delle macchine che faccio di solito ci sono sensori che quanto intervengono non è mica detto che stiano attivi per 200ms (e neanche per 100ms): non posso certo correre il rischio di non vederli... ci sono movimentazioni dove un ritardo di 200ms sarebbe un'esagerazione, perché se non taglio subito il comando quando vedo un sensore (tutto ridondato) il movimento va ben oltre quanto richiesto (e non stiamo parlando di controlli numerici, ma di comuni movimenti idraulici)... ci sono task cha aggiorno ogni secondo per memorizzare i dati sul supervisore, e altre task più rapide per visualizzare dati che agli operatori servono in tempo reale: non che 200ms di ritardo facciano una grande differenza, ma è un ritardo già avvertibile.

Se la tua macchina/impianto consente di avere tempi di ciclo così alti, capisco che usare una 315 invece di una 317 possa portare ad un risparmio, e capisco anche che dal punto di vista della programmazione ti puoi prendere più libertà senza cercare soluzioni estreme per risparmiare tempo... ma come concetto generale, secondo me è errato (a prescindere da quanto tu possa essere bravo).

ciao

[Luca Bab]

cerco di evitare le funzioni Siemens per scriverne di mie, più snelle e veloci (metto solo quello che mi serve) e sulla quali ho maggiore controllo (l'ho fatta io... so come girano i dati all'interno...).

Parole sante Ecup , approvo al 100% e faccio lo stesso

il discorso è che un tempo di scansione alto può causare non pochi problemi

quoto anche questo aggiungendo che i problemi maggiori ci sono in un tempo di scansione poco stabile

ciao

Luca

[Lorenzo (An)]

Vorrei sapere come si dovrebbero realizzare a regola d'arte le connessioni fra il cavo AT e gli elettrodi dei tubi fluorescenti a catodo freddo (quelli utilizzati per le insegne luminose al neon). Nel mio caso si tratta di una installazione al chiuso. Gli elettrodi presentano in uscita qualche cm di trefolo nudo.

[Paolo Cattani]

Le connessioni possono essere anche realizzate per semplice attorcigliamento dei fili... basta che le teste dei tubi (e quindi anche le connessioni) siano coperte dagli appositi cappucci elastici in silicone, che di solito vengono forniti dal piegatore.

Comunque, esistono prodotti appositi.

Rimane il fatto che comunque i neon devono esere segregati, e quindi è l'insegna che deve rispettare le norme, non il neon.

http://www.voltimum.it/catalog/fam/GII-/30...e-luminose.html

INSEGNE E TUBI LUMINOSI A SCARICA CON TENSIONE SUPERIORE A 1 kV

Sistema di alimentazione: TT, TN-S

Norme di riferimento:

CEI EN 50107-1 (CEI 34-86) "Installazioni di Insegne e di tubi luminosi a scarica funzionanti con tensione a vuoto superiore a 1000 V ed inferiore a 10000 V"

CEI EN 50107-2 (CEI) "Installazioni di Insegne e di tubi luminosi a scarica funzionanti con tensione a vuoto superiore a 1000 V ed inferiore a 10000 V - Dispositivi di protezione contro le correnti di dispersione e il circuito aperto" (di prossima pubblicazione)

CEI EN 50143 (CEI 20-54) "Cavi per installazioni di insegne e tubi a scarica luminosi con tensione a vuoto superiore a 1 kV ma non superiore a 10 kV"

CEI EN 61050 (CEI 34-39) "Trasformatori per lampade a scarica tubolari con tensione secondaria a vuoto superiore a 1000 V"

CEI EN 60598 (CEI 34-21) "Apparecchi di illuminazione"

CEI EN 61347-2-10 (CEI 34-101) "Unità di alimentazione di lampada

Parte 2-10: Prescrizioni particolari per invertitori e convertitori elettronici per funzionamento in alta frequenza di lampade tubolari a scarica a catodo freddo (tubi neon)"

CEI EN 60529 (CEI 70-1) “Gradi di protezione degli involucri (Codice IP)”

CEI 64-8 Impianti elettrici utilizzatori a tensione nominale non superiore a 1000 V in corrente alternata e a 1500 V in corrente continua”