funzioni fronti di salita /discesa

[TheOutSideR]

buonasera, ho provato a cercare ma non capisco la differenza,nel Tia portal,

delle istruzioni P=/N= e P_trig /N_trig...

a me sembrano uguali ma magari non colgo la differenza....

Potreste supportare la risposta con esempi ??? Grazie.

 

[leleviola]

Basta leggere l'aiuto in linea, comunque sono funzioni simili ma che si differenziano per la base di attivazione e per la posizione in cui vengono inserite, alcune vengono attivate confrontando lo stato dell'operando che controllano, altre vengono attivate dalla veridicità della logica che sta alla loro sinistra, altre dalla veridicità della logica alla sinistra ma anche dalla posizione in cui vengono inserite. L'unico vero "inconveniente" o obbligo che hanno è l'utilizzo di un operando dedicato per l'esecuzione dell'istruzione, in pratica ogni istruzione deve appoggiarsi a una memoria interna del PLC che ogni volta deve essere diversa, pena la non corretta esecuzione dell'istruzione. Insomma si potrebbe nel 2019, quasi 2020,  modernizzare tale istruzione non obbligando il programmatore a dedicare risorse all'esecuzione della specifica istruzione impulsiva, delegando al compilatore del programma tale compito

Modificato: 23 dicembre 2019 da leleviola

[Cesare Nicola]

 

Insomma si potrebbe nel 2019, quasi 2020,  modernizzare tale istruzione non obbligando il programmatore a dedicare risorse all'esecuzione della specifica istruzione impulsiva, delegando al compilatore del programma tale compito

In realtà esiste l'istruzione R_TRIG che, utilizzando una DB di appoggio tutta sua (come i TON, per intenderci), evita di dover definire il bit di appoggio. Bene, ma non benissimo. 🙂 Sembra che per gli sviluppatori Siemens sia tuttora un problema quasi insormontabile. 🙂

 

[leleviola]

 

In realtà esiste l'istruzione R_TRIG che, utilizzando una DB di appoggio tutta sua (come i TON, per intenderci), evita di dover definire il bit di appoggio.🙂

 

Bene che esiste l'istruzione ma sei impegnato nella risoluzione di una logica complessa di una sequenza complessa e devi pure distogliere l'attenzione e pensare alla logica a basso livello del PLC, Siemens fa passi da gigante con DB d'stanza, strutture, array e poi non migliora  la base della programmazione evoluta, lasciando al cliente quella che lei stesso con banali istruzioni potrebbe risolvere, speriamo che un giorno possano toglierci di dosso sto pregiudizio

Modificato: 26 dicembre 2019 da leleviola

[pigroplc]

R_TRIG che, utilizzando una DB di appoggio tutta sua

R_TRIG che, utilizzando una DB di appoggio tutta sua

Non è detto che si debba per forza utilizzare una DB istanziata esclusivamente per il fronte di salita o discesa. Si può creare una sola DB per tutte le istanze oppure semplicemente utilizzare una FB e istanziare il fronte di salita nell'area ritentiva del richiamo dell'FB, area che diventerà ritentiva al momento della dichiarazione dell'istanza della FB.

Tuttalpiù si può fare come gli antichi (fra i quali mi ci metto pure io) che facevano il fronte di salita con le semplici istruzioni, utilizzando sempre un merker.Parlo di step 5 per intenderci.

 

Secondo me i problemi di TIA sono altri, non ultimo il tempo di compilazione della parte WinccFlexible che ho visto arrivare anche a 9 min (con un SSD!!!) per impianti "impegnativi" con molti script e funzioni complesse. Visto che durante la compilazione non è possibile fare modifiche e che mi è impossibile aspettare che il programma sia compilato per procedere col resto e non posso restare fermo quel tempo per qualche pagina modificata durante le prove, ho dovuto fare il contrario del concetto del TIA: 
dividere i progetti fra PLC, Scada e HMI per il pannello dei comandi manuali. Sto parlando di un impianto con 1500 I/O qualche asse controllato un pò di inverter e un pò di encoder Profinet.

 

