fiorezzz Inserito: 14 luglio 2014 Segnala Inserito: 14 luglio 2014 Salve a tutti Ho questo dubbio sull'utilizzo di SFC58/59 per gestire i telegrammi tra CPU e slave DP ..tipo CU320 ..CU310 ecc.ecc. L’invio/ricezione di telegrammi fatto da SFC58/SFC59 avviene in un “sol colpo”? ..ad esempio io scrivo su PLC 5 word ..queste vengono trasferite verso la periferica quando si riesce a stabilire una comunicazione ..ma stabilità una comunicazione le 5 word sono trasferite in un sol colpo e quindi Anche dall’altra parte lette in un sol colpo ..questo per capire se impostando valori su word diverse in un determinato istante sul PLC ..dall’altro lato prima o poi leggo lo stesso set di valori impostati ..supponiamo che inizialmente ho tutte le word =0 ..poi in un ciclo PLC la word1=1 la word2=2 la word3=3 ecc.. e quindi lancio la SFC58 ..quando dall’altro lato inizio a leggere che la word1=1..nello stesso istante avrò anche word2=2 word3=3 ecc
pigroplc Inserita: 14 luglio 2014 Segnala Inserita: 14 luglio 2014 (modificato) Le SFC sfruttano il tempo libero a disposizione nel Profibus, quindi ci mettono anche più cicli del PLC per trasferire. La valutazione del pacchetto dati viene effettuata al momento del fronte di discesa del busy in concomitanza con il codice di errore uguale a zero. Solamente dopo puoi prendere I valori in lettura e li valuti. Io ho preferito in Passato l'utilizzo delle SFB52-53 in quanto mi restituivano il flag di trasferimento effettuato con il controllo a basso livello, la comunicazione mi sembrava più affidabile o meglio, non dovevo alzare lo start, aspettare il busy quindi abbassare lo start, quindi valutare il fronte di discesa del busy. Con il flag done mi sembrava più semplice. Nei miei impianti non ho mai verificato problemi di tempistiche dovuti alla lettura/scrittura in più cicli macchina in quanto ho sempre solamente scambiato quote di posizionamento e parametri. Parlo di linee con 60-70 servomotori e almeno 15 CU320 con CPU della serie 300. pigroplc Modificato: 14 luglio 2014 da pigroplc
fiorezzz Inserita: 14 luglio 2014 Autore Segnala Inserita: 14 luglio 2014 Ok che il trasferimento del telegramma impieghi anche non cicli PLC ...la cosa potrebbe anche reggere se quando trasferisce lo fa im modo completo mi spiego meglio se due input vanno a ON nello stesso momento anche se arrivano sul PLC dopo 10ms li vedo entrambi ON nello stesso ciclo se però uno arriva in un istante T1 e l'altro in un'altro istante T2 la cosa si fa più seria
pigroplc Inserita: 14 luglio 2014 Segnala Inserita: 14 luglio 2014 Allora io mi chiedo a cosa ti serve questa cosa? io ci ho letto parametri e scritto parametri dei Sinamics. Cosa ti frega se un numero arriva dopo l'altro? Idem in ricezione. io ho trasferito botte di 64 quote per poi lanciare I blocchi di funzionamento. Cosa cambia se anche uno arriva un pizziconanosecondo rispetto alla quota successive, visto che poi parti con l'asse quando tutto il treno di quote è arrivato? Se proprio ti serve ricevere e spedire 2 bit ti fai il tuo telegramma personalizzato (come feci a suo tempo) e ti fai tutto come ti aggrada. Le SFC/SFB le usi per smazzare dati importanti (quindi comunicazione aciclica) mentre per il resto usi la comunicazione ciclica dei telegrammi. Forse non capisco I tuoi dubbi, illuminami. pigroplc
fiorezzz Inserita: 14 luglio 2014 Autore Segnala Inserita: 14 luglio 2014 Il dubbio è questo ..ho avuto problemi perchè alzando nello stesso ciclo PLC il bit.di startare asse e dando il Nr.del blocco posizionatore da eseguire ...il posizionatore ha eseguito il Nr.Blocco che avevo scritto in precedenza ed essendo un movimento in relativo ha spostato asse in una posizione non voluta
fiorezzz Inserita: 14 luglio 2014 Autore Segnala Inserita: 14 luglio 2014 Però mi sembra abbastanza scontato che essendo in perenne scrittura o lettura del telegramma i dati in esso contenuti possano arrivare un po alla volta però mi chiedo sempre ..se sto leggendo una quota su 2 dword(4Byte) ..la quota cambia ..ma se la lettura delle 2dword avviene in due fasi mi trovo dei numeri che nulla hanno a che vedere una dword contiene già numeri nuovi l'altra contiene ancora vecchio valore
vitali mario Inserita: 14 luglio 2014 Segnala Inserita: 14 luglio 2014 usa gli sfcsolo per scrivere idati degli assi o i blocchi di movimento. La selezione del blocco da esegiure la trovi nel telegramma standard 110.
pigroplc Inserita: 14 luglio 2014 Segnala Inserita: 14 luglio 2014 quoto vitali mario. io te l'ho già spiegato ma mi sa che non sono stato chiaro. pigroplc
fiorezzz Inserita: 14 luglio 2014 Autore Segnala Inserita: 14 luglio 2014 Non capisco ..probabilmente mi manca qualche nozione Gi SFC58/59 sono proprio usati per lo scambio dati tra PLC e CU320 con un telegramma tutto personalizzato (anche se al 80/90% è simile a telegrammi standard ) ..il progetto l'ho ereditato da altri ..io da PLC non faccio altro che attivare dei Merker per scrivere nel "tabellone " del posizionatore (con dati messi du DBxx) e poi attivo il.nr.blocco e start per far partire asse ..ripeto il dubbio che ho è la selezione contemporanea da PLC del NrBlocco da eseguire e il bit da attivare per far partire il movimento
pigroplc Inserita: 15 luglio 2014 Segnala Inserita: 15 luglio 2014 Allora, il PLC e CU dialogano tramite Profibus(Profinet attraverso un telegramma che trovi pure nella configurazione hardware. Quella area di memoria che dipende dal tipo di telegramma è l'interfaccia dove sono mappati I vari start, reset ecc e altre informazioni tipo il numero di blocco da eseguire oppure la quota in MDI. Guarda bene ma secondo me SFC58/59 servono a trasferire ad esempio I blocchi di posizionamento (soluzione sulla quale ho già espresso il mio parere) e NON servono a scambiare I comandi di movimento. Mi immagino che chi ha fatto il programma ha appoggiato l'area di scambio su una DB e richiama il blocco n volte quanti sono gli assi. Al termine dell'esecuzione edl blocco stesso si scrive sulla periferia ed ecco che magicamente la CU esegue il commando. Io guarderei l'applicativo se per caso aggiorna il numero di blocco anche solamente un ciclo macchina in ritardo rispetto allo start. pigroplc
fiorezzz Inserita: 15 luglio 2014 Autore Segnala Inserita: 15 luglio 2014 Ok in effetti prima di richiamare le SFC c'è una parte di codice eseguita sempre che legge/scrive dagli indirizzi della CU ...tipo A220 E220 e trasferendo/leggendo da una db su cui io vado a lavorare ... Quindi posso concludere che lo scambio dati con telegramma è automatico non bisogna scrivere codice per trasferire questi telegrammi ..capito poi uso SFC ... Chiaro che da quando scrivo sulla DB ..a quando l'informazione arriva dall'altro lato potrebbe passare anche + cicli PLC Il dubbio che mi rimane è questo ...mentre su PLC trasferisco dalla mia db alla AWxx del telegramma e lo faccio sicuramente in un giro PLC (vengono lette non.dword e scritte non.ADw )..il telegramma continua a essere inviato ? o viene inviato alla fine di OB1 ?dato che che si usano le PAW ..PEW ..accesso diretto a periferia ..per scrivre/leggere dal telegramma ?
fiorezzz Inserita: 15 luglio 2014 Autore Segnala Inserita: 15 luglio 2014 Per meglio esprimere il mio dubbio finale ...quello che mi chiedo è se alla fine l'invio di un telegramma è== ad un aggiornamento dell'immagine di processo ..ovvero faccio una "foto" del valore delle word (alle non.word componenti il telegramma ) e le invio ..quando arrivo dall'altro lato aggiorno di nuovo "l'immagine di processo" e rendo disponibili in un sol colpo tutti i valori delle word del telegramma ...poi ripeto il ciclo ..nel PLC leggendo lo stato dei vari IO sia che lo faccio alla prima riga sia che lo faccio all'ultima riga dopo non.ms il vlore letto è sempre lo stesso (a meno di fare un accesso a periferia fuori ovvero anziche leggere E10.0 faccio L PEW 10 T MW10 u m10.0 se non mi sbaglio queste ultime 3 righe di codice messe ad inizio programma PLC o alla fine può dare esisto diverso se E10.0 cambio nel frattempo di stato
pigroplc Inserita: 15 luglio 2014 Segnala Inserita: 15 luglio 2014 Il tempo ciclo di aggiornamento della periferia dipende dal tempo del Profibus e non dal ciclo macchina del PLC. Siccome non conosco il tuo software devo immaginare che chi ha sviluppato il software: 1) copia il contenuto della periferia e lo trasferisce nella DB del tipo L PED xxx T DBzzz.DBD0 ecc 2) elabora I segnali e prende le decisioni 3) aggiorna la periferia del tipo L DBzzz.DBD40 T PAD xxx ecc Io non ho mai avuto bisogno di utilizzare SFC14/15 con I Sinamics in quanto non ho mai avuto problem di ritardi che evidenzi tu. Certo è che se se il PLC aggiorna la periferia quando oramai il Profibus ha già interrogato il partecipante vuol dire che la CU riceverà il comando il ciclo successivo. pigroplc
fiorezzz Inserita: 15 luglio 2014 Autore Segnala Inserita: 15 luglio 2014 Ok ..perfetto ..mi manca un tassello NEL .PLC L DBD100.DBD0 T PAD200 L DB100.DBD4 T PAD204 ..dall'altro lato (Sinamics??) quando leggo la PAD200 e la PAD204 sono le stesse scritte sopra ...non si corre rischio che leggo la PAD200 con nuovi valori e la PAD204 con valore precedenti non ancora allineati alla nuova scrittura che sto facendo
fiorezzz Inserita: 15 luglio 2014 Autore Segnala Inserita: 15 luglio 2014 per intenderci è la stessa consistenza dati che cercavo nel DP COUPLER
pigroplc Inserita: 15 luglio 2014 Segnala Inserita: 15 luglio 2014 Io ho in giro impianti da oramai quasi 10 anni con Sinamics-CU320 DP-S7 317 2DP che funzionano con questo concetto e ti posso assicurare che le linee di produzione lavorano almeno 6 giorni e mezzo su 7 su 3 turni senza problemi. Presumo quindi che la CU abbia la coerenza del messaggio altrimenti avrebbe preso lucciole per lanterne. pigroplc
fiorezzz Inserita: 15 luglio 2014 Autore Segnala Inserita: 15 luglio 2014 Ok ..grazie ..quando avrò a disposizione dell'hw lo riproverò ... .ti dico la mia esperienza con uso FC21 (Scrittura/Lettura DualRam tra PLC e CN 840Sl ) siemens dava per certificato solo la consistenza su due byte senza usare semafori ..io dovevo usare 4byte (dovevo trasmettere un quota in real) sembrava che funzionasse ugualmente senza semaforo..e ha funzionato per 2 mesi ..un giorno ebbi la sorpresa per piu di un ora anche dopo aver riavviato + volte CN a quel punto ho dovuto fare una correzione per essere sicuro di leggere 4 byte consistenti perchè il PLC impiegava + cicli ad aggiornare mentre il cn era + veloce Grazie mille delle info
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