Apertura Db S7 300

[puntalino]

curiosità

Esempio se ho 4 fc consecutivi e tutti utilizzano la medesima db

E giusto richiamarla all’inizio di ogni blocco o solo nel primo blocco cosi facendo si risparmiano risorse della cpu

[Savino]

Esempio se ho 4 fc consecutivi e tutti utilizzano la medesima db

Se ti riferisci ad una forma del genere:

OB1
      AUF   DB   120
      CALL  FC    40
      CALL  FC    41
      CALL  FC    42
      CALL  FC    43

FB 40/41/42/43
 L     ..
 T     DBW   20..22..24..

Funzionarebbe si' ..

cosi facendo si risparmiano risorse della cpu

Tempo ciclo.. dovrebbe!

[puntalino]

ciao savino

no io mi riferivo al seguente esempio

in fc 40 come prima istruzione

auf db1

e nei seguenti fc 41-42-43 non scrivo più

auf db1

dopo nel fc44 scrivo

auf db23

il tuo esempio non l’ho mai provato io di solito apro la db come prima istruzione nel blocco

domani provo il tuo esempio

[Savino]

Ciao puntalino,

..io mi riferivo al seguente esempio

in fc 40 come prima istruzione

auf db1

e nei seguenti fc 41-42-43 non scrivo più

auf db1..

In questo caso non funzionarebbe... e se in OB1 non hai aperto una DB, la CPU andrebbe in STOP.

La DB aperta dentro la FC permetterebbe un entry point di accesso locale e non globale.

[puntalino]

grazie savino mi hai chiarito le idee sempre molto preciso

[cliff]

e se interviene un ob diinterrupt (ob35 ad esempio) che si apre una db esternamente ???

bye

[kamikaze]

se interviene un ob diinterrupt (ob35 ad esempio)

Vale lo stesso discorso, aprire la DB all'inizio del blocco o prima che sia necessario accedervi per trasferire valori.

Sarebbe sempre un'accesso locale alla DB.

Ivan

[Luca Bab]

Aggiungo solo una precisazione per puntalino

L DB1.DBW0

e' uguale a

OPN DB1

L DBW0

Quindi se richiami le DBW con la DB all'inizio , e' molto bello poiche' puoi vedere il commento

ma riapri in continuazione la stessa DB

Ciao

Luca

[puntalino]

ciao luca ma riaprendo in continuazione la stessa db ho un allungamento del tempo di ciclo o mi sbaglio

[Ecup]

ciao luca ma riaprendo in continuazione la stessa db ho un allungamento del tempo di ciclo o mi sbaglio

Dici giusto, ma avresti il vantaggio di vedere il commento e quindi aumentare la leggibilità del codice.

In alternativa puoi aggiungere ad ogni riga i "//commenti"...

AUF DB 1

U DBX 0.1 //condizione 1

O DBX 0.3 //condizione 2

= DBX 1.0 //stato 1

...ma ti porta via tempo di scrittura (e ri-scrittura ogni volta che cambi o modifichi)

Cosa sia meglio fare dipende da tante cose: in passato usavo molto aprire la DB solo all'inizio, ma ora con le CPU più potenti per alcune parti del codice prediligo privilegiare la leggibilità (ammesso di non avere problemi di tempo ciclo).

Ovviamente se apri la DB solo all'inizio ricordati che se ti devi appoggiare ad un'altr DB, poi devi riaprire quella che ti serve:

//errato

AUF DB 1

U DBX 0.1 //condizione 1

O DBX 0.3 //condizione 2

= DB2.DBX 1.0 //stato 1

U DBX 0.2 // !!! sto usando la DB2, non la DB1 !!!

...

//corretto

AUF DB 1

U DBX 0.1 //condizione 1

O DBX 0.3 //condizione 2

= DB2.DBX 1.0 //stato 1

AUF DB 1 //riapro la DB1

U DBX 0.2 //sto usando la DB1

...

In alternativa puoi tenere aperte due DB

AUF DB 1

AUF DI 2