Cioè ho dovuto fare il contrario rispetto al concetto del TIA dove tutto è raggruppato. A mio avviso questo è un limite, non lo è certo un banale fronte di salita a preoccuparmi. 

Modificato: 27 dicembre 2019 da pigroplc

[batta]

 

Insomma si potrebbe nel 2019, quasi 2020,  modernizzare tale istruzione non obbligando il programmatore a dedicare risorse all'esecuzione della specifica istruzione impulsiva, delegando al compilatore del programma tale compito

Non posso credere che si possa arrivare a lamentarsi anche per questo. È semplicemente una filosofia diversa, non più vecchia o peggiore.

 

il tempo di compilazione della parte WinccFlexible che ho visto arrivare anche a 9 min

Mai nemmeno lontanamente avvicinato a simili tempi.

[leleviola]

batta non è che mi lamento è che sarebbe meglio focalizzare l'attenzione su altro o meglio sarebbe più utile semplificare le istruzioni base e lasciare al programmatore la focalizzazione ad alto livello del programma, convieni con me che sarebbe di sicuro una fonte in meno di errore? Può capitare a tutti di sbagliare o fare un errore di battitura se oltre a pensare alla gestione dei fronti e del loro ordine devi gestire pure la programmazione a alto livello, può capitare a volte che ti perdi o commetti degli degli errori, se invece a tutto ciò ci pensasse il compilatore sarebbe sicuramente meglio

[pigroplc]

Mai nemmeno lontanamente avvicinato a simili tempi.

Batta,

per contratto non posso divulgare gli applicativi di questo cliente altrimenti ti manderei il progetto, ti posso assicurare che ci arrivo alla grande. Penso che questo tempo di compilazione enorme sia dovuto ad una enorme mole di script e/o di faceplate. 
Negli applicativi che faccio dove l'utilizzo di faceplate non è previsto, il tempo di compilazione è di un paio di minuti al massimo. Gli script li uso pesantemente visto che mi faccio tutta la gestione delle ricette.
Quanto ai fronti io non ho la benché minima lamentela.

Modificato: 27 dicembre 2019 da pigroplc

[acquaman]

Cavolo lamentarsi per il bit del fronte di salita mi sembra un pò esagerato, e comunque per curiosità sono andato a vedere com'è con il codesis, ed è esattamente uguale, a parte Omron che non usa quel bit non so come sono gli altri.

[leleviola]

 

Cavolo lamentarsi per il bit del fronte di salita mi sembra un pò esagerato,

Beh per chi ci ha fattto il callo a tale abitudine non è un problema, quando però fai l'abitudine a non preoccupartene credimi non torneresti più indietro e il mio non un lamento ma uno stimolo a migliorare

[Roberto Gioachin]

Per gli altri sono proprio le istruzioni (P , N , fronti di salita e discesa, ALT) del plc che non hanno bisogno del bit di appoggio, non è un lavoro che fa il compilatore.

[leleviola]

Diciamo che se ce n'è bisogno ci pensa il programma a dedicare l'eventuale memoria dedicata necessaria all'istruzione

[Roberto Gioachin]

 

Diciamo che se ce n'è bisogno ci pensa il programma a dedicare l'eventuale memoria dedicata necessaria all'istruzione

In realtà ci pensa il firmware del plc a fare il tutto, in modo completamente autonomo senza impegnare nessuna memoria di quelle a disposizione del programmatore.

 

convieni con me che sarebbe di sicuro una fonte in meno di errore? 

Sicuramente si, evitare il rischio di utilizzare due volte la stessa variabile per due diversi fronti, significa evitare la possibilità di fare un errore.

Prima o poi ci penseranno anche i tedeschi.

[max.bocca]

Il caro 200 perché progetto Texas non aveva bisogno del bit appoggio, ci pensava il compilatore, solo se facevi le modifiche in Run ti chiedeva di mettere un progresso che però non potevi metterlo dupplicato.

