Finecorsa software in JOG assi Kinetix

[Cesare Nicola]

Sto utilizzando per la prima volta un sistema composto da CPU GuardLoogix 5580 e assi Kinetix. Il software non è realizzato da me e sto cercando di districarmi. Ho notato che gli assi, quando vengono mossi in JOG, col comando MAJ, non si arrestano sui finecorsa software, sebbene questi siano correttamente programmati e abilitati. Rockwell mi dice che è normale perché il JOG non prevede arresto sul finecorsa software: chi ha realizzato il software sembra invece sostenere che gli assi si devono arrestare, oltrepassando solo un po' il finecorsa a causa della rampa (dico "sembra sostenere" perché è uno statunitense col quale comunichiamo via mail, può essere che qualche informazione non venga ben compresa, da entrambe le parti). Chi ha ragione? 

Queste sono le impostazioni che hanno un legame col comportamento dei finecorsa software, da quel che mi han detto.

 

 

 

[84paolo]

il comando del jog non si ferma con gli extracorsa software, ha ragione la rockwell. quando io facevo i comandi di jog con rockwell, sul comando di jog avanti inserivo un confronto che la quota attuale doveva essere minore della quota di extracorsa letta con istruzione GSV

poi mi sembra di ricordare che nelle stop action impostavamo current decell and disable sugli extracorsa software e non disable.

Modificato: 23 maggio 2020 da 84paolo

[Cesare Nicola]

3 minuti fa, 84paolo ha scritto:

il comando del jog non si ferma con gli extracorsa software, ha ragione la rockwell. quando io facevo i comandi di jog con rockwell, sul comando di jog avanti inserivo un confronto che la quota attuale doveva essere minore della quota di extracorsa letta con istruzione GSV

poi mi sembra di ricordare che nelle stop action impostavamo current decell and disable sugli extracorsa software e non disable.

Immaginavo, anche io credevo alla versione Rockwell. Ora, io che sto usando Rockwell per la prima volta, dovrò spiegare a uno statunitense, dove mangiano pane e Rockwell anche a colazione, che si sta sbagliando! 😄
Grazie.

[Operational Amplifier]

3 ore fa, 84paolo ha scritto:

il comando del jog non si ferma con gli extracorsa software

Personalmente non condivido questa scelta 🙄

[Marco Mondin]

In Jog serve che non si fermino altrimenti da alcune rare situazioni non se ne potrebbe più uscire! Di solito io valuto la situazione.
Se sono con assi con homing eseguito genero io una rampa con un anticipo calcolato con uno stupido calcolo su accelerazione, velocità a jerk. La tolleranza di errore è dovuta solo al ciclo di interpolazione comunque quasi sempre ridicola. Se non sono in homing eseguito attraverso una password permetto comunque jog senza limiti. Lo metto sotto password in quanto va fatto solo in situazioni strane che di solito se la macchina funziona come deve non devono accadere.
La rampa sovente la applico modificando l'override sul mio calcolo.

Modificato: 24 maggio 2020 da Marco Mondin

[Livio Orsini]

3 minuti fa, Marco Mondin ha scritto:

In Jog serve che non si fermino altrimenti da alcune rare situazioni non se ne potrebbe più uscire!

 

Corretto.

Il jog dovrebbe essere interrotto solo dal fine corsa meccanico corrispondente.

[batta]

Il 23/5/2020 alle 11:40 , Operational Amplifier ha scritto:

Personalmente non condivido questa scelta

