Microwin ed s7200 - 224

[suibaf]

Cari amici. Mi sono procurato microwin 32 versione 2.0. Aprendola ho notato che non supporta le nuove cpu 22x, ma stamattina per provare ho programmato una 224 che avevo in magazzino. Il software la riconosce come una 214. Ho messo giù qualche istruzione per provare e mi sembra che funzioni. Secondo voi ci può essere qualche problema?qualche malfunzionamento?Qualcuno ha qualche esperienza?

Grazie

[suibaf]

Cari amici. Mi sono procurato microwin 32 versione 2.0. Aprendola ho notato che non supporta le nuove cpu 22x, ma stamattina per provare ho programmato una 224 che avevo in magazzino. Il software la riconosce come una 214. Ho messo giù qualche istruzione per provare e mi sembra che funzioni. Secondo voi ci può essere qualche problema?qualche malfunzionamento?Qualcuno ha qualche esperienza?

Grazie

[Livio Orsini]

Come ti ho scritto la tua versione non "vede" la serie S7-22x, si deve usara la versione 3.2x.

Se ti accontenti e non ti preoccupi di alcune limitazioni, puoi usare la tua versione di microwin.

Nel 1999, quando uscirono le prime CPU 22x, non avendo ancora la nuova versione di microwin, feci un paio di macchine con S7-224 senza problemi.

[Livio Orsini]

Come ti ho scritto la tua versione non "vede" la serie S7-22x, si deve usara la versione 3.2x.

Se ti accontenti e non ti preoccupi di alcune limitazioni, puoi usare la tua versione di microwin.

Nel 1999, quando uscirono le prime CPU 22x, non avendo ancora la nuova versione di microwin, feci un paio di macchine con S7-224 senza problemi.

[suibaf]

Grazie Livio

[suibaf]

Grazie Livio

[Eddyn°1]

Ciao a tutti!

La ditta dove lavoro costruisce molte macchine, le quali possono avere diverse varianti (presenza o meno di parti di macchina), da un po di tempo, quando ho un'oretta libera, sto cercando un modo per standardizzare tutti i pezzi di codice. L'idea che avevo in partenza, era questa:

Vi faccio un esempio:

La macchina può essere composta da vari dispositivi (possono essere anche complicati e richiedere un bel pezzo di codice): A, B, C, D, E, F, G

Per la gestione del dispositivo A:

Pezzo di codice: FC A

Variabili necessarie: DB A

Per la gestione del dispositivo B:

Pezzo di codice: FC B

Variabili necessarie: DB B

Per la gestione del dispositivo C:

Pezzo di codice: FC C

Variabili necessarie: DB C

ecc..

Quando vengono richiamati gli FC si dovranno impostare:

Variabili IN: Associare gli ingressi del programma

Variabili OUT: Associare le uscite del programma

Variabili INOUT: Associare le memorie di scambio tra i vari cicli-dispositivi

Premetto che tutte le variabili (BOOL,WORD,DWORD ecc.) le avevo messe in DB, anche i Timer me li ero creati io con un FC richiamato tante volte quanti i timer.

In questo modo, pensavo, "mi creo una biblioteca contenente la gestione del dispositivo A, del dispositivo B ecc.. Quando il dispositivo A c'è, mi prendo dalla biblioteca FC A e DB A, quando il dispositivo A non c'è, tolgo FC A e DB A.

In questo modo tutte le memorie del resto del programma non vengono toccate, in quanto non vengono utilizzati ne memorie "M" ne "Timer". Questo lo trovavo molto utile perchè quando si aggiunge un pezzo di codice standard, il 90% delle volte usa memorie "M" e "T" gia usati in giro per il programma.

L'idea mi sembrava buona ed ho iniziato a buttare giù un po di codice, quando mi sono scontrato con i limiti delle CPU 313 e 314 che noi usiamo per la maggiore.

Per limiti intendo: Poca memoria (in effetti ci sono un po di DB lunghe) e tempi ciclo che arrivavano anche a 35 ms.

