Fm357-2 - Funzioni M che non vengono emesse...

[Supertony]

Uso un'FM357-2 per realizzare un pick-and-place. La macchina preleva del prodotto da un piano di presa e lo deposita in un cartone. Per rendere il movimento continuo, evito di utilizzare cicli CASE o IF per verificare la presenza del prodotto o del cartone, ma al contrario faccio emettere alla scheda delle funzioni M durante il movimento. Poi tacito immediatamente dal PLC le funzioni se le condizioni per arrestare il movimento non ci sono, e quindi il ciclo non viene interrotto. Più in dettaglio, mentre ad esemio il robot si avvicina alla presa emetto un M64 ("G01 X200 Y200 M64"), che taciterò dal PLC immediatamente se il prodotto è già pronto per essere preso; in caso contrario gli assi si arresteranno nella posizione finale del movimento, sensa eseguire il movimento successivo (che sarebbe la presa del prodotto). ORBENE, il problema è che quando supero una certa velocità degli assi (anche solo un override del 40% con accelerazioni sostenute), "perdo" la funzione "M", ovvero il movimento inizia e finisce prima che il PLC abbia "visto" la funzione; risultato, la macchina scende in presa anche senza il prodotto sottostante. Qual'è il modo ottimale per gestire la tacitazione delle funzioni M? Oppure.... c'è un modo migliore per vincolare un movimento a delle condizioni senza che però il movimento ne risenta in raccordi e fluidità se le condizioni sono già presenti?

P.S.: se uso istruzioni di IF e CASE per controllare condizioni, il movimento non esegue raccordi e raggiunge esattamente il punto finale, per poi ripartire, cosa assolutamente da evitare in una operazione di handling come quella che sto programmando.....

.... URGENTEEEEEEEEEE!!!!!!

Grazie

[Gabriele Corrieri]

Ciao

in genere mi scoccia assai tanto rispondere quando nel post ci sono parole tipo ., URGENTE, .... però la cosa quando riguarda simatic mi interessa quindi faccio notare ma soprassiedo .

Premetto che non ho mai usato FM357, ma credo che il tuo problema risieda principalmente nel fatto che FM357, essendo una NCU di un certo livello, se non erro è il controllo del Sinumerik 840DI scatolato sul rack del 300, è molto veloce nell'eseguire i jobs, e il 300 (poverino) fa quel che può ... che CPU hai montato?

L'unica soluzione sarebbe quella di mettere la funzione che tacita la funzione M in un OB schedulato a tempo, tipo un OB35, oppure se è possibile cercare di scatenare un Interrrupt da FM357 verso la CPU e a quel punto inserire nella routine di INT il codice di tacitazione della funzione M.

Ciao

[Gabriele Riva]

Gabriele Corrieri+20 Aug 2004, 09:23 PM-->

ho modificato il titolo della discussione...

[Ivan Castellaro]

Non so se esiste sulla fm, ma dovresti inserire nel programma cn un'istruzione che arresta la preelaborazione del programma dove metti la M e vedere se ti esegue lo stesso il raccordo. Un altra alternativa è provare a guardare se c'è un datpo macchina che ti indica quantie righe di programma preelabora e ridurlo drasticamente (tipo 1 riga).

