SCL info implementazione trigger in TIA 13

[crc-error-79]

Apro un secondo 3d perchè avrei un'altra domanda riguardante i trigger.

Nel progetto di test che sto facendo ho aggiunto il trigger e tia mi fa aggiungere 1 db per ogni ingresso da controllare, è corretto?

 

Eventualmente è possibile usare un DB unico per tutti gli ingressi da controllare?

Grazie ancora

[pigroplc]

nel vecchio S7 si poteva creare una FB all'interno della quale creare delle istanze di richiamo della FB del trig.
Ne ottenevi una DB unica, con tanti blocchetti che non erano altro che i dati del singolo richiamo.

Su Simotion si dichiarano le istanze come variabili e si risolve tutto.

Se nel blocco SCL è possibile dichiarare delle variabili di tipo FB1002 (prendo spunto dalla tua foto) sono sicuro che si possa fare.

[crc-error-79]

Ok, grazie.

 

non ero sicuro che come ho fatto fosse la maniera corretta.. 

 

Grazie ancora

[Cesare Nicola]

Secondo me è questione di cambiare "filosofia". Mi spiego. Anche a me non sta simpatico vedere una DB per ogni fronte (e nemmeno per ogni timer) e mi ero posto le tue stesse domande. Poi, man mano che ho preso dimestichezza con TIA, ho iniziato ad infischiarmene allegramente; le DB che crea sono nella cartella "risorse del programma", dove non ci vai quasi mai. Lo spazio che occupano non lo so e non l'ho mai verificato, ma immagino che si trascurabile. Insomma, se quello è il modo di lavorare di TIA lascio fare a lui, io mi concentro sul mio software e mi godo l'utilizzo di TIA che, a differenza di molte critiche che sento, trovo sia davvero piacevole e rapido da utilizzare. La stessa cosa la sto facendo con le variabili; io scrivo il nome e lascio definire a TIA l'indirizzo. Che mi frega che il "pulsante_start" sia associato a M0.0 o M98.7? A me serve il pulsante start, poi faccia TIA. Ci sono ovviamente eccezioni a questa "filosofia", le applicazioni e le problematiche sono quasi infinite.
Tornando ai trigger, se proprio vuoi, si possono fare senza DB, con queste istruzioni che ho "ereditato" da un progetto fatto da altri, su cui ho lavorato. #segnale è la variabile di trigger, #fronte è il fronte che viene generato, #auxfronte è una variabile di appoggio.

 

FRONTE DI DISCESA IN SCL
#Fronte := NOT #Segnale AND #AuxFronte;
#AuxFronte := #Segnale;

 

FRONTE DI SALITA IN SCL
#Fronte := Segnale AND NOT #AuxFronte;
#AuxFronte := #Segnale;

Ciao

[batta]

Confermo che si può inserire l'istruzione R_TRIG (o F_TRIG) come multiistanza.

Personalmente però utilizzo il metodo suggerito da Cesare, con una piccola variante nel rilevamento del fronte di salita:

 

#FronteSalita := #Segnale AND #xFronteSalita;
#xFronteSalita := NOT #Segnale;

 

Qual è la differenza?

Nell'esempio di Cesare, se si avvia il PLC con segnale alto viene contato subito un fronte di salita.

Nell'altra maniera invece vengono contati solo i cambi di stato (all'avvio del PLC non si contano fronti).

In alcuni casi la differenza può essere trascurabile, in altri no.

 

C'è da dire che anche con la funzione R_TRIG se il segnale è già alto viene rilevato un fronte di salita.

[Mingus73]

Buongiorno,

mi inserisco in questa discussione, seppure a distanza di tempo, per  approfondire certi aspetti della faccenda secondo me interessanti.

 

Le mie osservazioni:

 

1) Le funzioni R_TRIG (o F_TRIG) non sono disponibili in tutte le CPU Siemens. Si trovano disponibili tranquillamente per una 1214C.ad esempio, ma non per una 313C; in quest'ultimo caso, non esiste alcuna funzione predefinita in Tiaportal (V15) per rilevare i fronti, né in SCL né in altro linguaggio! Trovo assolutamente curioso il fatto che il programmatore debba provvedere "con mezzi propri"...vista la diffusione di queste funzioni di fatto indispensabili in un programma PLC di un certo livello. Vero che ormai le CPU 300 sono al tramonto….ma il discorso generale per me è questo: in ogni CPU dovrebbero essere garantite "embedded"  TUTTE  le funzioni di base necessarie alla "programmabilità" di ogni logica, ed in queste rientrano sicuramente i fronti di salita e discesa, oltre che temporizzatori e contatori… Chiedo lumi ai più esperti in merito a questo aspetto: potrei essermi ingannato.

 

2) a proposito di "mezzi propri", ho trovato interessante il confronto tra due metodi proposti da CESARE NICOLA e poi da BATTA. Io personalmente ho sempre usato il metodo di Cesare, trovandolo più "intuitivo" come scrittura. Per risolvere la faccenda dell'avvio del PLC ho sempre usato un timer generale che disabilita, nei primi istanti di tempo computati (dell'ordine dei secondi, a seconda delle necessità), tutto ciò che deve essere disabilitato all'avvio del sistema, come ad esempio la lettura di alcuni sensori...

 

Cordiali saluti a tutti.