[Cesare Nicola]

PigroPLC

 

oppure semplicemente utilizzare una FB e istanziare il fronte di salita nell'area ritentiva del richiamo dell'FB

Infatti, è quello che faccio di solito, se uso FB. L'istruzione che citavo non l'ho mai utilizzata. Se uso FC, di solito ho una cartella di variabili che contiene merker dedicati ai fronti.

 

Acquaman

 

non so come sono gli altri.

Io, extra Siemens, ho esperienza quasi solo con Mitsubishi e lì il bit di appoggio non esiste. In effetti è molto comodo e quando ritorni a Siemens un po' scoccia dover utilizzare il bit. Non è certo un grosso problema, comunque, ci mancherebbe.

Freccia in su è fronte di salita, freccia in giù fronte di discesa. Ci sono anche per il contatto NC e per la serie di condizioni.

Modificato: 29 dicembre 2019 da Cesare Nicola

[leleviola]

 

In effetti è molto comodo e quando ritorni a Siemens un po' scoccia dover utilizzare il bit. Non è certo un grosso problema, comunque, ci mancherebbe.

Come non condividere tale comodità, purtroppo ci sono "mal abituato" da oltre quindici anni, per quello stimolo a migliorarsi

[Novis]

Salve

pesonalmente ritengo superate dette istruzioni.

Io uso sempre il linguaggio SCL ( PASCAL ) per fare cose simili.

Che ne pensate ?

[batta]

29 minuti fa, Novis ha scritto:

Io uso sempre il linguaggio SCL ( PASCAL ) per fare cose simili.

Anche nel testo strutturato (SCL non è Pascal) ci può essere necessità di rilevare il fronte di un segnale. Non è una operazione legata al linguaggio di programmazione.

In ogni caso, dato che quasi tutti i moderni PLC permettono di utilizzare più linguaggi, io paragono all'autocastrazione scegliere di usare un solo linguaggio.

Io non sono mai stato un amante del ladder, ma non si può certo negare che, per logica booleana, sia il più semplice, il più immediato, e il più facile da debuggare.

Io faccio largo uso del testo strutturato, ma solo per i compiti per i quali è più adatto. Ci possono esser solo due motivi per scegliere di fare tutto in strutturato: il primo, perché non si conosce il ladder (ma, per un programmatore di PLC è una lacuna da colmare), il secondo, per puro masochismo.

[Novis]

Il ladder è un linguaggio superato, desueto. Difficile per il debug, difficile da leggere e da modificare qualora si riprenda un progetto in mano dopo mesi.

Tutti i linguaggi producono codice macchina  booleano.

Cioè o scrivi in KOP, o FUP , o AWL o SCL sempre codice binario  diventa. La CPU esegue solo codice binario.

Il ladder lo usa/usava chi proviene dalla logica dei contatti elettrici. Ma chi proviene dal mondo informatico trova obsoleto pure l'SCL che è strutturato ma non ad oggetti.

Comunque "de gustibus non est disputandum"

saluti

Modificato: 5 gennaio 2020 da Novis

[acquaman]

47 minuti fa, Novis ha scritto:

Il ladder è un linguaggio superato, desueto.

E' quello che pensi tu.

48 minuti fa, Novis ha scritto:

Tutti i linguaggi producono codice macchina  booleano.

Batta parlava di logica boleana, quella parte di programma che gestisce ingressi ed uscita a bit, e condivido a pieno con Batta il ladder è il più semplice ed immediato anche da debuggare, mentre per dati, strutture, calcoli ecc. il testo strutturato non ha pari.

 

[batta]

56 minuti fa, Novis ha scritto:

Il ladder è un linguaggio superato, desueto. Difficile per il debug, difficile da leggere e da modificare qualora si riprenda un progetto in mano dopo mesi.

