BlenderCAM beta testing

[kylotron]

NOTA: Topic diviso da questo: https://www.cncitalia.net/forum/viewtopi ... 13&t=52677


A parte il fatto che sono quasi 10 giorni che tra 4° asse e blender non sto combinando null'altro (e devo sistemare un sito web).... mah...

ho scaricato una colonna in 3D per avere un riscontro oggettivo dell'effettivo funzionamento del 4° asse.... e sto tentando di fare qualcosa di concreto.

Ora guardate (considerate che ho volutamente impostato 8 cm di "Distance between toolpath" per avere un'immagine meno ingarbugliata....)....

BlenderCAM-test_4asse_colonna50.png

La domanda è: se il materiale se lo stima da solo sulla base del modello... perché deve partire cosi' lontano per fresare? Cioè... come faccio a ridurre la distanza tra la fresata più esterna e l'oggetto?
Io caricherò un pezzo di legno che è calcolato al mm per realizzare l'oggetto... non mi va di far fare 5 passate inutili...

[kylotron]

Problemi... su problemi...

questo è ciò che produce BlenderCAM

Schermata-1.ridimensionato.png

Questo è ciò che legge LinuxCNC

Schermata.ridimensionato.png

Come vedete non è proprio la stessa cosa...


P.S.: intanto siamo arrivati alla 249

[walgri]

Grazie per l'info kylotron

Permettimi una osservazione: questo è il posto sbagliato per rilevare i problemi di una parte sperimentale e non ufficialmente rilasciata di un software che è ancora alla versione 0.8

Non è evidentemente pronto per produrre e stai compiendo test su codice che nella migliore delle ipotesi è allo stadio alpha. Fai un test, unico e circostanziato e pubblica nella sezione Bug Reports del forum ufficiale includendo il file .blend. L'autore di Blendercam non legge qui, non conosce l'italiano.

[kylotron]

Ok

[Zebrauno]

Eppure a me non sembrano esserci discrepanze.
Quello che non quadra e' che in BlenderCam tu veda un 3D che e' totalmente differente da quello che l'utensile lavorerebbe seguento i percorsi indicati.
Infatti su LinuxCNC visualizzi esattamente gli spicchi di percorso con la stessa suddivisione dell'angolo giro che si vede in Blender.

ciao

[walgri]

Mi sorge il dubbio vi sia una differente rappresentazione/calcolo dei G0 G1, in Blendercam sembrano rappresentati con il movimento angolare eseguito durante il ritorno a X0, in Linuxcnc con il movimento angolare lungo la discesa. Ma senza il .blend non si può dire nulla.

[kylotron]

Allora... provo a spiegare ciò che dovrebbe fare e ciò che accade.

Immaginiamo di dover fresare un cilindro... magari con differenti diametri man mano che si procede lungo l'asse X.
E scegliamo di fresarlo con una strategia del tipo "Parallel", con l'utensile che si muove lungo l'asse X...
Per semplicità diciamo che faremo una passata ogni 10° di rotazione del mandrino.
Pertanto...

1) il mandrino si posiziona con A=0°
2) l'utensile si posiziona con X=0, Y che resta SEMPRE fermo e Z impostata...
3) l'utensile avanza lungo l'asse X fino alla fine... variando la Z secondo il profilo del pezzo che vogliamo ottenere.
4) immaginando di non aver impostato il doppio passaggio, ovvero la possibilità di fresare sia quando la X aumenta che quando diminuisce, avremo:
4a) il mandrino ruota e si posiziona in A=10° (o -10° a seconda di come viene impostato)..
4b) l'utensile torna indietro a X=0
5) si riparte dal punto 2... (fino al completamento del giro).

Questo ovviamente se vogliamo fresare un cilindro.

Quello che avviene invece è diverso....
Perché la A resta ferma finché l'utensile può togliere materiale. Quindi si sposta sia in X ma anche in Y... esenguendo una sorta di lavorazione a 3 assi. Poi quando non può più raggiungere il materiale, allora il pezzo ruota!

[walgri]

Quello che che fa, in base alla tua descrizione, sembra proprio un comportamento da 4° asse indicizzato. Se lo fa con strategia con 4° interpolato è un malfunzionamento.

Però utile a fresare certi sottosquadri, mhmm, se ci fosse il remachining interesserebbe molto al mio caro amico Arm

[kylotron]

Io intanto ieri ho installato opencamlib (non so se ho fatto tutto bene... boh) perché vedevo che veniva inserita nella 249.

Adesso ho aggiornato BlenderCAM alla 250

[walgri]

