pask1983 Inserita: 9 maggio 2011 Autore Segnala Inserita: 9 maggio 2011 (modificato) per quanto riguarda l'"A1.4"l'ho scritto a titolo di esempio, nella FC userei una nome tipo errore_valvolae per ogni valvola gli assocerei il suo indirizzo , quindi dovrebbe funzionare (se non ho capito male)per quanto riguarda l'E0.1voglio comandare lo stato di quell'ingresso, sempre se mi è possibile (ma a quanto pare non lo è), per mandare un messaggio all'OB in modo da attivare la FC EMERGENZA ovvero, se va in errore un controllo su di una valvola, l'OB mi deve chiamare l'FC emergenza come se fosse stato premuto il "fungo" di emergenza (che è un contatto normalmente chiuso, quindi avrei dovuto usare R E0.1 , invece di = E0.1 ... ma era solo a titolo di esempio... )quindi se non è possibile devo utilizzare un'altra "strada" ... ma non so... devo utilizzare un'uscita oppure un merker? o come devo fare?volevo evitare di chiamare direttamente l'FC emergenza in caso di errore per riuscire a scrivere un programma più "pulito"mi sa che la via è questa:OBUN E0.1 // se è stato premuto il fungo (contatto normalmente chiuso)O M0.1 // se il merker M0.1 è =1 CALL emergenzae nella FC apri-chiudi-valvola......... // in caso di errore= M0.1giusto?però come dovrei resettare il merker? con un altro ingresso manuale del tipo "a fine programma di emergenza resettare i messaggi ed i segnali di errore" ?tipo:in OBU E1.1 // se è stato premuto il tasto di "fine emergenza"R A1.4// spegni il led "errore valvola 1"...R M0.1 // resetta il merker Modificato: 9 maggio 2011 da pask1983
batta Inserita: 9 maggio 2011 Segnala Inserita: 9 maggio 2011 quindi se non è possibile devo utilizzare un'altra "strada" ... ma non so...Possibile è possibile. Solo altamente sconsigliato.Tieni presente poi che lo stato dell'ingresso lo dovresti scrivere prima di tutte le istruzioni che interrogano quell'ingresso.Questo perché l'immagine degli ingressi viene aggiornata, con il reale stato fisico degli ingressi stessi, all'inizio di ogni scansione.Il programma quindi vede lo stato alterato solo dal punto in cui si effettua l'operazione di scrittura in avanti.Comunque, ripeto: scrivere lo stato di un ingresso va bene solo ed esclusivamente per simulazioni. E' assolutamente da evitare in tutti gli altri casi.UN E0.1 // se è stato premuto il fungo (contatto normalmente chiuso)O M0.1 // se il merker M0.1 è =1CALL emergenzaQueste istruzioni invece sono sbagliate. L'idea, richiamare cioè la funzione "Emergenza" se manca E0.1 oppure se c'è M0.1 potrebbe funzionare.Dico potrebbe, perché è tutto da vedere se è corretto o meno gestire l'allarme di una valvola come una emergenza. Tutto dipende dall'impianto.Quello che non funziona però è che l'istruzione CALL non è minimamente influenzata dallo stato dell'RLC.Nel caso dell'esempio la funzione "Emergenza" verrebbe quindi eseguita sempre, indipendentemente dallo stato di E0.1 e di M0.1.Se la funzione "Emergenza" è una funzione senza parametri, al posto di CALL potresti utilizzare l'istruzione CC (Richiamo Condizionato).Per condizionare l'esecuzione di una funzione richiamata con l'istruzione CALL si devono usare i salti.Esempio:UN E0.1 // se è stato premuto il fungo (contatto normalmente chiuso)O M0.1 // se il merker M0.1 è =1SPBN _000CALL emergenza_000: NOP 0Riguardo il reset eventuale di M0.1, scrivendo la funzione come da esempio, lo stato di M0.1 è scritto direttamente dalla funzione di controllo valvola.Se la condizione di errore sparisce, M0.1 verrà messo a zero dalla funzione di controllo valvola.Se la condizione di errore persiste, sarà inutile resettare M0.1 perché verrà continuamente reimpostato a 1 dalla funzione di controllo valvola.
pask1983 Inserita: 13 maggio 2011 Autore Segnala Inserita: 13 maggio 2011 :thumb_yello: che dire... grazie assai! 30/30 ovviamente il programma del corso non era solo linguaggio AWLma :- sistemi elettronici di potenza, quali diodi, tiristori, mosfet gto ... etc etc e loro utilizzo (in monofase e trifase ) - macchine sincrone, asincrone, brushless - plc , caratteristiche, scelta di una cpu, liguaggi di programmazione e progetto (nel mio caso la gestione di una centrale idroelettrica ) con programmazione in AWLovviamente essendo un esame del corso di ing. meccanica, a corredo vi erano dimostrazioni e calcoli vari
pask1983 Inserita: 13 maggio 2011 Autore Segnala Inserita: 13 maggio 2011 (modificato) Per condizionare l'esecuzione di una funzione richiamata con l'istruzione CALL si devono usare i salti.Esempio:UN E0.1 // se è stato premuto il fungo (contatto normalmente chiuso)O M0.1 // se il merker M0.1 è =1SPBN _000CALL emergenza_000: NOP 0grazie, infatti così ho fatto l'unica cosa, nel flow chart il programma mi andava a "fine" ogni volta che si entrava in una delle sottofunzioni "principali" (ad esempio quelle di emergenza)in pratica ho messo (nell'OB1)UN "SE" // se non è attivo il merker di emergenzaU "PE" // e se non è stato premuto il pulsante di emergenza (contatto NC)spbn s001 // se rlc=0 saltacall emergenza s001: nop 0in questo caso dopo l'esecuzione della funzione "emergenza" , la cpu mi continua a scorrere le istruzioni successive, ma nel flow chart non deve farloallora per fare questo ho inserito: (nell'OB1)UN "SE" // se non è attivo il merker di emergenzaU "PE" // e se non è stato premuto il pulsante di emergenza (contatto NC)spbn s001 // se rlc=0 saltacall emergenzaspb fine s001: nop 0ed ho posizionato nell'ultimo segmento dell'OB1:"segmento 20"fine: nop 0in pratica, quando mi serviva "tagliare" il resto del programma, lo facevo con una funzione di salto a "fine" ci sono altri metodi? Modificato: 13 maggio 2011 da pask1983
JumpMan Inserita: 13 maggio 2011 Segnala Inserita: 13 maggio 2011 Per terminare un blocco ci sono le istruzioni BEA (fine incondizionata del blocco) e BEB (fine condizionata dall'RLC)
batta Inserita: 13 maggio 2011 Segnala Inserita: 13 maggio 2011 Se nel tuo diagramma di flusso risulta che, dopo l'esecuzione della subroutine delle emergenze si deve terminare l'elaborazione, allora la tua soluzione va bene.Saltare alla fine del blocco, oppure terminare l'elaborazione del blocco con BEA o BEB, porta allo stesso risultato.Quello che mi lascia invece perplesso è il diagramma di flusso.Per una semplice esercitazione mi sta anche bene saltare tutto quando sono in emergenza.Nella pratica invece un approccio simile raramente risulta essere corretto.Solo per citare il caso più banale, anche se sono in emergenza, segnalazioni, letture di valori analogici, diagnostica, devono comunque funzionare.Ma sono moltissimi i casi in cui, in emergenza, si devono attivare procedure particolari.Certo, queste procedure potrebbero essere gestite all'interno della subroutine "Emergenza", ma questo significherebbe, in moltissimi casi, duplicare parti di software già esistenti, che andrebbero invece solo integrate con l'informazione di Emergenza, e non certo saltate a piè pari.Non è raro, a dire il vero, trovare diagrammi di flusso come questo. Di solito sono scritti da persone che conoscono il processo, ma non la programmazione.Per chi non sa come si programma un PLC è semplice dire: ferma tutto ed esci. Ma non è quasi mai la procedura corretta.
JumpMan Inserita: 13 maggio 2011 Segnala Inserita: 13 maggio 2011 (modificato) Il primo errore che fanno molti è considerare il programma plc come una sequenza di istruzioni che hanno un inizio e una fine, questo può essere valido nell'ambito di un linguaggio di programmazione di un PC ma non certo in quello di un PLC!Nel plc le istruzioni vengono ciclate continuamente dalla prima all'ultima e poi ripartono nuovamente dall'inizio e così via all'infinito.Il tempo di scansione dell' OB1 non deve superare il limite impostato nei dati di sistema (il cosidetto watchdog) altrimenti la cpu va in stop, il programma non può p.es. fermarsi ad attendere un segnale, deve andare avanti fino alla fine di OB1 entro il tempo stabilito.Come ti ha già detto batta, non è corretto (ed è anche poco leggibile) scrivere un programma AWL pieno di salti, ed è anche difficile da gestire quando vai a "debuggare" online! Le istruzioni non elaborate, o meglio, elaborate solo per un istante sono abbastanza difficili da controllare. Personalmente non mi piace neanche settare e resettare lo stesso merker in 1000 posti (poi magari me lo trovo TRUE e non so chi è il colpevole ), preferisco usare l'istruzione di assegnazione (=) una sola volta, ma questa è una mia abitudine.Domanda, devi per forza usare l'AWL o puoi usare anche KOP e FUP ? Modificato: 13 maggio 2011 da JumpMan
Messaggi consigliati
Crea un account o accedi per commentare
Devi essere un utente per poter lasciare un commento
Crea un account
Registrati per un nuovo account nella nostra comunità. è facile!
Registra un nuovo accountAccedi
Hai già un account? Accedi qui.
Accedi ora