Vai al contenuto
PLC Forum


Unitypro


rddiego

Messaggi consigliati

Claudio Monti
Probabilmente devo cambiare lo stile di programmazione e adattarlo al sistema di programmazione del plc...

L'uso dei salti e' molto diffuso in chi proviene dal mondo Siemens programmazione AWL...

Io sinceramente non li uso mai, anche perche' devi sempre star li' a ragionare sulla condizione, su dove va a finire il salto, ecc... e in tutta franchezza il programma ne risente in leggibilita' (risparmi qualche ms in elaborazione, ma non sempre e' necessario ridurre all'osso l'esecuzione...).

Programmando in ST ed usando IF-THEN-ELSIF-ELSE o CASE SELECT praticamente i JUMP non servono. ;)

Link al commento
Condividi su altri siti


  • Risposte 63
  • Created
  • Ultima risposta

Top Posters In This Topic

  • rddiego

    16

  • Claudio Monti

    13

  • Stefano Sormanni

    10

  • MarcoEli

    4

Non e' per fare confusione, ma dato che sto' iniziando un grosso progetto con Schneider e provengo da un altro ambiente sto' cercando di imparare (e in poco tempo) le potenzialità e i difetti del nuovo ambiente unity. Le potenzialita' le tralascio, quelle aiutano il programmato, e sono molte. Quello che voglio affrontare al momento sono i "buchi" e le zone grigie di ogni ambiente di sviluppo. Più a fondo si conosce l'ambiente e più si riesce a sfruttare meglio. E' per quello che anche i piccoli suggerimenti da "esperti" come voi che gia' utilizzano il sistema da tempo e ne hanno affrontato tutte i vari aspetti sono preziosi.

I salti come li intendo io non servono per velocizzare l'esecuzione, non ho nessun problema di velocita'. Servono principalmente per bypassare intere sezioni di codicie non attive. Con Siemens diventa naturare andare in online, si vede al volo se una sezione di codice e' eseguita oppure no, se ci si entra anche solo un volta e poi non si passa si ha lo stato dell'esecuzione. Scorrendo con il cursore le varie zone del programma sono sempre aggiornato sulla situazione dell'elaborazione. Sequire passo passo (presumo sia un trace, anche se devo ancora provarlo) e' utile per particolari condizioni, ma suppongo blocchi l'esecuzione, e questo su di un impianto non e' quasi mai possibile.

Al momento sto' usando il simulatore, in quanto il materiale hw deve ancora arrivarmi, troppe volte ho dovuto ricompilare il progetto per variazioni e ricaricarlo, perdendo i valori delle %MW. Spero che in online reale questo non succeda... sarebbe una grossa limitazione in caso di testo e messa a punto di processi non interrompibili.

Altra cosa che sto' affronatno e' la programmazione, meglio il linguaggio IL o ST ? Oppure un mix di entrambi...

Link al commento
Condividi su altri siti

Servono principalmente per bypassare intere sezioni di codicie non attive

la sezione la crei come MAST e potresti condizionarla ad una variabile. In questa maniera hai un minimo di grafica per capire se la MAST è attiva o meno poichè c'è un pallino animato al fianco del nome della sezione nell'albero a sinistra.

Potrebbe magari fare al caso tuo.

C'è anche da dire che le istruzioni IF THEN, CASE sono dei salti quindi tutta sta difficoltà nel debug ne vedo poca. Potresti aiutarti con la grafica e farti un piccolo supervisore veloce.. Aiutati con la programmazione inserendo talpe dove ti servono e le tieni sotto controllo in una tabella di animazione.

troppe volte ho dovuto ricompilare il progetto per variazioni e ricaricarlo, perdendo i valori delle %MW

beh questo non è una nota è la normalità all'inizio.. Potresti mettere dei valori di default iniziali, oppure se sono %MW puoi salvare i valori su file prima di ricaricare il programma ed ogni volta che vuoi puoi ricaricarli nel programma.

una grossa limitazione in caso di testo e messa a punto di processi non interrompibili

dipende da cosa devi modificare nel programma. Certe cose non puoi farle online, ma molte altre sì. Se vai durante i test con un programma testato e "pronto per ogni evenienza" vai tranquillo.

Per esempio se lavori con strutture dati e hai bisogno di modificarle devi interrompere il processo, ciò comporta che il programma prima di essere scritto deve essere pensato e bisognerebbe prevedere anche l'impossibile che per Murphy appeno lo pensi...tac!!!!

meglio il linguaggio IL o ST

a parte che ci sono anche altri linguaggi, credo che sia abbastanza indifferente.

Io credo che ST sia il non plus ultra (come AWL lo è nel siemens), ma ad ogni modo dipende da cosa devi fare.

Link al commento
Condividi su altri siti

Claudio Monti

Aggiungo a quanto dice rddiego:

- ti consiglio ST, ti straconsiglio SFC (Grafcet), prova anche FBD... io non l'avevo mai usato ma e' veramente potente e online il debug e' semplicissimo!

- ti sconsiglio IL (se cerchi nel forum qualcuno ha postato anomalie sul IL)

Puoi creare tutte le sezioni che vuoi e le puoi vincolare al valore di una variabile, quindi puoi scegliere se eseguire o meno quella sezione, come dice rddiego a fianco compare un pallino colorato: verde la sezione e' eseguita, rosso no.

Occhio alla compilazione:

se fai modifiche online puoi semplicemente fare una compilazione parziale delle sole modifiche effettuate e questo NON richiede il ri-trasferimento al PLC.

