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:
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