gfkat Inserito: 24 marzo 2016 Segnala Share Inserito: 24 marzo 2016 Ciao a tutti gli utenti del forum, questa è la mia prima discussione spero di essere piuttosto chiaro. Ho sempre dato per scontato che la comunicazione con le aree di memoria del PLC via snap7 (http://snap7.sourceforge.net/) avvenisse prima dell'esecuzione dell'OB1 da parte dei PLC. Tutto il mio software si regge su questa ipotesi. Ora però mi sto rendendo conto che probabilmente non è così, infatti, a volte i dati letti da PC sono incoerenti con quanto scritto nelle DB. E l'unica spiegazione che sono riuscito a dare è che il PC accede in lettura nello stesso istante in cui il PLC accede in scrittura. Se volete posso entrare nel dettaglio per farvi capire come sono quasi totalmente certo di questa cosa. Ora vi chiedo, e lo chiedo soprattutto a Davide che ci ha donato lo snap7 (Grazie infinite!), se avete già affrontato questo tipo di problematiche e come avete risolto senza gravare troppo sulle prestazioni del PLC e dei software PC. La mia soluzione temporanea è quella di utilizzare un Merker di abilitazione alla comunicazione sul PLC, di settare questo merker ad inizio esecuzione dell'OB1 e tenerlo alto per 10/15 ms tenendo il PLC in loop, scaduto il tempo eseguire le istruzioni dell'OB1. Capite però che quest'operazione comporta un aumento consistente del tempo ciclo e non è sempre adottabile (sopratutto in applicazioni complesse). Grazie infinite per la vostra disponibilità, Ciao, Luciano. Link al commento Condividi su altri siti More sharing options...
84paolo Inserita: 24 marzo 2016 Segnala Share Inserita: 24 marzo 2016 Ciao. Per fare quello che hai detto basta usare delle db di appoggio. Per esempio se i comandi sono nella db10, crei un'altra db identica tipo db110. Dallo snap7 punti sul db110 e poi nell'ob1 fai una copia del db110 sul db10. Stessa cosa per le uscite. Link al commento Condividi su altri siti More sharing options...
stilnovo Inserita: 24 marzo 2016 Segnala Share Inserita: 24 marzo 2016 La comunicazione S7 è asincrona rispetto al programma OB1, ed è un bene. Immagina in caso contrario le ripercussioni sul tempo ciclo in caso di pesanti carichi di comunicazione. La tua soluzione 'temporanea' non va bene nemmeno in caso di vita o di morte, è del tutto sbagliata. Innanzitutto, chi ti assicura che il pc legga la tua DB durante quel tuo loop, ma che non lo faccia comunque dopo durante l'esecuzione di OB1 ? La soluzione è una sola, a mio avviso, ossia di congelare i dati finché il pc non li abbia acquisiti. Potresti usare un bit che il PLC scrive a 1 per dire "DATI SCRITTI/PRONTI PER LETTURA", il quale viene azzerato da PC quando questi ha completato l'acquisizione. Con il bit a 1 il PLC non scrive, con il bit a 0 il pc non legge. Link al commento Condividi su altri siti More sharing options...
dan64100 Inserita: 25 marzo 2016 Segnala Share Inserita: 25 marzo 2016 Ti confermo quanto scritto da Stilnovo : la comunicazione Partner <-> PLC è completamente asincrona rispetto ad OB1 (dove Partner può anche essere un altro PLC che usa GET/PUT). Aggiungo inoltre, non per sadismo ma per evitarti ulteriori mal di testa in futuro: - Il pacchetto dati contenuto nel telegramma può essere trasferito dal buffer del processore di comunicazione alla DB anche in più giri di OB. - Non c'è alcun modo di capire da programma se il processore di comunicazione abbia trasferito dei dati (in lettura o scrittura). Detto questo hai due strade: o usi Snap7 ed implementi un handshake fra PC e PLC oppure invii/ricevi i pacchetti dati utilizzando le funzioni di comunicazione TCON,TDISCON,TSEND,TRECV. La seconda opzione è più semplice dal punto di vista della sincronizzazione : mandi il pacchetto quando ti serve e sai che è consistente. Di per contro aumenti la complessità dei programmi, devi scrivere un mini server lato PC e gestirti connessioni/disconnessioni/errori lato PLC (ed è una rogna). Se usi Snap7 puoi usare una variabile di scambio che poni alla fine della DB : - Scrivi i dati nella DB - Metti a 1 la variabile - Entri in uno stato di attesa non bloccando OB1 ma come se aspettassi che un cilindro sia arrivato a fine corsa (l'automazione va gestita così non con i loop ). Nel frattempo il PC acquisisce continuamente il buffer, se trova la variabile di scambio ad 1 considera il pacchetto valido ed azzera la variabile (la scrive nel PLC), altrimenti scarta il pacchetto il quale conterrà nulla o dati non consistenti. Lato PLC esci dallo stato di attesa quando trovi la variabile a zero e ricomincia tutto. Se vuoi sincronizzare dei dati da PC a PLC è più semplice : i dati vengono sempre trasferiti sequenzialmente dal buffer di comunicazione alla memoria per cui: - Predisponi una variabile alla fine del tuo record che sarà sempre ad 1. - Il PC trasferisce i dati in una DB di appoggio. Il PLC ad ogni giro di OB controlla la variabile : se è ad 1 sei certo che tutti i dati precedenti sono validi per cui copi la DB di appoggio in quella di lavoro ed azzeri la variabile nella DB di appoggio. Se hai necessità di di un controllo accurato dovresti verificare con il PC che quella variabile sia 0 prima di scrivere un altro pacchetto. Alla fine sono due semplici macchine a stati da modellare, come quando gestisci un marcatore laser o un altro equipment che ha dei tempi di esecuzione non sincroni ad OB1. Ciao Davide Link al commento Condividi su altri siti More sharing options...
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