Se il ladder, nonostante l'età, e nonostante l'integrazione di nuovi linguaggi, è ancora molto usato, un  motivo forse c'è.
Per quanto riguarda l'essere "difficile da leggere e da modificare", è l'esatto opposto di quanto sostieni tu.
Purtroppo, chi arriva ai PLC con una formazione puramente informatica, si trova avvantaggiato su certi compiti, ma svantaggiato sul altri. Ma non lo ammetterà mai, nemmeno sotto tortura: si sentirà sempre più bravo di quell'elettriciaio che programma in ladder. Nulla di più sbagliato.
Per esperienza personale, ti posso dire che, molto spesso, chi ha una formazione informatica, è bravissimo a sviluppare comunicazioni, elaborazione di dati, ed altro, ma si trova molto impacciato, invece, in quello che è il "funzionamento base" della macchina o dell'impianto: tutto va bene se il ciclo procede come dovrebbe, ma quando capita l'imprevisto, non se ne viene più fuori. E, molto spesso, scrive dei programmi che solo lui è in grado di interpretare. Solo quando riuscirà a capire che la programmazione dei PLC non è una programmazione di serie B ma è solo una programmazione differente, solo quando riuscirà ad accettare che per programmare bene un PLC dovrà cambiare completamente approccio, solo allora potrà diventare un vero programmatore di PLC. Questa "trasformazione", di solito, richiede qualche anno. A quel punto, avrà dalla sua anche la preparazione informatica. 
Come già detto, io non amo il ladder, ma è inconcepibile che un programmatore di PLC non lo sappia usare, e non lo sappia apprezzare proprio per la sua immediatezza e semplicità.

Per quanto riguarda la logica booleana, ti ha già risposto Acquaman: quando parlo di logica booleana, non mi riferisco certo al linguaggio binario, che è tutta un'altra cosa, ma a segmenti con combinazioni, anche complesse, di AND e OR di variabili booleane per comandare una variabile booleana.
Faccio un esempio:
 

    pm1        pa1        pa2        em         run
----| |---|----|/|--------|/|--------| |--------( )
    pm2   |
----| |---|
    run   |
----| |---|


run := (pm1 OR pm2 OR run) AND NOT pa1 AND NOT pa2 AND em;

Oppure:
IF (pa 1 OR pa2 OR NOT em) THEN
    run := FALSE;
ELSIF (pm1 OR pm2) THEN
    run := TRUE;
END_IF;