U DBX 0.1 //condizione 1; uso la DB1

O DBX 0.3 //condizione 2; uso la DB1

= DIX 1.0 //stato 1; uso la DB2

U DBX 0.2 //uso sempre la DB1

[Luca Bab]

ciao luca ma riaprendo in continuazione la stessa db ho un allungamento del tempo di ciclo o mi sbaglio

Come ti hanno gia' detto , SI . Ogni istruzione comporta un'aumento di tempo di scansione

AUF DB 1

U DBX 0.1 //condizione 1

O DBX 0.3 //condizione 2

= DBX 1.0 //stato 1

Se la scansione per te e' un problema , quello che vedi sopra evitalo , l'accesso ai bit di una dbw di una DB e' molto piu' pesante dell'accesso alle M.

In questo caso , preferisco un move della DBW in MW poi uso i relativi bit ( o viceversa ) .

ma ora con le CPU più potenti

Questo e' sacrosanto , ma preferisco sempre essere parsimonioso ,

con questo modo di pensare ci fanno comprare un PC nuovo ogni 2 anni.

Ciao

Luca

[Ecup]

Se la scansione per te e' un problema , quello che vedi sopra evitalo , l'accesso ai bit di una dbw di una DB e' molto piu' pesante dell'accesso alle M.

Certo, ma il numero di MW è limitato e in certe situazioni (nel mio caso quasi sempre) non bastano per fare tutto, o quantomeno non bastano per fare tutto dando una struttura sensata all'organizzaione dei dati... se poi hai l'abitudine (come ce l'ho io, ma anche molti altri) di usare parte delle M per "mappare" gli I/O, il numero di M disponibili si riduce ulteriormente. Tutto questo senza considerare il fatto che l'utilizzo di DB "strutturate" (magari con UDT ad-hoc) è una grossa potenzialità da sfruttare quando si ha a che fare con parti di impianto "ripetitive". Giusto per farti un esempio, una tipologia di impianto che faccio abbastanza di frequente presenta fino a 16 "moduli" di struttura simile, e visto che ci ho a che fare spesso, mi sono fatto una struttura di DB che contiene i dati di stato e di processo dell'intero modulo. Con le dovute scorte è una DB da 300 Byte: moltiplicala per 16 e scoprirai che non posso mettere tutto su M... inoltre ogni modulo ha anche una sua DB di ricetta e di storico (più corte). Inoltre l'aver strutturato i dati mi ha permesso di fare una FC di elaborazione che richiamo #n volte aprendo prima la DB interessata.

Questo e' sacrosanto , ma preferisco sempre essere parsimonioso

Una volta scelta la CPU, l'impanto è fatto con quella CPU e girerà sempre in quel modo... piccoli aggiustamenti o aggiornamenti non ne stravolgono il funzionamento (non è come installare Vista su un PC di 5 anni fa...). Basta fare le cose bene all'inizio compatibilmente con quello che si ha a disposizione: io preferisco fare le cose in maniera ordinata, dando un tempo ciclo ragionevole, ma assicurando *anche* una struttura dei dati che consenta di intervenire agevolmente per modifiche / aggiunte / aggiornamenti (senza dimenticare la comprensione del codice).

ciao

[Luca Bab]

Certo, ma il numero di MW è limitato e in certe situazioni (nel mio caso quasi sempre)

il mio era un cosiglio generico , ovviamente se non ti bastano le M sei quasi obbligato a fare cio' ( a volte ho visto usare le uscite non utilizzate )

di usare parte delle M per "mappare" gli I/O

Una volta lo facevo anch'io ma adesso mi trovo molto bene con il ricablaggio

Una volta scelta la CPU, l'impanto è fatto con quella CPU e girerà sempre in quel modo

se riesci a fare cio' , sei fortunato . Io invece parto in un modo e a ogni ripetizione c'e' qualcosa da aggiungere .

Mi ricordo che la stessa macchina ( con le stesse prestazioni ) girava in 10ms su una 103 , adesso devo installare una 313 o 314 . Prova a guardare la differenza di prestazioni tra un 313 e una 103 !!!!

ma assicurando *anche* una struttura dei dati che consenta di intervenire agevolmente per modifiche / aggiunte / aggiornamenti (senza dimenticare la comprensione del codice).

Concordo pienamente , ma non solo per altri , ma anche per me stesso dopo qualche anno.

Pero' devi anche concordare con me che nella ricerca e' piu' facile trovare la M10.0 piuttosto che il DB30.DBX20.1 ( a proposito tu come fai per cercarlo ??? )

Comunque non c'e' una regola assoluta , bisogna analizzare caso per caso , ed e' anche bello confrontarsi con altre persone che hanno esigenze diverse

Ciao

Luca

[Ecup]

Una volta lo facevo anch'io ma adesso mi trovo molto bene con il ricablaggio

Usare la mappatura mi consente di essere molto più flessibile in fase di simulazione (che faccio sempre con una CPU "vera", ma senza I/O), nonché in fase di debug e test; il discorso della simulazione vale soprattutto con PLC diversi dal Siemens.

se riesci a fare cio', sei fortunato. Io invece parto in un modo e a ogni ripetizione c'e' qualcosa da aggiungere. Mi ricordo che la stessa macchina ( con le stesse prestazioni ) girava in 10ms su una 103, adesso devo installare una 313 o 314

Un momento... la stessa macchina (o simile, parlando dal punto di vista fisco/meccanico), 10 anni fa era fatta con un CPU, oggi ha molte più funzioni e più controlli, e per mantenere un tempo ciclo ragionevole è fatta con una CPU più prestante... questo è ovvio... (al di là del fatto che la CPU di 10 anni fa non le trovi più). Ma su un impianto messo in funzione 5 anni fa, se devo fare un'aggiunta o una modifica, non cambio certo la CPU, a meno che non si tratti di un cambiamento drastico accordato col cliente (come dovrò fare tra due settimane). Ma in questo discorso il fatto di utilizzare DB piuttosto che M c'entra solo fino ad un certo punto.

Concordo pienamente, ma non solo per altri, ma anche per me stesso dopo qualche anno.

sicuramente... anzi, da un certo punto di vista (tutela del know-how) l'importante è che sia leggibile per me, o più in generale per la mia azienda o i miei collaboratori

Pero' devi anche concordare con me che nella ricerca e' piu' facile trovare la M10.0 piuttosto che il DB30.DBX20.1 ( a proposito tu come fai per cercarlo ??? )

Non vedo grosse differenze e li cerco nello stesso modo (con "vai al punto di applicazione..."). L'unica differenza è che l'M20.1 è definito univocamente (a parte gli eventuali utilizzi come MW20 e MB20), mentre il DBX20.1, se cercato senza specificare la DB, potrebbe comparire più volte perché magari è utilizzato sia come DB30.DBX20.1, sia come DB29.DBX20.1, sia come DBX20.1 senza specificare la DB.

Per questo è importante aver strutturato bene i dati e aver dato la giusta leggibilità al programma, anche a costo di sacrificare un po' di tempo ciclo: nell'esempio che ti facevo prima sono solitamente sotto i 10ms, ma se anche fossero 12ms o 15ms, il funzionamento dell'impianto non ne risentirebbe. Per altri impianti magari sarebbe diverso... come dici anche tu, non c'è una regola assoluta.

ciao

[puntalino]

La discussione sta diventando molto interressante

[Luca Bab]

Usare la mappatura mi consente di essere molto più flessibile in fase di simulazione (che faccio sempre con una CPU "vera", ma senza I/O), nonché in fase di debug e test

Da qui si capisce le necessita' diverse , nelle macchine che progetto e programmo , non riesco a fare nessuna simulazione , poiche' dovrei simulare un sensore che si accende durante una fase di un ciclo del motore dalla durata di 1 secondo ( e di questi movimenti ne ho una 20ina ), mi dovrei fare un programma che gira simulando gli ingressi .

E il simulatore ( che oramai hanno quasi tutti i PLC ) , non ti basta ?? Ti conviene investire tempo in simulazione piuttosto che prenderti un po’ di tempo sulla macchina ???

10 anni fa era fatta con un CPU, oggi ha molte più funzioni e più controlli, e per mantenere un tempo ciclo ragionevole è fatta con una CPU più prestante

certo , pero' fa le stesse cose ( nella mia relata' ovviamente ) che faceva 10 anni fa' , ovviamente con meno controlli e meno funzioni , ma la produzione ( che e' quello che conta ) era la stessa , tu non ti chiedi mai se e' la direzione giusta quella che stai seguendo ??? ( io si' )

