Unitypro

[rddiego]

Volevo solo dire che Unity mi sembra una bomba

[Claudio Monti]

Confermo

[Robertogamma]

A mio parere, ha bisogno solo di qualche miglioramento sul controllo Motion : dopo è probabilmente tra i migliori sia x controlli di processo che x controllo macchine !!!

[Claudio Monti]

Effettivamente sulla motion qualcosa da dire c'e'...

mio malgrado sto realizzando una macchina con 12 assi controllati e la messa in funzione richiede un bel po' di tempo... purtroppo questo tempo si allunga inesorabilmente perche', in fase di debug sulle schede CAY, il refresh dei dati nella pagina e' LENTISSIMO, quindi non si riescono ad apprezzare le variazioni dei valori con i movimenti in corso!

Spero che lo sistemino

[Robertogamma]

E se provassi a by-passare la scheda CAY comandando gli assi direttamente con la cpu ? Troppo pesante il carico di lavoro ? Credo che siano cpu sufficientemente veloci da sopportare un tentativo in questo senso !

[montese]

Ciao a tutti,

scusate l'intromissione...

Sono nuovo nel campo e trovo abbastanza difficile reperire informazioni dal sito della telemecanique per quanto riguarda i software di programmazione.

Posseggo un Premium 57202 e ho iniziato ad utilizzarlo con il PL7 3.3 pro e il PL7 4.0 demo.

Sinceramente tra i due per ora non ho notato differenze.

In un corso di automazione invece stiamo utilizzando dei siemens S7 con lo Step 7.

Devo dire che per quanto riguarda il Ladder non ci sono paragoni. Lo Step 7 ha un editor di gran lunga superiore e facile da usare.

Ho sentito parlare di questo "Unity" ma non sono ancora riuscito a capire se è un altro software per la programmazione del PLC premium o meno. Voi dite che è una bomba. Spero proprio che sia quello di cui ho bisogno io !!

Che mi dite ?

Un'altra cosa...

Dal sito della telemecanique una volta (ma anche 2-3 settimane fa) ho scaricato il PL7 demo. Ora ho visto che non si può scaricare più nulla, hanno tolto qualsiasi cosa che fosse un .exe ! Solo .pdf

Esiste una versione demo del "Unity" ? dove si può trovare ?

Avrei tante altre domande, ma per ora mi fermo qui.

Grazie,

Massimo.

[Claudio Monti]

Scrivi alla Schneider... e chiedi la demo!

[beasrl]

Salve ultimamente ho realizzato ( e sto finendo di collaudare ) una macchina con premium + unity 2.1.

La configurazione prevede 3 assi ( con cay 41 ) e I/O in canopen (contatori veloci e I/O discreti)

Sinceramente penso che unity sia un prodotto valido ma ancora molto immaturo.

A parte continui crash (prove effettuate su svariati PC) penso che ci siano ancora molte cose che vadano corrette porto solo alcuni esempi delle 4 pagine di bug che trasmettero' a schneider ( con cui tra l'altro ho un ottimo rapporto ).

1) Il più delle volte devo ricompilare tutto il progetto anche per piccole modifiche e lo devo riscaricare completamente ( con relativo stop della CPU) pensate cosa succederebbe in un impianto di cogenerazione !!!!!

2) Ogni qualvolta scarico il programma perdo tutti i valori delle memorie comprese le %MW ( in pl7pro non si perdevano) ... vabbene che le posso salvare ma se mentre programmo on line accade il punto 1 e non ho salvato le %mw ?

3) Ogni tanto appare il messaggio in fase di compilazione "errore sconosciuto" (se non lo sa il compilatore che errore c'è !)

4) Per configurare dei nodi CANOPEN servono 3 SW diversi (fortuna che si chiama unity !)

5) Il contatore veloce in canopen lavora solo a 16 bit (occhio !!!)

6) quando si riscarica il progetto le istanze delle DFB si perdono (immaginate se in un impianto con siemens ad un tratto tutti i valori delle DB di istanza andassero al valore iniziale !)

potrei continuare per un bel po' !!!

comunque a parte questo il prodotto è buono e l'assistenza è ottima , penso che risolti questi problemi probabilmente sarà uno dei migliori sistemi

P.S. Ho avuto la garanzia da parte di schneider che almeno il problema della perdita dell %MW verrà risolto nella versione 2.3

il mio personale consiglio è di attendere questa versione prima di passare a unity.

Modificato: 14 febbraio 2006 da beasrl