Si tratta di un segmento di una semplicità disarmante. Eppure, non mi vorrai forse dire che è più chiaro scritto in testo strutturato piuttosto che in ladder, spero. Soprattutto quando sei online, in ladder vedi a colpo d'occhio la situazione.
Ripeto quanto detto nel mio precedente post: un programmatore di PLC che non sa usare il ladder (che, probabilmente, viene dal mondo dell'informatica), non è un programmatore più bravo, ma un programmatore con una grave lacuna.
 

[Novis]

2 ore fa, acquaman ha scritto:

E' quello che pensi tu.

.......

 

 

1 ora fa, batta ha scritto:

Se il ladder, nonostante l'età, ......per la sua immediatezza e semplicità.

 

Io uso talvolta il ladder.Per semplici connessioni è facile da leggere ed interpretare.

Ma non mi dite che fare una macchina a stati ( automa ) lo si possa fare in ladder ?

Diverrebbe una cosa micidiale. Sopratutto la gestione delle eccezioni.

Gestione delle eccezioni che Java o C++ mettono a disposizione mentre il sistema TIA Portal S1200  assolutamente no.

Tanto è vero, se non erro , che il s1500 mette a disposizine un altro linguaggio che si chiama STL

 

.

D'altronde se i nuovi sistemi di programmazione mettono a disposizione nuovi linguaggi , significa che saranno usati con più frequenza in futuro.

Comunque niente in contrario a chi usa LADDER.

Io preferisco il funzionale a blocchi e l'SCL.

 

p.s. per me è più semplice leggere la sintassi IF... THEN ....ELSIF..... END_IF;

 

 

Modificato: 5 gennaio 2020 da Novis

[batta]

52 minuti fa, Novis ha scritto:

Gestione delle eccezioni che Java o C++ mettono a disposizione mentre il sistema TIA Portal S1200  assolutamente no.

A parte che non vedo dove sia il problema a gestire una macchina a stati in ladder, mi chiedo se programmi PLC abitualmente o solo occasionalmente.

Il dubbio un po' mi è venuto dal tuo primo post, dove affermavi che non usi i fronti perché programmi in SCL (e definendolo come Pascal). Poi, mi parli delle eccezioni del Java e del C++, che non esistono in TIA Portal e nei sistemi S7 1200/1500. Dimmi, quali PLC conosci che si programmano in Java o in C++?

In quanto ad STL, che in Siemens di solito si chiama AWL, è praticamente il linguaggio a più basso livello, usato ancora nei vecchi S5. Linguaggio che, purtroppo, è sempre meno tenuto in considerazione anche dalla stessa Siemens nonostante, in alcuni casi, presenti ancora qualche punto a favore.

 

1 ora fa, Novis ha scritto:

p.s. per me è più semplice leggere la sintassi IF... THEN ....ELSIF..... END_IF;

Faccio un po' fatica a crederci. In ladder, non devi fare nessun ragionamento, non devi controllare le condizioni vere o false, ti basta uno sguardo, e capisci al volo se e dove manca qualcosa, e cosa manca. Posso mostrarlo anche ad una persona senza alcuna conoscenza né di informatica, né di elettrotecnica, e lo capisce. 

[Cesare Nicola]

13 ore fa, Novis ha scritto:

Ma non mi dite che fare una macchina a stati ( automa ) lo si possa fare in ladder ?

Certo che si può e non è micidiale, dipende solo dal numero di stati. Anche per macchine complesse, comunque, se il numero di passi è elevato, forse era meglio suddividere la funzionalità in più blocchi e quindi ricadere in un numero di stati adeguato. Io uso indifferentemente ladder o SCL, a seconda dei casi.

16 ore fa, Novis ha scritto:

Il ladder lo usa/usava chi proviene dalla logica dei contatti elettrici. Ma chi proviene dal mondo informatico trova obsoleto pure l'SCL che è strutturato ma non ad oggetti.

Il mondo dell'automazione industriale è fatto da programmatori esperti e meno esperti ma anche da manutentori senza grosse basi di programmazione ma che comunque devono mettere mano ai software, anche solo per debug: è una realtà che non si può trascurare. Chi proviene dal mondo informatico è solo una parte dei programmatori, non si può giudicare l'adeguatezza di un linguaggio solo ponendosi da quella parte.

 

13 ore fa, Novis ha scritto:

p.s. per me è più semplice leggere la sintassi IF... THEN ....ELSIF..... END_IF;

Ci mancherebbe, i gusti sono gusti, ma se un contatto è di colore verde, cioè la condizione è vera, lo vedi al volo, non devi ne' leggere ne' interpretare, è innegabile: se poi, come capita spesso, sei a due o tre metri dal PC perché devi premere un pulsante e vederne lo stato, in SCL non ci riesci (non con la mia vista a 50 anni, perlomeno 🙂 )
 

[leleviola]

Scusate l'ignoranza ma in SCL esistono i fronti? Uso lo strutturato o SCL solo per calcoli, se non esistono i fronti è già un vantaggio non da poco del ladder,

il ladder ha dalla sua la facile leggibilità visiva il che non è poco, non penso che il linguaggio compilato del plc sia di facile interpretabilità quando si è a diagnosticare un problema,

nella programmazione a passi i fronti sono tutto nella sviluppo delle varie fasi di attivazione dei passi, infatti sono a loro che si rifà sia il Graph in Siemens ma anche nella programmazione a passi SFC dela Mitsubishi. Bisogna capire che lo sviluppo di un programma non si ferma alla sua fase di sviluppo e scrittura ma anche nell'uso succesivo di ci ne dovrà diagnosticare il problemi nel funzionamento, più è semplice e chiaro un programma più sarà breve il fermo macchina per il cliente