Questo comunque era solo un discorso generale , poiche' non condivido l'idea di sprecare risorse se oggi ci sono , poiche' domani potresti averne bisogno .

Ma in questo discorso il fatto di utilizzare DB piuttosto che M c'entra solo fino ad un certo punto.

era sempre un discorso relativo al risparmio di risorse , forse sara' una mia fissazione , ma tu pensa che a volte mi leggo il SW che ho scritto ( quasi sempre in kop dove posso ) in awl per vedere dove faccio spreco di risorse , poi me lo modifico ( prova a fare un segmento in kop con un ingresso e 5 move di zero su 5 word diverse e tradurlo in awl)

mentre il DBX20.1, se cercato senza specificare la DB, potrebbe comparire più volte perché magari è utilizzato sia come DB30.DBX20.1, sia come DB29.DBX20.1, sia come DBX20.1 senza specificare la DB

appunto ........ , ogni tanto cerco la dbw0 e tu pensa che nei miei SW ci sono sino ad un centinaio di DB

come dici anche tu, non c'è una regola assoluta

e su questo siamo pienamente d'accordo.

Ciao

Luca

[Eddyn°1]

Ciao a tutti. Mi intrometto per dire la mia.

Da quanto ho capito, puntalino vuole avere un tempo ciclo miniore possibile.

