Velocità che si riduce in curva

Sezione dedicata a Linuxcnc
Rispondi
ross
Member
Member
Messaggi: 351
Iscritto il: mercoledì 3 agosto 2011, 23:16
Località: Macerata (MC)

Re: Velocità che si riduce in curva

Messaggio da ross » domenica 12 novembre 2017, 19:30

Qualsiasi cad 2D lavora in vettoriale, i files nativi in genere sono dwg e dxf, e gli archi sono sempre archi.
Fai delle prove e vedrai.

Ross

Dino
Senior
Senior
Messaggi: 815
Iscritto il: lunedì 13 novembre 2006, 23:08
Località: Dolomiti (BL)
Contatta:

Re: Velocità che si riduce in curva

Messaggio da Dino » domenica 12 novembre 2017, 22:27

OT-ON:
ross ha scritto:Ok, è come immaginavo.
Prova ad aprire il file dxf fatto con corel draw con un cad (draftsight, autocad ..) e vedrai che gli archi e le ellissi sono convertite in frammenti di linee.
La soluzione che adotto in azienda quando mi capitano queste cose (in genere sempre le spline) è quella di ricostruire manualmente gli archi al posto dei frammenti di linee e lo faccio anche per le ellissi.
Buonasera,
spesso leggo che secondo alcuni utenti avere file g-code contenenti solamente movimenti lineari, quindi con archi convertiti in linee entro una tolleranza accettabile, è causa di problemi di velocità nell'esecuzione della lavorazione, non so da dove nasca questa (ed altre) leggende metropolitane, quasi tutte le macchine a 5 assi lavorano esclusivamente con interpolazioni lineari sui 5 assi e questo non ne pregiudica affatto né la velocità di esecuzione né tantomeno l'accuratezza della lavorazione. Tanto più che un ellisse non è codificabile in G-code con G2 o G2 se non approssimando con n archi.
Altra leggenda metropolitana molto radicata è che avere rapporti di riduzioni tra l'albero motore e la vite con parecchi valori decimali porta ad un sovraccarico della CPU, nulla di vero, le moderne CPU (leggasi dall'intel 80386 che aveva già il coprocessore matematico, metà anni '80) impiegano più o meno lo stesso tempo a fare 1.0*10.0 che 3.14159265359*3.14159265359, altro discorso per la precisione sulle lunghissime distanze, in caso di macchine molto grandi (con assi di metri) bisogna tenere conto delle approssimazioni.

OT-OFF

Il problema dell'utente SergioRuffa e spesso di tutte le lavorazioni che apparentemente rallentano senza un preciso motivo è che l'accelerazione è stata impostata estremamente bassa, non so se per un limite del sistema (macchina+motori+driver+alimentazione+hardware PC) o per errore o mal informazione.

Avendo impostato:

Codice: Seleziona tutto

