Tentative de photo en 3D : Calculs infinis

Bonjour,

Suite à une jolie prestation de ma fille aux championnats de France d'Equifun, j'ai envie, pour lui faire une surpise, de réaliser quelque chose d'unique ...

Sur l'air de "Papa Fraiseur - Bébé Bonheur" (houla, ... Pas jeune ça ...), j'ai eu envie de réaliser une gravure 3D à partir d'une photo d'elle sur son cheval en utilisant ma fraiseuse préférée et, bien sûr, cam Bam.

Après le choix d'une photo graphique et assez simple, je l'ai intégrée dans cam Bam avec « surface » « à partir d'une image bitmap » avec une dimension de 300 y X 200 x. une profondeur de 15, et un pas de 1 sur les deux axes. (J'ai essayé ensuite avec différentes valeurs de pas… sans plus de succès…)
L'image d'origine est en JPEG (je ne sais pas ça a de l'importance)

Au début j'étais content car j'ai obtenu, sous cam Bam, une image 3D semblant tout à fait convenable lorsque je la fais pivoter.


Malheureusement, lorsque j'essaie de faire une gamme d'usinages cela se passe beaucoup moins bien :
–j'ai choisi un outil de 1,5 mm hémisphérique.
–Des vitesses assez rapides (800 mm mn) car mon prototype sera réalisé dans du styrodur.
–Et une passe à 1 mm.

Jusque-là tout va bien.

Mais lorsque je demande à générer le fichier Gcode, cam Bam part dans un calcul très long, très très long, très très très long,… bref il ne ressort pas du calcul.
Sous l'explorateur de ressources, on voit qu'il consomme petit a petit jusqu'a 2,6 Gigas octets de RAM, puis se stabilise à cette valeur et continue de tourner et de consommer du CPU.
(A noter que j'ai une configuration assez puissante avec 20 giga de RAM rapide, un disque dur SSD rapide, un Core I7 boosté avec refroidissement liquide, et une très bonne carte graphique gainward GTX 770 phantom)

Qu'en pensez-vous ?
Avez-vous déjà rencontré ce problème ?
Peut-être qu'il y a une étape que je fais mal… typiquement je ne nettoie pas l'image avant de l'intégrer…,…,
c'est peut-être la ou je pêche ?
Comment en savoir plus ?

Merci pour votre aide, Fragaria

Salut,

Tu dois avoir une valeur "dans les choux" dans un des réglages de ton opération d'usinage 3D ; si ton fichier .cb fait moins d'un Mo une fois compressé en ZIP, met le en PJ, je regarderais, sinon passe moi un MP, je te donnerais mon mail pour envoi.

++
David

Salut,

Il y a peut être (surement) un bug ; je vais transmettre à Andy pour confirmation.

Si on excepte les tracés 2D et les objets 3D, ce qui pompe de la mémoire, ce sont les parcours d'outils.

Un parcours d'outil n'est rien de plus qu'une polyligne, contenant plus ou moins de segments (donc de points)

En pratique, sur un usinage 3D, plus la valeur de recouvrement est faible, plus il y a des passes // (donc de polylignes), et plus la valeur de résolution est faible, plus les polylignes servant de parcours contiennent de segments. (donc consomment plus de RAM)

Si on a plusieurs niveaux d'usinage (plusieurs passe en profondeur), on multiplie encore la conso vu qu'il va y avoir autant de "couches" de polyligne que de niveaux d'usinage ; donc en principe, un usinage en 2 passes consommera 2x plus de mémoire qu'en une seule passe ... en théorie.

Maintenant, j'ai fait le test suivant, sans changer à tes autres paramètres:

incrément de passe = 15 -> soit une seule passe -> conso RAM pour Cambam -> 227 Mo
incrément de passe = 7.5) -> soit 2 passes conso RAM -> 2308 Mo (testé avec la patch 4Go pour win 64 **) ... soit 10x plus au lieu des 2x plus attendus ... pas normal ... et avec 15 passes comme sur ton fichier, out of memory !

Pour régler le problème, il suffit de changer un seul paramètre: Ordre d'usinage, à mettre sur Niveaux d'abord au lieu de profondeur d'abord ... et la, même avec 15 niveaux d'usinage (incr de passe = 1mm) la conso mémoire tombe à ...  278 Mo et ça passe même sous Win XP32bit sans le patch ..  je soupçonne donc un bug avec profondeur d'abord pour les opérations 3D.

** Note: une application 32 bits ne peux gérer que 2 Go de RAM, même si tu a plus de RAM installée sur le PC ou même si tu est sur une version 64 bit de windows (mais avec une appli 32 bits).

En pratique, si tu regarde sur le gestionnaire de tâches, CB plante avec un "out of memory" aux environ de 1.6 Go de RAM utilisée.

Il existe un patch qui permet SUR UN SYSTEME 64 bits (uniquement) de passer cette limite maxi à 4.0 Go environ pour les appli 32bits, et ça semble marcher avec CB (je suis monté jusqu'à 2.5 Go) ... bon, ça ne résout pas le bug ci-dessus car arrivé à 2.5Go je n'ai pas de out of mémory, mais le CPU tourne sans fin, mais c'est bon à savoir car en 3D le manque de RAM est un problème fréquent

http://ntcore.com/4gb_patch.php

Ceci dit, faire des passes de 1mm dans du styrodur, c'est vraiment faible, même avec une fraise de 1.5 ; à mon avis tu peux faire ça en 2 ou 3 passes sans soucis ; pour ma part dans le styrodur, avec une fraise de 3 hémi, je prends des passes égales à la longueur taillée de la fraise, soit -> 22mm ...

Note aussi qu'en principe en usinage on travaille avec ébauche et finition (voir ébauche, pré finition, finition) ; inutile de faire 15 passes de finition !, tu devrais logiquement faire une ébauche avec une "grosse" fraise (cylindrique) et de grosses passes en laissant une surépaisseur pour la finition, puis faire la finition avec la petite fraise et des passes latérale serrées

++
David

Merci David,

Encore une fois tu es une vraie bible.

Note que j'avais déjà fait la manip, il y a quelque temps déjà, pour passer à 4 Go de RAM Cam Bam (puisque je suis en 64 bits)

Je n'avais pas pensé à passer de "profondeur d'abord" à "niveau d'abord" ...

Effectivement j'avais aussi trouvé que la passe en 1 mm dans le styrodur était faible …, mais j'en étais juste aux prémices pour essayer de faire quelque chose.

Je vais également suivre ton conseil en faisant déjà une ébauche, puis une finition.

Encore merci, je te dirais ce que ça donne des que j'aurais fait un essai « en vrai ».

Un grand merci à notre grand manitou : David
Fragaria

Re

Je n'avais pas pensé à passer de "profondeur d'abord" à "niveau d'abord" ...

Ca doit être un bug, car il n'y a pas de raison que ça consome plus ; le nombre de parcours d'outils étant le même dans les 2 cas ... en plus ça ne le fait pas sur tout les modèles ; je viens d'essayer sur un autre objet 3D, et la conso est la même dans les 2 modes

Note que le 'out of memory' peut se produire à la génération des parcours ou à la génération du Gcode.

Dans le cas de ton fichier en 15 passes avec Niveau d'abord, aucun soucis sous XP 32 bits pour générer les parcours, par contre, pas moyen de produire le Gcode, pas assez de RAM

Sur W7 64 avec le patch 4Go, le Gcode passe aussi ... mais ça fait quand même un fichier de ... 2.5 million de lignes !! (et 67 heures d'usinage d'après CutViewer )

++
David

Oui j'ai vu !

(CutViewer est bien utile pour optimiser ses usinages ;-) )

Bon ...
En étant moins bourrin (plus bourrin sur la fraise en fait ...), j'arrive à quelque chose en environ 2h00.
(D'après Cut Viever toujours)

encore merci,
/ Fragaria

en plus de ça, tu peux très fortement augmenter la vitesse d'avance ; en comptant du 100m/min pour la Vc, ça fait 21000 tr et avec un Fz de 0.05, 2100 mm/min d'avance !!

Je ne suis par contre pas convaincu en ce qui concerne la "beauté" du résultat ; à mon avis il faudrait d'abord faire un gros travail sur l'image avant de s'en servir pour faire un objet 3D .. à voir ce que ça donne "en vrai" ..

CutViewer est bien utile pour optimiser ses usinages

oui, en particulier pour la 3D, car il n'est pas simple d'imaginer l'état de surface juste avec un tas de parcours d'outils !! (et je ne parle même pas des petits défauts liés aux réglages de la résolution des op 3D ... qui sont tout à fait impossibles à voir sans la simu ..)

Je ne saurais plus m'en passer de ce simulateur ... et pourtant je ne fais que peu de 3D au final, mais je l'utilise systématiquement ... et il m'a sauvé la vie plusieurs fois !

Une de mes rares pièce en 100% 3D pour un client.
en MDF ; Ø 400mm, H=35mm, brute d'usinage sur la photo, elle vas servir pour faire un master, la pièce finale sera en carbone.





++
David