Le considerazioni che sono state fatte fino ad ora sono:

-usando le “M” si risparmia tempo ciclo poiché non si deve aprire nessuna DB.

-nel caso si debbano usare le DB cercare di ripetere il minor numero di volte l’istruzione AUF DB.

La considerazione che faccio io è:

Prendiamo in considerazione un programma di medie dimensioni: 40000 byte.

Tale programma viene steso prima utilizzando principalmente memori “M”, poi lo stesso programma viene steso utilizzando solamente memorie contenute in DB.

La differenza di tempo ciclo tra i due programmi sarà di 3-8ms (provato personalmente), logicamente il tempo ciclo più lungo riguarda il programma steso utilizzando le DB.

A questo punto io vi chiedo:

Cosa mi può cambiare una differenza di tempo ciclo di 3-8ms, la risposta secondo me è NULLA. Poiché se la mia macchina ha bisogno di controlli che richiedono intervalli minori di 8 ms di sicuro prendo in considerazione l’utilizzo di interrupt a tempo o su evento.

Logicamente le mie considerazioni sono basate sull’utilizzo di “S7300”.

Infatti se parliamo di Omron il tempo ciclo di un “CJ” è in medi 10 volte inferiore a quello di un “S7300” (P.S.: con questo non voglio assolutamente dire che Omron e meglio di Siemens).

Vi sembra un modo sbagliato di pensare il mio?

[Luca Bab]

Da quanto ho capito, puntalino vuole avere un tempo ciclo miniore possibile.

Credo che non fosse il suo problema primario , ma siamo andati un po' OT per confrontare esperienze diverse e sembra che a puntalino interessi , quindi credo si possa continuare .

Prendiamo in considerazione un programma di medie dimensioni: 40000 byte

se sono solo di codice , comincia ad essere " medio-grandi "

Cosa mi può cambiare una differenza di tempo ciclo di 3-8ms, la risposta secondo me è NULLA. Poiché se la mia macchina ha bisogno di controlli che richiedono intervalli minori di 8 ms di sicuro prendo in considerazione l’utilizzo di interrupt a tempo o su evento