MAX_VELOCITY = 30.0
MAX_ACCELERATION = 10.0
l'asse impiegherà 3s e 45mm per accelerare da 0mm/s a 30mm/s, praticamente la velocità impostata nel g-code 400mm/min (6.66mm/sec circa) non verrà mai raggiunta dagli assi interpolati in quanto per raggiungere tale velocità il sistema impiegherà più di 0.6s e 2mm ma considerando che gli spostamenti sono molto corti, che oltre alla rampa di accelerazione c'è anche quella di decelerazione e che le due rampe si incontrano negli spostamenti programmati nel g-code la velocità risultante sarà estremamente bassa (senza fare calcoli ad occhio non si supereranno i 50-100mm/min durante l'esecuzione così come regolata la macchina) per ovviare a questo problema bisogna impostare le rampe di accelerazione e decelerazione molto più ripide, ovviamente stando sempre entro i limiti meccanici/elettronici del sistema, questo per evitare di perdere passi. Se tutto il sistema è ben dimensionato credo tu possa portare l'accelerazione a 500-600mm/s² così da abbassare a 0.05-0.06s il tempo si accelerazione/decelerazione per portare il sistema da 0 a 30mm/s (in meno di 1mm si passa da fermi alla massima velocità) così le rampe non si incontreranno ed il sistema lavorerà nel migliore dei modi. Il mio consiglio è di alzare l'accelerazione e verificare che il sistema non perda passi finché si scopre il limite del sistema, poi per avere un buon margine di sicurezza impostare l'accelerazione a circa l'80-85% del massimo trovato o anche meno se le prestazioni sono soddisfacenti, solitamente 600-700mm/s² sono un ottima accelerazione per i motori stepper, per i brushless o DC si può arrivare anche a 10000-15000mm/s² con driver e motori professionali.
Stessa cosa puoi fare per regolare la velocità massima, alzi finché non perdi passi poi setti all'80% e fai molte prove per esser certo di non perdere mai passi.
In Stepconf nella sezione dove si configurano gli assi in basso vengono calcolati tutti i valori risultanti con i dati settati.

Dino
NON più moderatore della sezione EMC ( http://www.linuxcnc.org/ )
Felice utilizzatore di GNU/Linux http://www.gnu.org/ http://www.kernel.org/
Linux Registered User #192043 http://counter.li.org/
Sito internet http://dino.delfavero.it/

Avatar utente
shineworld
Senior
Senior
Messaggi: 673
Iscritto il: venerdì 18 marzo 2016, 9:44
Località: Vicenza
Contatta:

Re: Velocità che si riduce in curva

Messaggio da shineworld » domenica 12 novembre 2017, 22:53

Premetto che sono poco addentro a Linuxcnc e che a riguardo ho dato solo un breve sguardo al relativo codice sorgente ma quanto segue vale per tutte le CNC.

Per una CNC in presenza di archi è sempre preferibile l'uso di comandi G2/G3 in quanto fa risolvere al generatore di profili la creazione dei punti necessari nella giusta risoluzione disponibile nel sistema.

Nei casi in cui siano fatti da un CAM come serie di tratti G1, un buon generatore profilo ed interpolatore applica lo stadio di lookahead in modo da guardare "avanti" nel programma e valutare le deviazioni di percorso ed ottimizzare la velocità. Questo ovviamente sotto G64 (continuous mode) di solito modale di default.

Dal 2004 in Linuxcnc è stato migliorato l'algoritmo di lookahead.

Controlla se i passi di lookahead sono abilitati e che siano sufficienti per fare l'arco. Per esempio in mach3 di default sono solo 20 e possono essere pochi.

Nel mio controllore sono anche lì programmabili tra 1000 e 30000.

ross
Member
Member
Messaggi: 351
Iscritto il: mercoledì 3 agosto 2011, 23:16
Località: Macerata (MC)

Re: Velocità che si riduce in curva

Messaggio da ross » domenica 12 novembre 2017, 22:59

quindi con archi convertiti in linee entro una tolleranza accettabile, è causa di problemi di velocità nell'esecuzione della lavorazione, non so da dove nasca questa (ed altre) leggende metropolitane, quasi tutte le macchine a 5 assi lavorano esclusivamente con interpolazioni lineari
Purtroppo non è una leggenda, lavoro con due macchine di taglio laser industriali che hanno accelerazioni molto alte e un cam "intelligente" da 6500euro che senza le dovute accortezze si comportano proprio così (rallentamenti), questa è esperienza fatta direttamente sul campo e faccio presente che le dimensioni dei frammenti di linee a cui mi riferisco sono inferiori al decimo di millimetro causate dalla conversione del file grafico.

Ross

Dino
Senior
Senior
Messaggi: 815
Iscritto il: lunedì 13 novembre 2006, 23:08
Località: Dolomiti (BL)
Contatta:

Re: Velocità che si riduce in curva

Messaggio da Dino » domenica 12 novembre 2017, 23:32

Ciao,
che il cam costi 6500€ non implica che faccia le cose bene/nel modo migliore, dipende dall'esperienza sul campo di chi l'ha codificato e ti posso assicurare che molti sviluppatori (specie di software detto "di nicchia") sono persone improvvisate che non hanno mai visto una macchina e che sanno solo la teoria (e a volte la sanno anche male, te lo dico perché ho discusso un giorno con uno pseudo venditore/programmatore di CAM e dai discorsi fatti si capiva che non aveva molto le idee chiare di cosa stesse parlando, figurarsi se sapeva cosa stava facendo... puntava tutto sul basso costo del software come se il costo facesse il prodotto, naturalmente l'ho congedato con "le faremo sapere...")
Premesso questo bisogna sempre valutare se anche il software a bordo macchina è configurato correttamente, se l'operatore conosce la macchina e conosce come impostare i parametri modali prima della lavorazione. Potrei farti vedere lavorazioni in 3-4-5 assi eseguite ad alta velocità e descritte da movimenti di decimo di millimetro o anche meno (all'interno del G-Code). Tutto sta nell'aver correttamente impostato la macchina, cosa che come ho evidenziato non è stato fatto per il caso in questione.
Potrei portare altri esempi, sono 25 anni che lavoro su macchine a 3-5 assi, di tecnici o programmatori che spacciano per oro il piombo e che a detta loro sono il meglio del meglio... ad esempio un tizio qualche mese fa proponeva una sua macchina 5 assi customizzata per produrre parti di occhiali ad una cifra a suo parere concorrenziale (circa 100K€ quando la concorrente più diffusa ed utilizzata costa circa 170K€) equipaggiata (sempre a suo dire) con il miglior controllo in circolazione (giapponese) poi durante una visita alla sua azienda notai che nelle schermate del pc non appariva mai il logo del famoso controllo (disse che era perfettamente identico a quello famoso, aveva le stesse funzioni disse...???...), aperto il quadro elettrico di una macchina (scelta da lui per farci vedere come lavorava) trovammo fili sparsi ovunque, fascettati qua e la alla meglio, successivamente il cliente (io ero la solo come tecnico per consigliare eventuali migliorie da portare alla macchina) chiese se poteva vedere la macchina in funzione, provarono per una mezz'ora buona a far muovere la macchina modificando il g-code a mano cercando di capire cosa non andava... la scusa fu che il cam era stato fatto da un altra azienda e che forse c'era qualcosa da sistemare... insomma negli anni ho visto di tutto quindi non mi meraviglio più di nulla (NON DICO SIA IL TUO CASO ma molto molto spesso il problema è da ricercare in cosa si è acquistato e non tanto sul come si sta cercando di far lavorare la macchina, poi ovviamente tutto è perfettibile e non si possono prevedere tutti i possibili errori fatti dagli operatori) concordo che più il G-Code è scritto bene e meglio verrà realizzato il lavoro, che per ogni macchina va realizzato un post-processor ad-hoc e che solo chi ha esperienza sul campo può intuire cosa non va.
Dino
NON più moderatore della sezione EMC ( http://www.linuxcnc.org/ )
Felice utilizzatore di GNU/Linux http://www.gnu.org/ http://www.kernel.org/
Linux Registered User #192043 http://counter.li.org/
Sito internet http://dino.delfavero.it/

Avatar utente
shineworld
Senior
Senior
Messaggi: 673
Iscritto il: venerdì 18 marzo 2016, 9:44
Località: Vicenza
Contatta:

Re: Velocità che si riduce in curva

Messaggio da shineworld » domenica 12 novembre 2017, 23:59

Concordo con Dino.
Un CAM al top da solo non basta.
Bisogna configurare bene anche la macchina ed assicurarsi che il codice g generato dal CAM sia appropriato.

Da un punto di vista matematico il rallentamento del feed in una serie di tratti molto piccoli è imputabile anche a un non adeguato stadio di lookahead.

Li dipende molto dalle strategie adottate da ogni singolo CN su come eliminare tratti inutili al fine del risultato, analizzare cosa farà nei passi che seguiranno, adottare le giuste tecniche di raccordo per tenere la velocità più prossima al feed impostato.

Concorrono impostazioni assi ( velocità massima, tempi accelerazioni/decelerazione, risoluzione di tutti gli assi coinvolti).

Partendo da un buon post-processo si è già a metà strada.

scj

Re: Velocità che si riduce in curva

Messaggio da scj » lunedì 13 novembre 2017, 14:11

shineworld ha scritto:
Nel mio controllore sono anche lì programmabili tra 1000 e 30000.
Se non è top secret che controller hai? :wink:

Avatar utente
shineworld
Senior
Senior
Messaggi: 673
Iscritto il: venerdì 18 marzo 2016, 9:44
Località: Vicenza
Contatta:

Re: Velocità che si riduce in curva

Messaggio da shineworld » lunedì 13 novembre 2017, 15:02

Ciao SCJ,
nessun segreto :)

Di recente ho acquistato MACH4 Industrial su cui ho fatto delle prove ed ha il look-ahead programmabile in setup.
Sui pantografi faccio girare RosettaCNC, che per default ha un lock-ahead di 1000 passi.

gio14
Newbie
Newbie
Messaggi: 48
Iscritto il: venerdì 3 marzo 2017, 2:20
Località: Brignano (BG)

Re: Velocità che si riduce in curva

Messaggio da gio14 » martedì 14 novembre 2017, 3:30

@ sergioruffa
Comunque se usi VCarve (io uso Asppire delle Vectric, come VCarve credo) quando importo un dxf che è costituito da una miriade di trattini uso l'opzione "adatta curve a vettori" in pratica puoi trasformarlo in archi o in curve di bezier, poi in base alla tolleranza che gli dai hai o maggiore precisione o meno archi o curve (però attenzione quando cerchi l'opzione, perché il menù contestuale è farlocco, almeno in Aspire, lo trovi sotto l'icona "arco d'entrata nei vettori selezionati"

SergioRuffa
Newbie
Newbie
Messaggi: 28
Iscritto il: martedì 11 aprile 2017, 14:27

Re: Velocità che si riduce in curva

Messaggio da SergioRuffa » giovedì 16 novembre 2017, 18:12

Ringrazio tutti per le dritte e per l'interessante discussione che è nata sull'argomento. Avrete tutti capito che tra me e un professionista ci sono alcune differenze...

Mi state aprendo un nuovo mondo, inizierò a fare test e prove, magari continuerò a disturbarvi per avere altri chiarimenti!!

Rispondi

Torna a “Linuxcnc”