[Claudio Monti]

A parte continui crash (prove effettuate su svariati PC)

con le vecchie versioni sicuramente, con la 2.2 non ho ancora avuto problemi;

1) Il più delle volte devo ricompilare tutto il progetto anche per piccole modifiche e lo devo riscaricare completamente ( con relativo stop della CPU) pensate cosa succederebbe in un impianto di cogenerazione !!!!!

Attento, ci sono 2 modalita': una cosa e' la ricostruzione totale del progetto che poi ti obbliga a ritrasferire tutto sul PLC (come se fosse un sw nuovo), un'altra e' la compilazione di SOLO cio' che hai modificato e puoi farlo tranquillamente online senza i problemi che hai elencato, anzi, in questo e' molto meglio di PL7 in quanto ti permette di fare online tante piu' cose (pensa solo ai temporizzatori...);

2) Ogni qualvolta scarico il programma perdo tutti i valori delle memorie comprese le %MW ( in pl7pro non si perdevano) ... vabbene che le posso salvare ma se mentre programmo on line accade il punto 1 e non ho salvato le %mw ?

Mi riservo di verificare, ma mi sembra che ci sia l'opzione per mantenerne il valore...

3) Ogni tanto appare il messaggio in fase di compilazione "errore sconosciuto" (se non lo sa il compilatore che errore c'è !)

Trovo il debug molto ben fatto, prova a farmi un esempio di questo messaggio, io nonl'ho mai visto... magari non sono mai riuscito a creare le condizioni...

Sinceramente penso che unity sia un prodotto valido ma ancora molto immaturo.

Fidati, era IMMATURA la versione 1.0, la 2.2 e' gia' ad un buon livello, ma sicuramente ha ancora alcune cose da sistemare (ad es. le pagine di debug sulle schede assi, sono di una lentezza unica!!!)

[beasrl]

Grazie per i consigli,

il problema della ricompilazione nasce proprio da ciò che hai detto. Alcune volte faccio piccole modifiche (alla logica non alla configurazione HW ) ma non mi viene più data la possibilità di fare la compilazione parziale on-line !!! come se avessi fatto delle modifiche alla parte di configurazione. Un'altra cosa che ho notato nella configurazione della cay e che i dati e i valori che vengono modificati on-line non vengono aggiornati nel progetto off-line ! in questo modo se scarico tutto nuovamente e non mi sono ricordato di riportare a mano i valori sul progetto off line vengono ricaricati i vecchi valori ! Poi secondo me l'algoritmo di controllo della scheda prevede pochi parametri ( chi,kd,.....) cosa che non mi permette di realizzare tarature degli assi come piacciono a me ! inoltre è del tutto assente uno strumento "oscilloscopio". Per graficare l'errore di inseguimento sono stato costretto ad appoggiare questo valore su un %MW e visualizzarlo graficandolo con un trend di cimplicity !

Il problema del salvataggio delle %MW a parola di schneider sarà risolto nella versione 2.3 che uscirà a giugno.

Rimarrà comunque il problema delle variabili non allocate e le istanze delle DFB che vengono inesorabilmente perse!

Per non parlare poi del grafcet che riscaricando tutto vengono persi i valori degli stati !

Secondo me Schnieder deve ancora fare molta strada prima di arrivare ad avere un prodotto stabile e collaudato come Siemens, GE, Omron o Allen-Bradley ma continuo a dire che le premesse sono buone. Quello che tuttavia non riesco a mandare giù e il fatto che è toccato a noi debuggare (perchè a perer mio di beta test si parla) un SW incompleto e instabile ! Visto che sono due anni che si parla di Unity non potevano aspettare ancora 6 mesi. (tra l'altro dicono di aver speso una "manovra finanziaria" per sviluppare questo SW bha ).

Se interessa a qualcuno potrei pubblicare la lista completa (4 pagine di word) dei bug e magari discuterla assieme !

P.S. come hai fatto ad avere la versione 2.2 che ufficialmente non è ancora uscita ? l'hai avuta sotto banco

[ronald]

I bug è sempre meglio conoscerli, quindi se si possono avere, più che volentieri

La versione 2.2 a me è arrivata automaticamente avendo registrato da meno di un anno la 2.1.

[bigalex]

Ho dovuto utilizzare Unity Pro 2.1 per una macchina con 9 assi in canopen .

Se devo essere sincero ho rimpianto molto PL7 per molti aspetti che per brevità non descrivo ora.

Qualche impiccio che non mi piace è :

1- Dover ricompilare offline e dover ritrasferire l'intero progetto in diversi casi tra cui l'inserimento di una istanza tipo PL7_TON ( timer tipo PL7) oppure quando dopo avere dichiarata ed utilizzata una variabile (es. INTEGER ) se ne cambia il tipo (es. da INTEGER --> REAL) ;

2- Azzeramento variabili dopo trasferimento progetto ;

3- Lentezza animazione in debug;

4- Cross Reference da incubo ;

5- Non avere la possibilità di visualizzare in modo efficace se una variabile allocata è già stata utilizzata ;

6- L'overlapping di variabili allocate ;

7- Essere obbligati all'utilizzo di variabili allocate per comunicare con pannelli operatore o altro .

etc. etc. .

Di strada se ne deve fare molta .

Su un macchinario o impianto di grandi dimensioni (complessità) o dove ci sono processi che non possono essere interrotti con facilità è devastante utilizzare Unity .

Preciso che questo è il mio parere personale e non vuole in alcun modo essere denigratorio nei confronti di nessuno.

[Claudio Monti]

La versione 2.2 mi e' arrivata automaticamente avendo registrato la 2.1, tra l'altro e' arrivata a me prima che a tanti tecnici =S=...

Rispondendo a Bigalex:

- Unity l'ho utilizzato soprattutto per progetti piuttosto grandi, mi ha infatti aiutato moltissimo la nuova struttura delle variabili...

- per quello che riguarda la modifica del tipo, beh, prima come facevi? Ti creavi un'altra variabile REAL e la usavi! Fai la stessa cosa. Dovrei provare, ma mi sembra che si possa fare online...

- PL7_TON non ho provato

- Azzeramento variabili, questa e' una scocciatura!

- Cross Reference: concordo! C'e' da perdersi!

- Puoi vedere se una variabile e' allocata semplicemente modificando la visibilita' delle colonne nell'editor variabili: ce n'e' una che si chiama "Usato", la spunti e vedrai che ti dice quante volte l'hai usata

- variabili allocate per comunicare: si', e' una scocciatura, ma non dipendono da Unity, bensi' dalle altre apparecchiature! Se XBTG non ti permette di usare variabili non allocate non c'e' verso di fare altrimenti.

[Claudio Monti]

Azzeramento variabili: hai provato a scaricare i dati in un file.DAT e poi reinserirlo?

[beasrl]

Il fatto di salvare un file .dat è sicuramente utile ma non risolve il problema !

se non ti ricordi di salvare il file ?

se hai usato var non allocate ?

Per le istanze delle DFB è possibile salvare i valori in un file. Se però viene modificata anche una di queste istanze non è più possibile ripristinare nessun valore se non le %MW e le %M.

[bigalex]

Si ho già attuato la procedura di salvare le variabili nel file .DAT .

Rimane comunque una procedura "ruvida" e non mi sembra una bella cosa visto che questo Unity è stato come "Aspettando Godot" .

E' stato annunciato per anni , descritto come una rivoluzione copernicana nelle piattaforme di programmazione ma, a mio modesto parere, le aspettative sono state deluse .

Ribadisco la validità di alcuni aspetti tra i quali gli Array di variabili (es. a più dimensioni) , ma molti aspetti sono molto più ostici che in PL7 .

Inoltre credo che per poterlo utilizzare bene ci vorrebbe un education approfondito e non una mezza giornata al volo come propone Schneider.

Inoltre non sono molti i tecnici Schneider che hanno veramente esperienza sul prodotto e ne conoscono a fondo il funzionamento .

Ciao

Bigalex

[Stefano Sormanni]

L'unico che conosce bene Unity a pronto contatto è Serano...

[luciopro]

Salve a tutti,

anche io sto iniziando ad avvicinarmi al mondo unity. Per il momento sto solo testando l interfaccia operativa per prendere un po di confidenza con il software e le novità implementate in esso.

Mi piacerebbe tuttavia fare un confronto con chi è più esperto di me su due temi:

1- I "buchi" presenti: se si potesse stilare una lista dei problemi riscontrati in modo da evitarli.

2- Le migliorie o le mancanze che secondo voi presenta in modo da poterci confraontare.

Dal mio punto di vista le cose che mancano, per il momento sono le seguenti (forse alcune cose è possibile farle ma non ho identificato la modalità):

1- Confronto file online-offline che indichi esattamente i punto in cui il software diversi (per intenderci vedi step7)

2- Possibilità di scaricare solo parti di programma in Run o configurazione fisica.

3- Possibilità di suddividere la memoria in diverse tabelle (ad esempio DB Siemens), in modo da poterne ampliare le dimensioni senza intercorrere nel problema delle sovrapposizioni di memoria.

come vi ho detto sono all inizio dell utilizzo dello Unity....aspetto un vostro riscontro.

Ciao e grazie

Modificato: 5 settembre 2006 da luciopro

[rddiego]

il confronto online/offline non è possibile (inteso come in altri prodotti), però è un'opzione utile in casi particolari e comunque lascia il tempo che trova a mio parere

il punto 2 non mi è chiaro cosa intendi. In modalità RUN puoi scaricare tutto il codice che vuoi. Alcune modifiche sono necessarie offline in quanto intaccano la struttura dei dati già configurati (quantità dei dati, indirizzamenti, collegamenti indiretti..). La configurazione dell'hardware è necessariamente da fare offline.

sul punto 3 stai facendo un paragone con Siemens assolutamente improprio. Esistono le strutture di dati che offrono possibilità enormemente maggiori delle DB: sono le DDT che ti permettono di creare strutture di dati anche molto complesse e di differenziarle tra loro in maniera più che intuitiva e di crearne quante ne vuoi (memoria permettendo). Non esistono problemi di sovrapposizioni quando le variabili non sono allocate e per inciso l'allocazione (stabilire un indirizzo) serve solo praticamente per comunicare con apparecchiature esterne.

Un esempio.

Ho 10 motori da gestire. Per una miglior organizzazione decido di creare un DB per ciascun motore. La DB conterrà tutto di quel motore: Comandi Manuali, comandi automaici, allarmi, tempi, sensori analogici (temp., pressioni ....) e quant'altro possa servire. Avrò così creato la mie 10 DB (DB1, DB2, DB3, DB4....DB10). In maniera simile creerò un DDT con tutte le mie informazioni e lo chiamerò "MOTORE". Nella mia tabella delle variabili creerò così le mie 10 variabili strutturate come MOTORE (pompa1, traslazione, pompa_risciacquo etc. etc.) Non sembrano esserci grandi differenze!!! In realtà però per esempio allarmi potrebbe essere un'altra struttura, comandi ugualmente un'altra struttura, tempi potrebbe essere un array... Insomma le possibilità si allargano enormemente.

[walterword]

si si e' vero !!!

[luciopro]

Ciao rddiego,

ho letto il tuo messaggoe cerco di chiarirmi meglio:

il confronto online/offline non è possibile (inteso come in altri prodotti), però è un'opzione utile in casi particolari e comunque lascia il tempo che trova a mio parere

il confronto online/offline lo eseguo ogni volta che devo modificare un software. Spesso metto mani a macchina vecchie e non so mai se il software di partenza è quello che sta girando oppure no. un bel confronto mi permette di sapere esattamente se il software è quello oppure no ed in caso negativo quali sono le differenze

il punto 2 non mi è chiaro cosa intendi. In modalità RUN puoi scaricare tutto il codice che vuoi. Alcune modifiche sono necessarie offline in quanto intaccano la struttura dei dati già configurati (quantità dei dati, indirizzamenti, collegamenti indiretti..). La configurazione dell'hardware è necessariamente da fare offline.

Supponiamo che modifico in ufficio un programma in particolare modifico SR20 SR30. se potessi trasferire parti di programma arrivato dal cliente trasferirei solo le due SR modificate senza bisogno di fermargli l'impianto.

sul punto 3 stai facendo un paragone con Siemens assolutamente improprio. Esistono le strutture di dati che offrono possibilità enormemente maggiori delle DB: sono le DDT che ti permettono di creare strutture di dati anche molto complesse e di differenziarle tra loro in maniera più che intuitiva e di crearne quante ne vuoi (memoria permettendo). Non esistono problemi di sovrapposizioni quando le variabili non sono allocate e per inciso l'allocazione (stabilire un indirizzo) serve solo praticamente per comunicare con apparecchiature esterne.

Il mio rifermento era proprio a variabili allocate. Mi risulta che momentaneamente sono poche i touch screen che ti permettono di puntare a variabili non allocate.

Per una miglior organizzazione decido di creare un DB per ciascun motore. La DB conterrà tutto di quel motore: Comandi Manuali, comandi automaici, allarmi, tempi, sensori analogici (temp., pressioni ....) e quant'altro possa servire.

Il tuo esempio è proprio calzante. Supponiamo di avere creato una parte di memoria in cui descrivo le caratteristiche di un motore. A tale parte di memoria aggiungiamo 10-15 Word per ampliamenti futuri, quindi la allochiamo e realizziamo la supervisione. Dopo un certo tempo ci chiedono una bbella modifica al software, e caso vuole che dobbiamo ampliare la memoria dedicata ad ogni singolo motore, e le word lasciate come scorta non sono sufficienti. Ci tocca riallocare tutto e riprendere una bella parte del software di supervisione. Se avessi avuto la memoria divisa in + strutture il problema (lato visualizzazione) non si sarebbe verificato.

Come ho detto prima questa è la mia opinione, forse dovuta al mio modo di lavorare. Ero solo curioso di un confronto con altri che utilizzano lo stesso prodotto.

ciao

[rddiego]

il confronto online/offline lo eseguo ogni volta che devo modificare un software. Spesso metto mani a macchina vecchie e non so mai se il software di partenza è quello che sta girando oppure no. un bel confronto mi permette di sapere esattamente se il software è quello oppure no ed in caso negativo quali sono le differenze

ok e quando sai le differenze cosa fai? Scarichi il programma offline? O modifichi quello online? E se hai delle differenze su un impianto che sta andando probabilmente il tuo software offline non sarà l'ultimo e quindi non fa fede, sarà da cestinare. Ecco perchè è un opzione che lascia il tempo che trova..

Se hai delle differenze non fai prima a fare l'upload?

Supponiamo che modifico in ufficio un programma in particolare modifico SR20 SR30. se potessi trasferire parti di programma arrivato dal cliente trasferirei solo le due SR modificate senza bisogno di fermargli l'impianto.

Certo che puoi farlo (ma anche con PL7PRO)

Il tuo esempio è proprio calzante. Supponiamo di avere creato una parte di memoria in cui descrivo le caratteristiche di un motore. A tale parte di memoria aggiungiamo 10-15 Word per ampliamenti futuri, quindi la allochiamo e realizziamo la supervisione. Dopo un certo tempo ci chiedono una bbella modifica al software, e caso vuole che dobbiamo ampliare la memoria dedicata ad ogni singolo motore, e le word lasciate come scorta non sono sufficienti. Ci tocca riallocare tutto e riprendere una bella parte del software di supervisione. Se avessi avuto la memoria divisa in + strutture il problema (lato visualizzazione) non si sarebbe verificato.

Primo.. se ti chiedono una modifica di una certa consistenza che cosa ci puoi fare? non è che c'è un plc che ti risolve questi "falsi" problemi.

Secondo... se preferisci aggiungi più word di memoria per modifiche future (ne hai migliaia a disposizione!!!)

Se avessi avuto la memoria divisa in + strutture il problema (lato visualizzazione) non si sarebbe verificato.

Ma la memoria è divisa in diverse strutture come ti ho fatto osservare nel mio precedente esempio.

Credo che ci sia qualcosa che mi sfugge, oppure non ti ho ben chiarito la grande maneggevolezza che ha questo modo di utilizzare l'area di memoria (che per altro già Allen Bradley fa da tempo), oppure sei un po' arenato sui DB (lo escluderei visto che vuoi conoscere cose diverse)

[Claudio Monti]

La struttura dati di Unity e' veramente flessibile e potente... pero' come dice Luciano e' limitata nel momento in cui devi interfacciarla con un HMI in quanto quest'ultimo punta solo all'area di memoria allocata.

Il TOP sarebbe poter avere un HMI che si lega alla memoria non allocata gestita da Unity!

Tanto per capirci non dichiaro piu' una variabile di tipo WORD %MW10 con simbolico pinco_pallino bensi' dichiaro una variabile pinco_pallino senza indicare l'esatta posizione in memoria, si arrangia il processore (un po' come avviene in C# o VB...): se potessi avere un HMI che punta a pinco_pallino !!!

Se Schneider facesse un ambiente UNICO che comprendesse i PLC e gli HMI allora lo si potrebbe chiamare veramente UNITY !!!

[Stefano Sormanni]

a proposito di buchi (?), se inserisco una riga di prg con una word %mw e poi associo a questa %mw un simbolo, unity non mi aggiorna il nome sulla variabile utilizzata (come in PL7).

[Stefano Sormanni]

Sentite questa!

per fare un fronte di salita:

CAL R_TRIG_Instance (CLK:=ClockInput, Q=>Output)

che bomba!