Ovvio se fai modifiche pesanti DEVI fare un "compila tutto" e trasferire al PLC.

Ti consiglio, dopo che hai fatto le tue verifiche, modifiche ecc... di fare un "compila tutto" e trasferire al PLC prima dell'installazione finale, cosi' il file viene ricostruito e compattato e tiene molto meno posto!

Link al commento
Condividi su altri siti

Metti una "talpa": inserisci una word che incrementa ad ogni ciclo dopo il salto che dici di eseguire e vedi se il codice viene eseguito ma ad ogni detto così è difficile aiutarti prova a postare il codice.

Metti una talpa... Ma dai, ma come ca..o parli ? :lol:

Link al commento
Condividi su altri siti

Claudio Monti

Talpa o trappola sono termini molto usati (almeno per chi come me in passato ne ha usati per il debug dei programmi...), sara' l'eta' ma a me non e' sembrato un termine cosi' strano.

Link al commento
Condividi su altri siti

...a me non e' sembrato un termine cosi' strano.

Ma si, tanto per dire... in ogni caso per debug approsimativi vanno bene anche le talpe che è risaputo ci vedono poco e male. Per debug oculati bisognerebbe passare ad esempio a Siemens con Step7. UnityPro mi sembra un altro prodotto partito con il piede sbagliato.

Ho detto. :lol:

Link al commento
Condividi su altri siti

Claudio Monti

In tutta onesta' devo dirti che si' Unity e' nato con qualche difettuccio, ma rimane comunque un sw davvero buono!

Se mi parli di pesantezza all'avvio e/o altre cosucce che sono venute fuori nei post ti do ragione, ma anche Step7 non mi sembra cosi' snello x i PC!

Le "talpe" erano il giusto consiglio di rddiego per chi, come cliff e' abituato ad un metodo di programmazione.

Con Unity ci sono strumenti di debug (stile VisualStudio), ci sono le colorazioni verde/rosso di tutte le variabili booleane, ti da' la possibilita' di vedere i valori degli altri tipi di variabili, ti da' la possibilita' di crearti tabelle di animazione, ti da' la possibilita' di forzare i bit o cambiare il valore con un semplice clic del tasto destro del mouse, ti da' la possibilita' di gestire e debuggare come piu' ti pare e piace i SFC, ecc...

A proposito, mi risulta che il SFC su Siemens sia uno strumento a parte, a pagamento... con Unity (e gia' con PL7) e' gia' compreso nell'ambiente di sviluppo... no a me non sembra per niente male. Ripeto, ci sono alcune cosine da sistemare (tra l'altro molte gia' previste per le prossime release), ma il prodotto non mi sembra partito con il piede sbagliato!

Link al commento
Condividi su altri siti

Ma cosa parliamo di SIEMENS, provate a fare una comunicazione TCP OPEN con il tedesco!

Provate a fare un PID!

Provate a gestire un valore analogico!!

bah, una volta esistevano solamente i tedeschi, adesso la musica è cambiata.................!!

Link al commento
Condividi su altri siti

Stefano Sormanni

Io provengo dal mondo Siemens (e non a caso programmo in IL) e devo dire che a parte i difetti che ance step7 aveva (e ha), mi devo inchinare ai tedeschi. In tanti anni di programmazione sia in step 5 che 7, non ho mai visto una CPU inchiodata (in errore quasi sempre), o che dopo 2 anni iniziasse a dare i numeri (ve lo immaginate cosa accadrebbe su un sistema in continua!). Quindi da tener presente è l'estrema affidabilità del prodotto. Non voglio dire che Unity e Premium siano dei prodotti scadenti, ma prima di arrivare al livello tedesco la strada è ancora lunga.

Es.

- Se ho nel PLC e sul PC il programma differente, Unity non mi fa vedere il codice differente tra PC e PLC, Siemens SI

- Se ho modificato solo un blocchetto, e faccio il trasferimento Unity mi compila tutto e trasferisce tutto, Siemens solo il blocchetto.

- se inserite una parte di codice dove assegnate a 1 i bit da %M0:1000 (es. con l'istruzione MOVE) l'opzione "sovrapposizione indirizzi" è inutilizzabile, su Siemens no.

e tanto altro...

Link al commento
Condividi su altri siti

Io provengo dal mondo Siemens (e non a caso programmo in IL)

siamo alle solite... non è questione di mondi, è questione di conoscere gli strumenti che si ha a disposizione. Awl o Kop o FUP sono ottimi strumenti, ma diversi da altri. IL non è certo paragonabile a AWL quindi il tuo "non a caso" è un concetto non corretto oltre che limitato.. Sviluppa in ST o prova SFC insomma non essere categorico.

se inserite una parte di codice dove assegnate a 1 i bit da %M0:1000 (es. con l'istruzione MOVE) l'opzione "sovrapposizione indirizzi" è inutilizzabile, su Siemens no.

MOVE_BOOL_AREBOOL (IN := a,OUT => b ); dove a è un bit e b un array di ebool

Modificato: da Claudio Monti
Link al commento
Condividi su altri siti

  • 15 years later...

Yiogo ... forse hai tanto tempo da dedicare al forum ma il post che hai riesumato risale al 2008 !!!

 

Temo anche che alcuni dei partecipanti al post non siano più tra noi ...

Link al commento
Condividi su altri siti

  • Ivan Botta locked this discussione
Ospite
Questa discussione è chiusa alle risposte.

×
×
  • Crea nuovo/a...