Non ho ancora ben capito sul quali strategie è adottata. In ogni caso è un bel passo avanti verso la creazione dei percorsi direttamente sul Stl anziché sulla bitmap. Mi pare una eccellente novità, tutta, ovviamente, da testare, ma già estremamente promettente.

La lavorazione Waterline, che mi pare la prima sopportata di opencamlib dovrebbe avere già dei miglioramenti rispetto a a quanto postai all'inizio del topic.

Su linux hai dovuto compilare Opencamlib ?
Io ora devo capire come aggirare, se si può, VisualStudio, ho già esperienza sulla creazione di dll da utilizzare con Python, ma devo vedere se ci sono altri ostacoli.

[kylotron]

Si... ho compilato tutto. All'inizio m'ha dato un errore... poi ho reinstallato il necessario (forse mancava qualcosa) ed è andato tutto bene.

Se vuoi lavorare con Blender ti consiglio di farti un dual boot. Blender nasce su Linux... il resto è un porting... non so fino a che punto riuscirebbe ad essere stabile e performante!

[walgri]

Grazie Kylotron, faccio continuamente dual boot, ma preferirei tenere tutto quanto riguarda la cnc su windows, visto che il mio controller per ora ha soltanto interfaccia per quel sistema.

[walgri]

Che bello, Zebrauno, saperti dei nostri

[kylotron]

Ragazzi, vi chiedo una gentilissima cortesia...

Blender-test_4asse_colonna30.png

Quella che vedete nell'immagine è una piccola colonna che vorrei fresare con il 4° asse.
Ce l'ho in blender... e l'ho esportata in STL che allego.

test_4asse_colonna30.stl.zip

Volevo chiedere a qualcuno se può elaborarla con un qualche CAM per poterla fresare sul 4° asse... in linuxCNC.

Mi serve una sgrossatura con fresa cilindrica da 3 mm ed una finitura con bulino 30g da 0.5 mm (files gcode separati, grazie).


Per ulteriori info basta che mi contattate.
Io con BlenderCAM riesco ad esportare il percorso completo... ma linuxCNC me ne vede solo una piccola parte. E volevo capire quali fossero le differenze.

Grazie
Bernardo

[kylotron]

ATTENZIONE: RILEVATO ERRORE DI CALCOLO

Ho prodotto il gcode....

Test_4asse_colonna30_2b_helix.ngc.zip

(NON USATE QUESTO GCODE SULLE VOSTRE CNC SE NON IN MODALITÀ SIMULAZIONE)
per vedere se avevo intuito male l'operato di BlenderCAM. E per fortuna che sono stato veloce a bloccare la macchina....

Questo è il percorso teorico, come viene calcolato da BlenderCAM:

percorso_blender.png

...e questo è quello reale, come viene letto da LinuxCNC:

percorso_teorico.jpg

Questo è il punto in cui ho stoppato la macchina:

percorso_reale.jpg

Cosa succede?
Graficamente, il percorso sembra riuscire bene. In pratica, invece, succede un macello!

La teoria vuole che, una volta impostata la macchina e azzerato il tutto nel punto in cui si vuole iniziare, con X=0, Y in linea con il 4° asse e Z in linea con il centro del 4° asse...

...l'utensile venga spostato in una Z positiva pari al diametro esterno dell'oggetto da realizzare, più una certa distanza di sicurezza.
Da quel momento in poi, gli unici movimenti che l'utensile DEVE FARE sono solo ed esclusivamente quelli lungo l'asse X "positiva", da 0 alla fine del pezzo, e quelli lungo l'asse Z "positiva", da 0 al massimo diametro del pezzo (in realtà procede al contrario). Durante tutta la lavorazione... il pezzo DEVE RUOTARE... per mantenere sempre il punto di contatto tra l'utensile e il pezzo in senso verticale, sopra l'oggetto.

Fin qui la teoria... (correggetemi se sbaglio).

Nella pratica avviene tutt'altro.
LinuxCNC, non sapendo che all'interno della spirale che disegna il percorso utensile, c'è un corpo rigido, non fa altro che seguire alla lettera delle istruzioni palesemente sbagliate.... tentando di far seguire alla punta dell'utensile il percorso specificato. Cosa che, ovviamente, non può fare. Non DEVE fare. L'utensile NON DEVE passare all'interno dell'oggetto per poter seguire il percorso... deve restarci sempre fuori!

Pertanto... BlenderCAM attualmente sbaglia completamente la gestione del percorso utensile.

Non so l'inglese se non col traduttore di google... Walgri, se puoi contattare lo sviluppatore... penso che risolvendo tale problema si farebbe un bel passo avanti!

Grazie
Bernardo