Ci sono diverse correnti di pensiero, e ci sono pro e contro in entrambe le soluzioni.
Da una parte, risulta comodo tener conto dei limiti software anche in jog, ed essere in questo modo sicuri di non superare i limiti senza dover implementare ulteriori controlli.
Dall'altra, ti potresti trovare con un asse non correttamente referenziato, e non poter oltrepassare i limiti nemmeno in alcuni casi, come dice Marco, potrebbe generare una situazione dalla quale non usciresti più.
Io non conosco Rockwell (sono entrato nella discussione, come spesso faccio, per curiosità), ma trovo corretto (almeno in questo caso, non è mia intenzione scatenare guerre) il modo di agire di Siemens: imposto i limiti software e, con un bit, li abilito e li disabilito a piacere. Con i limiti abilitati, non esco dai limiti non solo con i comandi jog, ma nemmeno durante l'homing.
È di una facilità estrema decidere se e quando permettere o non permettere di andare oltre i limiti software.

 

Personalmente, ritengo che, spesso (da valutare caso per caso in relazione a eventuali possibili danni), se ho dei finecorsa software affidabili, si possa anche fare a meno dei finecorsa hardware. Questo, ovviamente, richiede che i finecorsa software siano attivi anche in jog, quindi non condivido la filosofia Rockwell.

Modificato: 24 maggio 2020 da batta

[84paolo]

con rockwell anche i limiti software si possono abilitare o disabilitare tramite istruzione SSV. però comunque l'istruzione Jog rimane fuori da questi limiti. Tra l'altro, in Jog, una volta oltrepassati i limiti software l'asse viene disabilitato e quindi occorre implementare alcune righe di codice per poter disattivare il blocco dell'asse tramite istruzione SSV e poi una volta rientrato in range occorre riabilitare i limiti.

[Operational Amplifier]

4 ore fa, batta ha scritto:

Ci sono diverse correnti di pensiero, e ci sono pro e contro in entrambe le soluzioni.
Da una parte, risulta comodo tener conto dei limiti software anche in jog, ed essere in questo modo sicuri di non superare i limiti senza dover implementare ulteriori controlli.
Dall'altra, ti potresti trovare con un asse non correttamente referenziato, e non poter oltrepassare i limiti nemmeno in alcuni casi, come dice Marco, potrebbe generare una situazione dalla quale non usciresti più.

Vero...ci sono pro e contro in entrambe le soluzioni.

 

5 ore fa, Marco Mondin ha scritto:

In Jog serve che non si fermino altrimenti da alcune rare situazioni non se ne potrebbe più uscire! Di solito io valuto la situazione.
Se sono con assi con homing eseguito genero io una rampa con un anticipo calcolato con uno stupido calcolo su accelerazione, velocità a jerk. La tolleranza di errore è dovuta solo al ciclo di interpolazione comunque quasi sempre ridicola. Se non sono in homing eseguito attraverso una password permetto comunque jog senza limiti. Lo metto sotto password in quanto va fatto solo in situazioni strane che di solito se la macchina funziona come deve non devono accadere.
La rampa sovente la applico modificando l'override sul mio calcolo.

Effettuerò anch'io questo override dei limiti software tramite password con le nuove release anche perchè prevenire è meglio che curare. 

[Livio Orsini]

Io sono della vecchia scuola: i limiti di sicurezza per me si fanno con dispositivi elettromeccanci, i limiti software vanno bene ma, in caso di necessità, si devono poter superare.

[Operational Amplifier]

1 ora fa, Livio Orsini ha scritto:

Io sono della vecchia scuola: i limiti di sicurezza per me si fanno con dispositivi elettromeccanci, i limiti software vanno bene ma, in caso di necessità, si devono poter superare.

I finecorsa hw di solito li installo sempre poco oltre ai limiti sw come sicurezza di extracorsa con contatto NC.

[Marco Mondin]

Tuttavia sempre più committenti ultimamente sembra paghino oro ogni cm in più di guide!
Molto di frequente mi trovo finecorsa meccanici a 5mm dalla battuta! Su macchine che magari vanno a 1.4m/s!
Devono spiegarmi che utilità ci trovano a spendere solidi nei finecorsa meccanici per poi montarli così! 

[batta]

18 minuti fa, Marco Mondin ha scritto:

Devono spiegarmi che utilità ci trovano a spendere solidi nei finecorsa meccanici per poi montarli così! 