Ho fatto un passo in dietro e ho snellito le DB lasciandoci dentro solo i "dati macchina" necessari per il funzionamento del dispositovo e le variabili WORD e DWORD utilizzate per calcoli, utilizzando le "M" per le variabili bool e i "T" per i timer, cercando di dedicare pezzi di memoria continui per ogni dispositivo (es.: dispositivo A = MB100 --> MB119; T50 --> T59)

In questo modo la cosa è migliorata, ma a questo punto mi sono accorto che richiamare, per esempio, 10 FC passandogli un ventina di variabili impegna in modo considerevole la CPU (10ms).

Sapevo che le 313-314 non erano grosse CPU ma limitate fino a questo punto........

Il punto forte della siemens (punto forte perchè c'è arrivata prima degli altri) sono le FC e FB parametrizzabili, ma se questi si possono utilizzare (in maniera pesante) solo su 317 e 400 allora mi cade un po il palco!!!

Vi ho scritto questa esperienza per sapere se altre persone hanno incontrato la mia stessa esigenza e come si sono comportati.

Tutte le esperienza e consigli sono utili....

Per finire, se mi permettete, direi che siemens mi stà un po deludendo, per questo e per altre caz.... che sta facendo..... (lo dice una persona che lavora di frequente anche con altre marche, e quindi può comparare i vari prodotti).....

Siemens sei ferma!!!!! (Opinione strettamente personale)

[Eddyn°1]

Ciao a tutti!

La ditta dove lavoro costruisce molte macchine, le quali possono avere diverse varianti (presenza o meno di parti di macchina), da un po di tempo, quando ho un'oretta libera, sto cercando un modo per standardizzare tutti i pezzi di codice. L'idea che avevo in partenza, era questa:

Vi faccio un esempio:

La macchina può essere composta da vari dispositivi (possono essere anche complicati e richiedere un bel pezzo di codice): A, B, C, D, E, F, G

Per la gestione del dispositivo A:

Pezzo di codice: FC A

Variabili necessarie: DB A

Per la gestione del dispositivo B:

Pezzo di codice: FC B

Variabili necessarie: DB B

Per la gestione del dispositivo C:

Pezzo di codice: FC C

Variabili necessarie: DB C

ecc..

Quando vengono richiamati gli FC si dovranno impostare:

Variabili IN: Associare gli ingressi del programma

Variabili OUT: Associare le uscite del programma

Variabili INOUT: Associare le memorie di scambio tra i vari cicli-dispositivi

Premetto che tutte le variabili (BOOL,WORD,DWORD ecc.) le avevo messe in DB, anche i Timer me li ero creati io con un FC richiamato tante volte quanti i timer.

In questo modo, pensavo, "mi creo una biblioteca contenente la gestione del dispositivo A, del dispositivo B ecc.. Quando il dispositivo A c'è, mi prendo dalla biblioteca FC A e DB A, quando il dispositivo A non c'è, tolgo FC A e DB A.

In questo modo tutte le memorie del resto del programma non vengono toccate, in quanto non vengono utilizzati ne memorie "M" ne "Timer". Questo lo trovavo molto utile perchè quando si aggiunge un pezzo di codice standard, il 90% delle volte usa memorie "M" e "T" gia usati in giro per il programma.

L'idea mi sembrava buona ed ho iniziato a buttare giù un po di codice, quando mi sono scontrato con i limiti delle CPU 313 e 314 che noi usiamo per la maggiore.

Per limiti intendo: Poca memoria (in effetti ci sono un po di DB lunghe) e tempi ciclo che arrivavano anche a 35 ms.

Ho fatto un passo in dietro e ho snellito le DB lasciandoci dentro solo i "dati macchina" necessari per il funzionamento del dispositovo e le variabili WORD e DWORD utilizzate per calcoli, utilizzando le "M" per le variabili bool e i "T" per i timer, cercando di dedicare pezzi di memoria continui per ogni dispositivo (es.: dispositivo A = MB100 --> MB119; T50 --> T59)

In questo modo la cosa è migliorata, ma a questo punto mi sono accorto che richiamare, per esempio, 10 FC passandogli un ventina di variabili impegna in modo considerevole la CPU (10ms).

Sapevo che le 313-314 non erano grosse CPU ma limitate fino a questo punto........

Il punto forte della siemens (punto forte perchè c'è arrivata prima degli altri) sono le FC e FB parametrizzabili, ma se questi si possono utilizzare (in maniera pesante) solo su 317 e 400 allora mi cade un po il palco!!!

Vi ho scritto questa esperienza per sapere se altre persone hanno incontrato la mia stessa esigenza e come si sono comportati.

Tutte le esperienza e consigli sono utili....

Per finire, se mi permettete, direi che siemens mi stà un po deludendo, per questo e per altre caz.... che sta facendo..... (lo dice una persona che lavora di frequente anche con altre marche, e quindi può comparare i vari prodotti).....

Siemens sei ferma!!!!! (Opinione strettamente personale)

[pigroplc]

In tutte le marche ci sono pro e contro, Siemens compresa.

Certo è che non ci credo che gli altri siano tanto più avanti (anche io uso altri costruttori...).

Se vuoi ridurre il numero di parametri nelle FB-FC perchè portano via tanto tempo prova a indicizzare in modo mascherato il blocco,

cioè usi delle FB con i loro DB di istanza, e prima di lanciarle aggiorna i dati statici, quindi appartenenti alle DB di istanza, tutto questo senza usare parametri:

esempio

.

.

.

L 100

T DB100.DBW0

ecc

CALL FB100, DB100

.

.

.

ovviamente la DB 100 è mappata secondo le tue necessità e nella FB carichi il parametro corrispondente alla word 0 per i tuoi utilizzi.

prrrrrovaaaaa

pigroplc

[pigroplc]

In tutte le marche ci sono pro e contro, Siemens compresa.

Certo è che non ci credo che gli altri siano tanto più avanti (anche io uso altri costruttori...).

Se vuoi ridurre il numero di parametri nelle FB-FC perchè portano via tanto tempo prova a indicizzare in modo mascherato il blocco,

cioè usi delle FB con i loro DB di istanza, e prima di lanciarle aggiorna i dati statici, quindi appartenenti alle DB di istanza, tutto questo senza usare parametri:

esempio

.

.

.

L 100

T DB100.DBW0

ecc

CALL FB100, DB100

.

.

.

ovviamente la DB 100 è mappata secondo le tue necessità e nella FB carichi il parametro corrispondente alla word 0 per i tuoi utilizzi.

prrrrrovaaaaa

pigroplc

[mubeta]

E' difficile fare una valutazione del problema che esponi e dare una soluzione.

Come hai già fatto tu, la strada da intraprendere è l'analisi del problema e l'ottimizzazione del codice anche per le CPU più piccole.

Io non amo gli FB usati con DB di istanza, quindi in tal senso da me non avrai suggerimenti.

Ad una FC puoi passare tutte le variabili supportate dal linguaggio, anche dei Timer ad esempio. All'interno della funzione, il timer avrò un nome simbolico, all'esterno lo colleghi al T che ti interessa. Visto che la CPU spende un poco do tempo per fare girare il "sistema operativo", tanto vale utilizzare le sue risorse, tra cui i timer.

Non so come usi le DB, ma queste sono particolarmente pesanti per il tempo ciclo: se nella tua FC hai dichiarato tutte le variabili come singole variabili, e nei punti di richiamo scrivi sempre "DBn.D...." per forza che il ciclo è pesante. Qui puoi migliorare molto utilizzando delle strutture dati, (una area di memoria contigua), ed invece di passare alla FC tutte le singole variabili, passi un'array della struttura, o qualcosa del genere, che potrai, a piacimento, copiare poi nella memoria Locale, se hai strutture non troppo grandi, o usare come variabile IN_OUT.

Cercherò di fare un'esempio:

crei una struttura dati comune alle varie utenze A, B, C, ... (se è fattibile), altrimenti strutture diverse a seconda dei casi;

crei una o più DB, con degli array per N strutture necessarie.

crei delle FC che hanno come variabile di ingresso una variabile IN_OUT del tipo struttura che ti interessa, o un puntatore any alla stessa struttura.

In questo modo quando la FC viene richiamata, invece di dover copiare n variabili di interfaccia, con la continua apertura della DB indicata, se deve aprire una unica volta la DB e si copia tutti i dati in unica soluzione.

Non conosco le tue macchine, ma su CPU 313 ho scritto programmi per una quarantina di utenze e, fatto in questo modo, di spazio ne avanzava (32 kB di RAM) ed era abbastanza performate. (Comunque sull'ordine dei 25 ms, nel mio caso sufficienti).

[mubeta]

E' difficile fare una valutazione del problema che esponi e dare una soluzione.

Come hai già fatto tu, la strada da intraprendere è l'analisi del problema e l'ottimizzazione del codice anche per le CPU più piccole.

Io non amo gli FB usati con DB di istanza, quindi in tal senso da me non avrai suggerimenti.

Ad una FC puoi passare tutte le variabili supportate dal linguaggio, anche dei Timer ad esempio. All'interno della funzione, il timer avrò un nome simbolico, all'esterno lo colleghi al T che ti interessa. Visto che la CPU spende un poco do tempo per fare girare il "sistema operativo", tanto vale utilizzare le sue risorse, tra cui i timer.

Non so come usi le DB, ma queste sono particolarmente pesanti per il tempo ciclo: se nella tua FC hai dichiarato tutte le variabili come singole variabili, e nei punti di richiamo scrivi sempre "DBn.D...." per forza che il ciclo è pesante. Qui puoi migliorare molto utilizzando delle strutture dati, (una area di memoria contigua), ed invece di passare alla FC tutte le singole variabili, passi un'array della struttura, o qualcosa del genere, che potrai, a piacimento, copiare poi nella memoria Locale, se hai strutture non troppo grandi, o usare come variabile IN_OUT.

Cercherò di fare un'esempio:

crei una struttura dati comune alle varie utenze A, B, C, ... (se è fattibile), altrimenti strutture diverse a seconda dei casi;

crei una o più DB, con degli array per N strutture necessarie.

crei delle FC che hanno come variabile di ingresso una variabile IN_OUT del tipo struttura che ti interessa, o un puntatore any alla stessa struttura.

In questo modo quando la FC viene richiamata, invece di dover copiare n variabili di interfaccia, con la continua apertura della DB indicata, se deve aprire una unica volta la DB e si copia tutti i dati in unica soluzione.

Non conosco le tue macchine, ma su CPU 313 ho scritto programmi per una quarantina di utenze e, fatto in questo modo, di spazio ne avanzava (32 kB di RAM) ed era abbastanza performate. (Comunque sull'ordine dei 25 ms, nel mio caso sufficienti).

[Eddyn°1]

In tutte le marche ci sono pro e contro, Siemens compresa.

Certo è che non ci credo che gli altri siano tanto più avanti (anche io uso altri costruttori...).

Certo, ogni costruttore ha i suoi pro e contro, ma dalle mie ultime esperienze, ritengo che siemens stia tirando avanti grazie al nome "Siemens" che nel passato era una sicurezza!! Lo dimostra anche il calo delle vendite!!

Sottolineo che queste lamentele sono fatte da una persona (io) che ha sempre avuto un debole per Siemens in quanto ho iniziato a programmare siemens in AWL (quindi un siemens dipendente).

Tornano al mio problema

Ho preso in considerazione anche il fatto di utilizzare FB con relative DB di istanza, ma le trovo poco elastiche per eventuali modifiche.

Ho preso anche in considerazione l'ipotesi di mascherare i dati da passare all'FC e passarli in un solo colpo utilizzando poi all'interno dell'FC le variabili mascherate. Il problema di questa soluzione è la difficoltà di fare un riferimento incrociato della memoria. Dovete pensare che io devo considerare il fatto che i programmi devono essere chiari e di semplice debug per tutti i tecnici che collaudano e vanno a montare le macchine, i quali hanno un'infarinatura solo generale sulla programazione.

Non conosco le tue macchine, ma su CPU 313 ho scritto programmi per una quarantina di utenze e, fatto in questo modo, di spazio ne avanzava (32 kB di RAM) ed era abbastanza performate. (Comunque sull'ordine dei 25 ms, nel mio caso sufficienti).

[Eddyn°1]

In tutte le marche ci sono pro e contro, Siemens compresa.

Certo è che non ci credo che gli altri siano tanto più avanti (anche io uso altri costruttori...).

Certo, ogni costruttore ha i suoi pro e contro, ma dalle mie ultime esperienze, ritengo che siemens stia tirando avanti grazie al nome "Siemens" che nel passato era una sicurezza!! Lo dimostra anche il calo delle vendite!!

Sottolineo che queste lamentele sono fatte da una persona (io) che ha sempre avuto un debole per Siemens in quanto ho iniziato a programmare siemens in AWL (quindi un siemens dipendente).

Tornano al mio problema

Ho preso in considerazione anche il fatto di utilizzare FB con relative DB di istanza, ma le trovo poco elastiche per eventuali modifiche.

Ho preso anche in considerazione l'ipotesi di mascherare i dati da passare all'FC e passarli in un solo colpo utilizzando poi all'interno dell'FC le variabili mascherate. Il problema di questa soluzione è la difficoltà di fare un riferimento incrociato della memoria. Dovete pensare che io devo considerare il fatto che i programmi devono essere chiari e di semplice debug per tutti i tecnici che collaudano e vanno a montare le macchine, i quali hanno un'infarinatura solo generale sulla programazione.

Non conosco le tue macchine, ma su CPU 313 ho scritto programmi per una quarantina di utenze e, fatto in questo modo, di spazio ne avanzava (32 kB di RAM) ed era abbastanza performate. (Comunque sull'ordine dei 25 ms, nel mio caso sufficienti).

[MarioS]

Ciao è difficile dare una risposta al tuo quesito senza conoscere bene i dettagli, ma sicuramente se il tuo problema è il tempo ciclo devi lavorare sull'ottimizzazione del programma.Personalmente da quando lavoro con CPU S7-300 non ho più avuto problemi di tempo ciclo visto che sono molto veloci certo che se il tuo programma richiama molti fc parametrizzati (credo anche quelli dei temporizzatori, come dicevi)il tempo ciclo inevitabilmente aumenta. Un trucchetto che io usavo sui PLC S5 era per esempio quello di richiamare alcune parti del programma (ovviamente quando è possibile farlo ) in maniera alternata (un ciclo si e un ciclo no )in modo da diminuire il tempo ciclo totale. Un esempio sono le fc standard di linearizzazione delle analogiche se non è necessario avere un aggiornamento ciclico (ad esempio temperature) e devi leggiere 4 valori, due li richiami in un ciclo e nel ciclo successivo puoi aggiornare le altre due.

Spero di averti dato alcuni indizi ciao......e buon lavoro.

[MarioS]

Ciao è difficile dare una risposta al tuo quesito senza conoscere bene i dettagli, ma sicuramente se il tuo problema è il tempo ciclo devi lavorare sull'ottimizzazione del programma.Personalmente da quando lavoro con CPU S7-300 non ho più avuto problemi di tempo ciclo visto che sono molto veloci certo che se il tuo programma richiama molti fc parametrizzati (credo anche quelli dei temporizzatori, come dicevi)il tempo ciclo inevitabilmente aumenta. Un trucchetto che io usavo sui PLC S5 era per esempio quello di richiamare alcune parti del programma (ovviamente quando è possibile farlo ) in maniera alternata (un ciclo si e un ciclo no )in modo da diminuire il tempo ciclo totale. Un esempio sono le fc standard di linearizzazione delle analogiche se non è necessario avere un aggiornamento ciclico (ad esempio temperature) e devi leggiere 4 valori, due li richiami in un ciclo e nel ciclo successivo puoi aggiornare le altre due.

Spero di averti dato alcuni indizi ciao......e buon lavoro.

[mubeta]

i programmi devono essere chiari e di semplice debug per tutti i tecnici che collaudano e vanno a montare le macchine, i quali hanno un'infarinatura solo generale sulla programazione.

Pur conoscendo e capendo cosa sta dietro alla affermazione, non è una ragione questa per fare "male" i programmi. Come hanno imparato a montare meccanicamente le macchine; come hanno imparato a fare i cablatori, collegare encoder, brushless e fotocellule, piuttosto che avviare dei robot, allora possono anche imparare, col dovuto training, a mettere le mani sui programmi delle macchine che montano. Per non dire che, se non sono programmatori "eecelsi", devono almeno essere programmatori, con tutto cosa ne consegue.

25 ms non è un tempo ciclo eccessivo, ma per dirti, altri costruttori (non voglio far nomi) con prodotti di prezzo uguale o inferiore con la stessa quantità di codice hanno un tempo ciclo 5-6 volte inferiore

Non so quali sono le tue esperienze, ma altri costruttori, TLM, Omron, semplicemente non ti danno le DB, ma aree di memoria ad indirizzamento assoluto. Un bel pacco di lavoro in meno per la CPU, indubbio.

Modificato: 18 giugno 2008 da mubeta

[mubeta]

i programmi devono essere chiari e di semplice debug per tutti i tecnici che collaudano e vanno a montare le macchine, i quali hanno un'infarinatura solo generale sulla programazione.

Pur conoscendo e capendo cosa sta dietro alla affermazione, non è una ragione questa per fare "male" i programmi. Come hanno imparato a montare meccanicamente le macchine; come hanno imparato a fare i cablatori, collegare encoder, brushless e fotocellule, piuttosto che avviare dei robot, allora possono anche imparare, col dovuto training, a mettere le mani sui programmi delle macchine che montano. Per non dire che, se non sono programmatori "eecelsi", devono almeno essere programmatori, con tutto cosa ne consegue.

25 ms non è un tempo ciclo eccessivo, ma per dirti, altri costruttori (non voglio far nomi) con prodotti di prezzo uguale o inferiore con la stessa quantità di codice hanno un tempo ciclo 5-6 volte inferiore

Non so quali sono le tue esperienze, ma altri costruttori, TLM, Omron, semplicemente non ti danno le DB, ma aree di memoria ad indirizzamento assoluto. Un bel pacco di lavoro in meno per la CPU, indubbio.

Modificato: 18 giugno 2008 da mubeta

[pigroplc]

Standardizzare il software significa anche standardizzare i collegamenti input / output.

Se pensi di utilizzare i parametri formali per ciascun input/output sei fuori strada secondo il mio parere, primo per il tempo ciclo, poi per la quantità di memoria necessaria.

Ho avuto a che fare qualche anno fa con un ingegnerino di primo pelo che aveva gestito il ciclo automatico con blocchi da 20 parametri e più.

Io ho cancellato tutto e ho rifatto la logica (tutta booleana) senza parametri e con la possibilità di debuggare senza troppi intoppi.

Comunque tu parli di semplicità poi metti gli input/output nei parametri formali: sei sicuro che il debug per un manutentore sia facile??

pigroplc

[pigroplc]

Standardizzare il software significa anche standardizzare i collegamenti input / output.

Se pensi di utilizzare i parametri formali per ciascun input/output sei fuori strada secondo il mio parere, primo per il tempo ciclo, poi per la quantità di memoria necessaria.

Ho avuto a che fare qualche anno fa con un ingegnerino di primo pelo che aveva gestito il ciclo automatico con blocchi da 20 parametri e più.

Io ho cancellato tutto e ho rifatto la logica (tutta booleana) senza parametri e con la possibilità di debuggare senza troppi intoppi.

Comunque tu parli di semplicità poi metti gli input/output nei parametri formali: sei sicuro che il debug per un manutentore sia facile??

pigroplc

[mubeta]

Se pensi di utilizzare i parametri formali per ciascun input/output sei fuori strada secondo il mio parere, primo per il tempo ciclo, poi per la quantità di memoria necessaria.

Mah, se riesci ad isolare parte del codice di programma che è ripetitivo, e scriverlo una unica volta, sotto forma di funzione, per poi passargli dei parametri, sopratutto se sono puntatori, hai sempre il coltello dalla parte del manico; anche se devi passargli qualche I/O.

E' chiaro che stiamo parlandi di standardizzare qualcosa che è sempre comune e molto presente nei programmi; non certo il merker di automatico/manuale o cosa ti può venire in mente.

Per una azienda costruttrice è poi molto importante la standardizzazione: l'azienda ha più bisogno di continuità e ripetibilità nei programmi, perché c'è sempre poco tempo per fare, perché ci devono mettere le mani in molti, perché tra venti anni i nuovi arrivati devono trovarsi a "casa" anche sulle macchine più vecchie, piuttosto che inventarsi di volta in volta il programma perché secondo l'ultimo venuto sarebbe meglio se... invece che...

Si deve insomma, trovare il giusto compromesso tra standard, economia, semplicità.

[mubeta]

Se pensi di utilizzare i parametri formali per ciascun input/output sei fuori strada secondo il mio parere, primo per il tempo ciclo, poi per la quantità di memoria necessaria.

Mah, se riesci ad isolare parte del codice di programma che è ripetitivo, e scriverlo una unica volta, sotto forma di funzione, per poi passargli dei parametri, sopratutto se sono puntatori, hai sempre il coltello dalla parte del manico; anche se devi passargli qualche I/O.

E' chiaro che stiamo parlandi di standardizzare qualcosa che è sempre comune e molto presente nei programmi; non certo il merker di automatico/manuale o cosa ti può venire in mente.

Per una azienda costruttrice è poi molto importante la standardizzazione: l'azienda ha più bisogno di continuità e ripetibilità nei programmi, perché c'è sempre poco tempo per fare, perché ci devono mettere le mani in molti, perché tra venti anni i nuovi arrivati devono trovarsi a "casa" anche sulle macchine più vecchie, piuttosto che inventarsi di volta in volta il programma perché secondo l'ultimo venuto sarebbe meglio se... invece che...

Si deve insomma, trovare il giusto compromesso tra standard, economia, semplicità.

[Eddyn°1]

Buon giorno!!

Per una azienda costruttrice è poi molto importante la standardizzazione: l'azienda ha più bisogno di continuità e ripetibilità nei programmi, perché c'è sempre poco tempo per fare, perché ci devono mettere le mani in molti, perché tra venti anni i nuovi arrivati devono trovarsi a "casa" anche sulle macchine più vecchie, piuttosto che inventarsi di volta in volta il programma perché secondo l'ultimo venuto sarebbe meglio se... invece che...

Si deve insomma, trovare il giusto compromesso tra standard, economia, semplicità.

Hai colto perfettamente nel segno.... E' esattamente quello che sto cercando di fare io, che pur lavorando su un'azienda consolidata e medio grande, questi concetti non sono ben chiari!!!

Ho avuto a che fare qualche anno fa con un ingegnerino di primo pelo che aveva gestito il ciclo automatico con blocchi da 20 parametri e più.

Normale.... Sicuramente arrivava dalla programamzione in C o in VB o altro..., dove il debugg è molto ma molto macchinoso....

La soluzione che andro ad adottare e quella di standardizzare pezzi di codice con aree di memorie M e T ben definiti.

Cerchero di standardizzare (a livello di chema elettrico) gli indirizzi degli ingressi e delle uscite in modo da non dover passare alcun dato all'FC..... il tutto salvato su biobbioteche..... Sinceramente il tutto non mi soddisfa a pieno, perchè avrei voluto utilizzare le "belle cose" che siemens mette a disposizione...... ma che poi non sono sempre utilizzabili.....

Ciao e grazie a tutti, altri consigli sono sempre ben accetti!!!

[Eddyn°1]

Buon giorno!!

Per una azienda costruttrice è poi molto importante la standardizzazione: l'azienda ha più bisogno di continuità e ripetibilità nei programmi, perché c'è sempre poco tempo per fare, perché ci devono mettere le mani in molti, perché tra venti anni i nuovi arrivati devono trovarsi a "casa" anche sulle macchine più vecchie, piuttosto che inventarsi di volta in volta il programma perché secondo l'ultimo venuto sarebbe meglio se... invece che...

Si deve insomma, trovare il giusto compromesso tra standard, economia, semplicità.

Hai colto perfettamente nel segno.... E' esattamente quello che sto cercando di fare io, che pur lavorando su un'azienda consolidata e medio grande, questi concetti non sono ben chiari!!!

Ho avuto a che fare qualche anno fa con un ingegnerino di primo pelo che aveva gestito il ciclo automatico con blocchi da 20 parametri e più.

Normale.... Sicuramente arrivava dalla programamzione in C o in VB o altro..., dove il debugg è molto ma molto macchinoso....

La soluzione che andro ad adottare e quella di standardizzare pezzi di codice con aree di memorie M e T ben definiti.

Cerchero di standardizzare (a livello di chema elettrico) gli indirizzi degli ingressi e delle uscite in modo da non dover passare alcun dato all'FC..... il tutto salvato su biobbioteche..... Sinceramente il tutto non mi soddisfa a pieno, perchè avrei voluto utilizzare le "belle cose" che siemens mette a disposizione...... ma che poi non sono sempre utilizzabili.....

Ciao e grazie a tutti, altri consigli sono sempre ben accetti!!!

[berbeck]

Buongiorno a tutti

è la prima volta che scrivo in questo forum.

Sono un installatore abilitato per le lettere A, B e G

Situazione:

-civile abitazione, 2 appartamenti indipendenti (stesso proprietario) <200mq

-fornitura energia unica (contatore ENEL 3KW)

-nessuna situazione che porti ad obbligo di progetto da parte di professionista abilitato

-unica centrale termica (se può essere definita così) con caldaia a gasolio con potenza nominale 43KW. la caldaia è alimentata dall'appartamento1

-Il proprietario ha eseguito dei lavori edili di ristrutturazione e mi ha commissionato il rifacimento totale dell'impianto elettrico dell'appartamento2

-Io ho installato l'impianto a regola d'arte (per il quale emetterò la DICO come "nuovo impianto") separandolo completamente dal resto della casa.

-Nell'appartamento2 l'idraulico ha installato un "kit di termoregolazione" per impianto a pavimento marcato CE e pronto per l'uso, SOLO da alimentare

-A questo kit sono collegate delle valvole di zona e una pompa comandata e i relativi termostati.

-Ora che l'impianto è quasi finito l'idea del committente è quella di far installare un nuovo contatore ENEL e collegare l'impianto appena installato.

Dubbi e domande:

1. posso io (abilitato per le lettere A,B,G) collegare (installare) questo tipo di kit? o rientra tra le mansioni di cui alla lettera C (impianti di riscaldamento, condizionamento...ecc)?

2. i termostati che io ho installato contestualmente a tutto il resto dell'impianto elettrico POTEVO installarli? o anche quelli fanno parte dell'impianto di riscaldamento in senso stretto?

3. l'idraulico, mi chiede ora, ad impianto praticamente ultimato di AGGIUNGERE nel locale dove è presente la caldaia (vedi spopra) una pompa AGGIUNTIVA comandata dall'appartamento2. Posso io portare in questo locale (anche se ordinario e non a rischio incendio) una alimentazione di una pompa "nuova" ? ad occhio non mi pare una cosa molto "a norma" e così avevo pensato di alimentare la pompa aggiuntiva (che serve l'appartamento2) con l'energia dall'appartamento1 (come tutto il resto del locale) e COMANDARLA con un relè a 12V che eccito con un trasformatore presente nell'appartamento2. In questo modo avrei solo una tensione di 12Vac (SELV). Ha senso la cosa? Non si può fare? è inutile? Come osso fare in alternativa?

Scusate per la lunghezza e grazie in anticipo per le eventuali risposte.

Saluti