Stiamo parlando di differenza ??? o di tempo di scansione , perche' se e' scansione con cosa giri con una 319 ??? Gli interrupt non sono il massimo da gestire e ti servono ingressi dedicati

Comunque ti posso dire che da manuale siemens x 313/14/15

U M1.0 = 0,2 ( nanoS ) U dbx1.0 = 1,4

S m1.0 = 0,2 S DBX1.0 = 1,7

SETTE/OTTO volte tanto , quindi non so' come hai fatto a fare i conti ( e sono tempi senza contare OPN/AUF DB )

La differenza comunque potrebbe essere quella di vedere o no un sensore , di attivare o disattivare qualcosa con una tolleranza intollerabile .

Come avrai capito , ci sono esigenze diverse .

Non tirare fuori altri PLC , e' difficile fare dei confronti diretti ( poi ci sono tante leggende )

Ciao

Luca

[Eddyn°1]

Buon giorno.

SETTE/OTTO volte tanto , quindi non so' come hai fatto a fare i conti ( e sono tempi senza contare OPN/AUF DB )

Luca i miei non sono conti teorici, ma un'esperienza pratica. Ti spiego, parlo di esperienza pratica perchè sto converterndo i miei programmi stesi usando memorie M per i cicli

Ti spiego:

Fino a poco tempo fa per la transizione delle fasi del ciclo macchina utilizzavo le memorie "M" ora sto converterndo tutti i programmi in modo da avere una DB per ogni ciclo macchina, in questo modo sono più flessibile se devo aggiungere o togliere pezzi di macchina.

La differenza comunque potrebbe essere quella di vedere o no un sensore , di attivare o disattivare qualcosa con una tolleranza intollerabile .

Ti ripeto Luca, se ti serve una precisione inferiore di quei 3-8 ,supponiamo anche, 10 ms io non mi fiderei lo stesso del tempo ciclo di un "S7300" (sopratutto dalla 314 in giù) e userei un interrupt.

Come avrai capito , ci sono esigenze diverse .

Lo so bene, infatti se il tuo sistema richiede un tempo ciclo minore di 8ms, e devi scrivere un bel po di codice, io prendere in considerazioni altre CPU e non una 313-314.

Non tirare fuori altri PLC , e' difficile fare dei confronti diretti ( poi ci sono tante leggende )

Non volevo "tirare fuori altri PLC" era solo per far capire che il mio discorso era relazionato ad una CPU314 della serie S7300.

Non so cosa intendi per "leggenda", poichè un qualsiasi programmatore che ha usato entrambi i PLC ti può confermare quanto ho affermato.

Ciao, Buon fine settimana.

[kamikaze]

Ciao Luca,

Comunque ti posso dire che da manuale siemens x 313/14/15

U M1.0 = 0,2 ( nanoS ) U dbx1.0 = 1,4

S m1.0 = 0,2 S DBX1.0 = 1,7

SETTE/OTTO volte tanto , quindi non so' come hai fatto a fare i conti ( e sono tempi senza contare OPN/AUF DB )

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

Dai post precedenti, ho dedotto che tu sei un ottimo programmatore anche perche' molto scrupoloso , soprattutto nei tempi ciclo.

Io sono piu' pratico.

Valuto l'incidenza del tempo ciclo solo se l'applicazione lo richiede.

Esempio:

Impianto di trasporto interno fabbrica, un disastro di rulliere, deviatori, elevatori.

Precisione richiesta di arresto dei colli nessuna , o almeno nel limite della decenza.

Allora non mi sono curato piu' di tanto del ciclo di scansione, mi ricordo era intorno ai 195 ms, per via del tracking,che vergogna.

Quello che piu' mi interessava era la leggibilita' del codice , e il volume del programma , siccome i trasportatori erano molti ma molto simili tra loro ho usato un sacco di FB parametrizzati.

Impianto di paletizzazione, almeno 255 prodotti diversi , riconoscimento codice a barre dal nastro trasportatore e 6 baie di deposito , e stampa etichetta pallet a completamento lotto.