Un ultima soluzione che mi viene in mente è quella di fare le M bloccanti per il cn (non so se si puo' fare bisogna vedere i DM) e quindi se da plc non l'hai ancora vista al massimo si stoppa il cn.

La cosa che non mi piace di siemens è proprio quella di avere una cpu cn e una plc che non sono per nulla sincronizzate.

[Ivan Castellaro]

Mi sono scaricato il manuale e gli ho dato uno sguardo veloce.

Mi sa che le mie soluzioni non sono applicabili. Di DM si sono sprecati a metterne! Lo STOPRE fa effettuare uno stop preciso!

Secondo me ho trovi qualcosa con le "Azioni sincrone" ma non mi sono addentrato piu' di tanto su come funzionano oppure devi fare un barbatrucco non molto bello, ti spiego:

in pratica se devi andare da "A" a "C" passando da "B" ora tu fai:

G01 ..... M64 // Vai a B e aspetti se non puoi andare in C

Mentre la mia idea è , quando sei in A e hai le condizioni per andare da C, non metti la M altrimenti si.

Es

// posizione a

IF .... // condizioni ok

G01.....

G01.....

ELSE

G01 ..... M64

STOPRE

G01

ENDIF

Altro non so dirti... Buona fortuna!

[Supertony]

Vi ringrazio per i preziosi consigli, domani e domenica ( ) cercherò di mettere tutto insieme e trovare una soluzione... colgo l'occasione per scusarmi dell'"URGENTE" che ho "osato" mettere nel titolo, ma il fatto è che il problema l'ho riscontrato questa sera nell'accelerare la macchina per raggiungere la produzione richiesta dal cliente, e lunedì mattina la devono smontare e spedire... per cui mi restano solo SABATO e DOMENICA per cercare e TROVARE una soluzione!!! Ringrazio ancora chiunque abbia anche solo preso in considerazione il mio "appello" !!!

P.S. per Ivan: ti ringrazio per la soluzione proposta, è quella che ho già "volgarmente" attuato per fare funzionare il tutto temporaneamente; il fatto è che però fra la posizione "A" e "C", come dici tu, ci dono una mezza dozzina di percorsi intermedi che emettono altrettante funzioni M, il tutto senza arrestare la corsa e gli smussi dei 2 assi, pertanto non posso prevedere così tanti casi... il software CN diventerebbe illeggibile e poco flessibile.

Ah, dimenticavo di dire che la CPU è una 314c 2DP, il tempo ciclo è sui 20ms, e il problema si presenta solo da quando ho dovuto ridurre le corse fra un punto e un altro e aumentare le velocità di movimento... in pratica il CN ha molto "meno tempo" per emettere suddette (maledette!!!) funzioni....

[Ivan Castellaro]

Facci sapere se e copme risolvi!

[Supertony]

Questa mattina ho provato a fare molte prove diverse di gestione dei segnali di scambio con l'FM, compresa la tacitazione delle funzioni M, ma niente da fare; alla fine è cambiato qualcosa solo riducendo l'avanzamento dei movimenti (da "F20000" a "F7000", per esempio). Una cosa curiosa è che in seguito ad un cambiamento di velocità apparentemente non visibile a occhio (per esempio perchè associato ad un tratto corto con accelerazioni non spinte) le funzioni M sono molto più gestibili dal PLC....

[Ivan Castellaro]

Hai provato a fare una routine per le M che gira in un Ob35 come suggerito da gabriele e impostare il richiamo del Ob35 a 8ms?

[Supertony]

Sì, avevo provato a 5msec ma senza risultato... ... poi ho notato anche un'altra cosa: anche il segnale di STOP PREELABORATORE (un bit del DB100) che uso per arrestare alcuni movimenti, a volte l'FM non riesce a rilevarlo in tempo, e si arresta alla fine del movimento successivo... anche in questo caso ho provato a richiamare in diversi modi l'FC di comunicazione, ma niente da fare... però mi sembra strano che per una scheda del genere ci si debba accontentare di un sistema di scambio dati così asinncrono e "grezzo".... deve esserci una soluzione migliore. Ho contattato l'hot-line della Siemens, ma.... non mi hanno più richiamato, 'sti asini!!!! :ph34r:

[wally]

Non ho mai usato la FM357-2, pero' ho usato le FM453 e 353, nel tool di configurazione delle FM c'e' un dato macchina che definisce la modalita' di gestione delle funzioni M, tipo (vado a memoria) :

- emissione funzioni M durante il posizionamento con reset da PLC

- emissione funzioni M dopo il posizionamento con reset da PLC

- emissione funzioni M a tempo ( di default e' qualche millisecondo ma si pio' cambiare con un tempo piu' elevato)

Percio' nel tuo caso devi selezionare le funzioni M dopo il posizionamento con reset da PLC.

Probabilmente questo lo hai gia' fatto, comunque non si sa mai ... nei meandri delle FM si fa' presto

a dimenticarsi qualcosa.

ciao

wally

[Supertony]

No, nel mio caso lavoro con l'emissione DURANTE il movimento, altrimenti se vengono emesse PRIMA o DOPO il movimento si arresta, emette e poi riparte, vanificando ogni tentativo di raccordo fra le traiettorie...

[314C]

Ho fatto applicazioni simili alla tua e l'emissione durante il movimento mi funzionava correttamente.

Sei sicuro che il problema dipenda esclusivamente dall'FM?

Io ti consiglio di fare una semplice prova:

Togli tutte le tacitazioni M dal programma PLC e fai un programma di movimento con una sola M nel punto in questione.

Sono sicuro che funzionera' correttamente.

Lascia Perdere OB a tempo o cose simili. Assicurati solo che il tempo ciclo dell'OB1 sia maggiore di 9 ms.

Saluti

[Supertony]

Orbene, signori, ci sono delle novità, che comunque non mi hanno risolto il problema, ma che mi hanno perlomeno permesso di "arginarlo". Innanzitutto, mi sono accorto che sia le funzioni M che i segnali di stop preelaboratore vengono rispettivamente emessi e ricevuti solo in un tratto SENZA raccordi. Mi spiego in parole povere: se con gli assi devo percorrere uno spazio di un metro in verticale, poi un metro in orizzontale durante il quale emetto un M e tento di arrestare il movimento con il STOPRE, e poi di nuovo un metro in verticale in discesa, e fra questi riesco ad inserire un raccordo di raggio 300mm, succede che nel tratto orizzontale mi rimangono solo 400m (1000-300-300), che tra l'altro percorro alla velocità più alta, per emettere l'M e tacitarlo. In parole povere, più sono piccoli i raccordi fra i movimenti lineari, e più possibilità ci sono che i segnali fra PLC e FM siano visibili.

Altra novità, confessatami da un tecnico Siemens: a partire dalla versione 5.0 del firmware dell'FM357-2, sono stati apportati mooooooooolti cambiamenti alla gestione delle funzioni ausiliarie.... ora, io dico.... se 2-3 anni fa non avevo di questi problemi programmando pick-and-palce mooooooolto più rapidi, allora credo che anche alla Siemens, evidentemente.... lavora qualche asino.

[Supertony]

Orbene, siamo arrivati al punto che un tecnico dell'Hot Line mi ha consigliato di aggiornare il firmware della scheda VERSO IL BASSO, cioè dalla versione 5.03 alla 5.01, che ho già scaricato da intenet, nell'attesa di effettuare il tentativo.

Giocando sulle velocità di avanzamento dei movimenti G01 e sui valori di raccordo delle funzioni "RND", ho trovato un compromesso sufficiente ad arrestare gli assi quando desiderato. Adesso il problema è un altro: per il funzionamento della macchina, a causa del fragile prodotto manipolato, devo utilizzare un profilo di movimento SOFT, guadagni bassi e accelerazioni modeste; c'è però un sistema di controllo di collisione che interviene nel caso il robot si schianti su qualcosa: in quel momento, tramite un interrupt avvio un sottoprogramma che arresta il movimento degli assi, ne rileva la posizione e si sposta dalla parte contraria per 300mm. Il problema è che in caso di collisione, gli assi si vermano con la solita "calma", per poi eseguire il movimento contrario.... che istruzioni posso usare per creare una specie di "arresto rapido" (rampa quasi zero) nel punto della collisione? Ho già provato a cambiare profilo da SOFT a BRISK all'inizio del sottoprogramma, ma non basta ancora.... devo trovare il sistema di arrestare immediatamente il movimento senza mandare in emergenza il CN. Neanche all'Hot Line hanno saputo darmi informazioni utili.... c'è qualcun più in gamba di loro?