Perfettamente d'accordo.
Il bello dei limiti software (almeno in Siemens) è che non intervengono all'improvviso, quando magari sei alla massima velocità, impegnando poi il sistema con una frenata rapida, ma vengono gestite le rampe per arrestarsi esattamente sul limite software impostato.
Certo, se qualcosa non dovesse funzionare nei limiti software, meglio avere un finecorsa hardware che non averlo, ma se questi finecorsa vengono posti troppo vicini ai limiti della corsa meccanica, non servono praticamente a nulla.
Per questo, come dicevo prima, si deve valutare caso per caso. Ci sono casi in cui ci si può permettere di andare a sbattere senza causare danni (e, in questo caso, i finecorsa hardware sono solo una inutile complicazione), e ci sono assi in cui una collisione causerebbe danni irreparabili (quindi, si devono prendere tutte le precauzioni, compresa quella di non installare i finecorsa hardware appiccicati ai limiti della corsa meccanica).
Purtroppo, da quando "si fa tutto con il plc", i progettisti meccanici sempre più spesso trascurano aspetti che rimangono, plc o no, ancora fondamentali.

[Operational Amplifier]

1 ora fa, Marco Mondin ha scritto:

Tuttavia sempre più committenti ultimamente sembra paghino oro ogni cm in più di guide!
Molto di frequente mi trovo finecorsa meccanici a 5mm dalla battuta! Su macchine che magari vanno a 1.4m/s!
Devono spiegarmi che utilità ci trovano a spendere solidi nei finecorsa meccanici per poi montarli così!

Perfettamente d'accordo.

 

48 minuti fa, batta ha scritto:

Per questo, come dicevo prima, si deve valutare caso per caso.

Certamente ogni sistema va interpretato a se.

[Cesare Nicola]

11 ore fa, Marco Mondin ha scritto:

Tuttavia sempre più committenti ultimamente sembra paghino oro ogni cm in più di guide!
Molto di frequente mi trovo finecorsa meccanici a 5mm dalla battuta! Su macchine che magari vanno a 1.4m/s!
Devono spiegarmi che utilità ci trovano a spendere solidi nei finecorsa meccanici per poi montarli così! 

Esatto. Questa, più che "molto spesso" è la norma. I finecorsa meccanici sono ormai un inutile spreco di soldi e fatica per regolarli (quando si riesce, perché a volte sono così vicini al limite della corsa utile che non si riesce proprio).

 

Per quel che riguarda le differenti filosofie, io valuto tenendo sempre a mente la legge Nr. 1 di Murphy sulla movimentazione assi: "se un asse può andare a sbattere sulla battuta meccanica, ci andrà; se potrà farlo a velocità tale da causare un danno, lo farà".

Non so dire se alla base della scelta di chi ha fatto il software ci sia un ragionamento o semplicemente l'ha buttato giù così e "poi vedremo" (direi la due, a naso).

PS. Qualcuno si chiederà forse "ma stai lavorando su un impianto senza avere le idee chiare di come deve funzionare"?. Sì, esatto. L'impianto doveva essere collaudato dallo statunitense che ha realizzato il software, ma non può muoversi causa Covid, quindi chi ha realizzato l'impianto ha dovuto trovare in fretta e furia qualcuno che facesse almeno un pre-collaudo.

[Livio Orsini]

41 minuti fa, Cesare Nicola ha scritto:

, quindi chi ha realizzato l'impianto ha dovuto trovare in fretta e furia qualcuno che facesse almeno un pre-collaudo.

 

Almeno questa è una ragione valida e, soprattutto, indipendente dalla volontà umana.

Altre volte invece si cerca qualche povero disgraziato che faccia un lavoro simile, solo per motivi economici.

[Marco Mondin]

31 minuti fa, Livio Orsini ha scritto:

Almeno questa è una ragione valida e, soprattutto, indipendente dalla volontà umana.