Quasi l'80% del programma era indicizzazione dati delle DB per i prodotti (tipo, dimensioneXYZ,peso,collocazione, N.strati ecc.)

Usai una 317 , ma in ogni caso il tempo ciclo max restava nell'ordine dei 230ms , inaccettabile in quanto il posizionamento richiesto del manipolatore a tre assi era di una precisione di 2mm!!!!

Allora sono ricorso al sistema che ritengo meno professionale in quanto riduce drasticamente la leggibilita' del codice.

Dopo il job di riconoscimento prodotto, calcolo della destinazione, e prelievo, settavo un bel flag di "short loop" che abbinato a dei Jump condizionati qua e la', mi faceva saltare il 90% del codice durante il posizionamento , riducendo il tempo ciclo a 65ms.

Vedi che alla fine anche senza calcoli complessi il risultato lo raggiungi?.

Ivan

[Savino]

QUOTE

..io mi riferivo al seguente esempio

in fc 40 come prima istruzione

auf db1

e nei seguenti fc 41-42-43 non scrivo più

auf db1..

In questo caso non funzionarebbe... e se in OB1 non hai aperto una DB, la CPU andrebbe in STOP.

La DB aperta dentro la FC permetterebbe un entry point di accesso locale e non globale.

Dunque, ripeto.. La DB aperta dentro la FC permetterebbe un entry point di accesso locale e non globale ..per questo , in ogni caso e per buona regola, sempre meglio fare un auf dbx.. all'interno di un blocco sub per mantenere la portabilita' independente della suddetta funzione.. comunque.. Modificato: 4 agosto 2007 da Savino

[batta]

Dunque, ripeto.. La DB aperta dentro la FC permetterebbe un entry point di accesso locale e non globale ..per questo , in ogni caso e per buona regola, sempre meglio fare un auf dbx.. all'interno di un blocco sub per mantenere la portabilita' independente della suddetta funzione.. comunque..

Savino, come sempre dimostri che per te Siemens non ha segreti

Al fatto puramente tecnico io aggiungerei anche che, se proprio si vuole aprire il DB all'inteno della FC, aprire il DB alcune volte anziché una sola influisce sulla scansione in modo insignificante, mentre il programma guadagna molto in leggibilità.

Personalmente ritengo che programmi tipo

AUF DBn

U DBX.y

= DBX.z

stile S5, per dire, siano illeggibili ed il cross reference diventa praticamente impossibile. E' il motivo principale per cui io ho sempre odiato gli S5.

Certo, scrivere

U DBn.DBX.y

= DBn.DBX.z

fa perdere tempo alla cpu ma, se l'allungamento del tempo di scansione diventa inaccettabile, si può aggirare l'ostacolo appoggiando i dati del DB a variabili TEMP all'inizio della FC, lavorare con i dati TEMP (che così avranno un nome e il programma diventa comprensibile), scrivere i dati nel DB prima di uscire dalla FC.

Le aperture di DB restano limitate ed il tempo di scansione praticamente non ne risente.

[Savino]

Savino, come sempre dimostri che per te Siemens non ha segreti

batta..Bentornato !! ... ti ringrazio!. ma anche te non scherzi mica sai

saluto.

[Ecup]

>>Usare la mappatura mi consente di essere molto più flessibile in fase di simulazione

>>(che faccio sempre con una CPU "vera", ma senza I/O), nonché in fase di debug e test

>

>Da qui si capisce le necessita' diverse , nelle macchine che progetto e programmo , non riesco

>a fare nessuna simulazione , poiche' dovrei simulare un sensore che si accende durante una fase

>di un ciclo del motore dalla durata di 1 secondo ( e di questi movimenti ne ho una 20ina ), mi dovrei fare un programma

>che gira simulando gli ingressi .

E' esattamente quello che faccio io... altrimenti che simulaziuone sarebbe?

> E il simulatore ( che oramai hanno quasi tutti i PLC ) , non ti basta ??

No... usando una CPU vera ci collego anche il supervisore, invio "ricette", eseguo cicli automatici di funzionamento, verifico come girano i dati, controllo il meccanismo di acquisizione degli storici, ecc... ecc... (ovviamente non vale per tutti gli impianti). Il simulatore è utile per verificare piccoli cicli o sequenze di alcune parti, ma non per una simulazione "completa"

> Ti conviene investire tempo in simulazione piuttosto che prenderti un po’ di tempo sulla macchina ???

Nel corso degli anni ho accertato che una simulazione fatta in questo modo mi permette di risparimare diverso tempo in campo durante lo startup. Ovviamente devi conoscre bene anche la macchina

>>10 anni fa era fatta con un CPU, oggi ha molte più funzioni e più controlli, e per mantenere un tempo

>>ciclo ragionevole è fatta con una CPU più prestante

>

>certo , pero' fa le stesse cose ( nella mia relata' ovviamente ) che faceva 10 anni fa' ,

Ho detto "molte più funzioni"...

>ovviamente con meno controlli e meno funzioni , ma la produzione ( che e' quello che conta ) era la stessa

Nel mio caso le "molte più funzioni" consentono di ottenere una produzione superiore, ma soprattutto con una continuità qualitativa e una ripetitività dei risultati nettamente superiore.

> tu non ti chiedi mai se e' la direzione giusta quella che stai seguendo ???

certo, e spesso cambio anche rotta

> Questo comunque era solo un discorso generale , poiche' non condivido l'idea di sprecare risorse se oggi ci sono ,

> poiche' domani potresti averne bisogno .

e dove starebbe lo spreco?

>>Ma in questo discorso il fatto di utilizzare DB piuttosto che M c'entra solo fino ad un certo punto.

>

>era sempre un discorso relativo al risparmio di risorse

Il riparmio di risorse non è tutto, e comunque, ribadisco, non sempre è possibile fare tutto con le M... nel mio caso quasi mai.

In ogni caso il risparmio di risorse si può fare anche in molti altri modi

> forse sara' una mia fissazione , ma tu pensa che a volte mi leggo il SW che ho scritto

> ( quasi sempre in kop dove posso ) in awl per vedere dove faccio spreco di risorse , poi me lo modifico

> ( prova a fare un segmento in kop con un ingresso e 5 move di zero su 5 word diverse e tradurlo in awl)

programmo solo in AWL: anche questo è un metodo per risparmiare risorse

> ogni tanto cerco la dbw0 e tu pensa che nei miei SW ci sono sino ad un centinaio di DB

dipende da come hai programmato: se sai di percerto di poter cercare una DBxx.DBWyy, puoi benissimo specificare la DBxx nella finestra di "Vai al punto di applicazione..." (altro motivo per privilegiare la scrittura estesa, dove serve, anche se si sacrifica del tempo ciclo). Se non puoi specificarlo puoi comunque avere un'idea di "dove" cercare quello che ti serve. Anch'io ho centinaia di DB, ma non ho mai avuto problemi a cercare quello che mi serve

ciao

[Ecup]

Esempio:

Impianto di trasporto interno fabbrica, un disastro di rulliere, deviatori, elevatori.

Precisione richiesta di arresto dei colli nessuna , o almeno nel limite della decenza.

Allora non mi sono curato piu' di tanto del ciclo di scansione, mi ricordo era intorno ai 195 ms, per via del tracking,che vergogna.

195 ms???

Personalmente non accetterei mai un tempo ciclo del genere, per quanto poco critica sia l'applicazione. Mediamente sto abbondantemente sotto i 20ms, se arrivo intorno ai 30ms prendo in considerazione l'idea di aver sbagliato CPU, se supero i 50ms cambio la CPU (successo una sola volta)

Quello che piu' mi interessava era la leggibilita' del codice , e il volume del programma , siccome i trasportatori erano molti ma molto simili tra loro ho usato un sacco di FB parametrizzati.

Capisco, lo faccio spesso anch'io, ma non arrivo mai a tempi così alti

PS: anch'io ho spesso a che fare con tracking dei dati, Barcode, RFID e simili...

ciao