Altre volte invece si cerca qualche povero disgraziato che faccia un lavoro simile, solo per motivi economici.

Sai quante volte sento la frase... "Dobbiamo cercare un ragazzino, magari un neolaureato per le messe in servizio, perché dobbiamo risparmiare, voi per questo costate troppo".
Faccio sempre finta di nulla e non rispondo, ignoro totalmente la frase quando la dicono. Alla fine la gente deve provare e sbagliare da sola!

[lucios]

Quote

Il jog dovrebbe essere interrotto solo dal fine corsa meccanico corrispondente

Livio, sui CNC più noti è da anni che i finecorsa software funzionano anche in JOG. Non danno problemi perchè, se per qualche ragione viene oltrepassato il limite, il CNC stesso permette solo i movimenti nel senso opposto; per cui non si possono verificare condizioni di stallo. Dovrebbe essere secondo me il funzionamento ottimale anche su assi gestiti da PLC.

I finecorsa meccanici devono rimanere l'ultima barriera contro il cozzo e devono essere regolati in modo di evitare di piantarsi contro i tamponi meccanici.

[Marco Mondin]

35 minuti fa, lucios ha scritto:

Livio, sui CNC più noti è da anni che i finecorsa software funzionano anche in JOG. Non danno problemi perchè, se per qualche ragione viene oltrepassato il limite, il CNC stesso permette solo i movimenti nel senso opposto; per cui non si possono verificare condizioni di stallo. Dovrebbe essere secondo me il funzionamento ottimale anche su assi gestiti da PLC.

I finecorsa meccanici devono rimanere l'ultima barriera contro il cozzo e devono essere regolati in modo di evitare di piantarsi contro i tamponi meccanici.

Il problema è quando non sono referenziati gli assi e magari hanno encoder incrementali! Accendendosi con quote sconosciute e magari oltre i limiti, rientrare è un serio problema!
Per altro la funzione di movimento solo dal lato opposto lasciata attiva senza home, l'ho vista causare ulteriori problemi!
Va benissimo ed è corretto usarla con assi referenziati! Facciamo anche noi così, con alcuni CN è gestito con altri lo gestiamo noi, tuttavia preferisco gestirla io proprio per evitare le situazioni "anomale".

La situazione tipo, anche se rara è:
Fanno manutenzione, spostano un asse al limite della battuta DX a mano, accendono la macchina e l'encoder dice di essere oltre il limite sw SX! Il costruttore, cosa per altro non rara ha messo una camma sul micro meccanico che si può superare e siamo oltre a micro spento!
Il SW in automatico non fa i miracoli come credono alcuni progettisti di macchine...

[lucios]

Quote

Fanno manutenzione, spostano un asse al limite della battuta DX a mano, accendono la macchina e l'encoder dice di essere oltre il limite sw SX!

Ma, a parte che è una situazione limite, se l'encoder è incrementale probabilmente il CNC ha perso l'origine quindi va rifatta la procedura di ripresa.

In ogni caso, se si è combinato un disastro simile, tutti i CNC (o almeno quelli con i quali ho avuto a che fare) hanno la possibilità di forzare una quota o, al limite, di rifare la procedura di presa origine macchina come se fosse la prima accensione.

Però la discussione riguarda PLC Rockwell che non conosco, quindi stiamo andando off topic.

Modificato: 25 maggio 2020 da lucios

[Livio Orsini]

2 ore fa, Marco Mondin ha scritto:

Il problema è quando non sono referenziati gli assi e magari hanno encoder incrementali! Accendendosi con quote sconosciute e magari oltre i limiti, rientrare è un serio problema!

 

Io non sono un esperto di CNC, che sono controlli specialistici, però un asse è un asse ed un fine corsa è un fine corsa.

Per me vale sempre il primo assioma della vita: "Se un incidente può capitare, capiterà senz'altro! L'importante è essere comunque preparati."