Salut,
Merci. J’ai donc terminé le document comme promis. Voilà la première synthèse (avec mon environnement de travail ) :
Je travaille sous FreeCAD et voilà donc la pièce prototype à tourner. J’utilise FreeCAD 0.19 parce que je fais beaucoup d’électronique et de petite mécanique associée, son association avec KICAD (module SetUpKicad) est redoutablement efficace et – je dirai- quasi professionnel. C’est un prototype donc exprimé ici par 3 modules
: PART DESIGN (dessin),
SPREADSHEET (tableurs des cotes) et
TECHDRAW (le dessin technique). Classiquement toute modification dans le tableur modifie le dessin et le document technique automatiquement. C’est pratique pour moi quand je reviens quelques semaines après pour ajuster définitivement les tolérances ou modifier des cotes dans le tableur (je suppose que c’est idem pour Solidworx ou Fusion360).
Voilà la pièce résultante. Notez que pour m’adapter au tournage j’ai construit la pièce dans le
plan XZ. On en fait un fichier STL (FreeCAD/Export) que l’on va charger dans CAMBAM et NCNETIC. Entre FreeCAD et NCNETIC, c’est parfait, la pièce se charge selon les bons axes comme nous le verrons. Avec CAMBAM, elle se charge sur l’axe Y donc il faudra la tourner de 90°.
Voilà le dessin technique sous FreeCAD. A partir de dessin technique TECHDRAW (automatiquement ajusté) de FreeCAD, je sélectionne la pièce et je génère sa projection DXF. Il y a d’autres façons de faire sous FreeCAD mais je trouve – pour moi- que c’est la manière la plus rapide.
Je charge à partir de CAMBAM la projection DXF ainsi obtenue dans le plan XY et je la positionne à l’origine (ROTATE, MOVE et NUMERICAL MOVE) de CAMBAM.
J’ajuste le brut et je ne conserve ensuite de la pièce que son profil de tournage (il suffit d’effacer le reste). N’oubliez pas de joindre les 4 segments en un seul polyline. Je génère les passes de tournage sous CAMBAM de manière à obtenir le fichier de tournage « nc ». J’ai également chargé le STL de la pièce à titre de vérification. Comme post-processeur j’utilise pour l’instant MACH03-turn mais je vais changer cela. Bien définir le diamètre du BRUT, d’ailleurs il faut faire un premier tournage sur le tour pour ajuster le brut (ici un barreau de fer doux de 25mm de diamètre), je vérifie au pied au coulisse que j’ai la bonne cote initiale. Si on à usiner un peu trop, pas grave – on réajuste le BRUT dans CAMBAM. On ne touche plus au X de l’outil et on positionne l’outil à son point d’origine machine Z. (pour moi, l’extrémité droite de mon BRUT + dégagement de 2mm) sur le barreau de fer doux.
NCNETIC m’a permis de vérifier que CAMBAM/tournage générait un GCODE bizarre (des cercles) en fin de fichier et un retour dans le brut en fin de fichier (étrange !). On notera également que la ligne 193 n’était pas réellement visible sous NCNETIC car elle était masquée par l’axe X (en bleu), NCNETIC devrait prioritiser la passe (couleur rose) car sinon on peut passer à côter d’une très grosse anomalie. Donc à priori il vaut mieux faire apparaître l’outil dans NCNETIC. J’élimine tout cela à l’éditeur CAMBAM et tout rentre dans l’ordre (mais un point qui reste à creuser, sans doute une erreur de paramétrage de ma part quelque part… donc à voir).
Charger le fichier « nc » de CAMBAM dans
NCNETIC et hop ! miracle de la science,
on a la l’expression du BRUT (le total du rose), la pièce à tourner (en gris) et les passes (lignes roses). Il faut bien vérifier alors qu’on a aucune collision entre les passes et la pièce à tourner (on peut zoomer sur la pièce sous NCNETIC), et que le GCODE crée bien la pièce, que l’outil va pas se balader dans l’objet... Malheureusement, pas de gestion des outils de tournage prédéfinis sous NCNETIC (mais on peut peut-être générer des géométries d’outil… à tester) ni des collisions donc là faut apprécier perso en fonction de l’outil qu’on utilise si cela va coincer quelque part. J’ai choisi pour l’instant l’outil COUTEAU (plus tard j’essaierai de créer d’autres géométries si cela est possible). Si cela coince à cause des angles d’outils prévoir 2 passes (une à droite et une à gauche), dans ce cas arranger votre dessin technique en conséquence (je fais apparaître dans mon dessin un petit artéfact qui me permettra ensuite de construire sous CAMBAM mes 2 passes, ou plus si nécessaire selon la complexité de la pièce à tourner).
L’outil se positionne à gauche, l’outil est là … hé hé… :
On peut sous NCNETIC avancer pas-à-pas en Gcode ou se mettre en HALT à tout moment dans le Gcode. La ligne orange constitue la dernière passe.
Nota 1 : il est bon de bien visualiser la première passe (pour être sur qu’on démarre bien) et la dernière passe (pou être aussi sur que cela se termine bien). On peut rajouter sans doute pour être élégant un code ou une macro Gcode dans NCNETIC de dégagement d’outil et repositionnement à l’origine.
Si tout semble OK, on charge le « nc » dans CAMBAM gbrl, on lance le tour et c’est parti. Notez que la visualisation de CAMBAM/gbrl n’est pas correcte (inversion des axes Y et Z), la faute au plugin qui ne prend pas en compte les opérations de tournage. Si on veut visualiser plus correctement, il y a plein d’outils gbrl sous Windows (UGCS/IOsender) ou Linux (bCNC). J’ai choisi ici visualiser sous UGCS qui me permet de suivre en temps réel sous gbrl le déroulement du gcode avec les copeaux…
J’ai approximé au mieux et rapidement le choix de l’outil à l’aide de NCNETIC de façon suivante :
Au final je choisi l’outil 2 à plaquette de carbure. Notez que la proxxon pd230 usine le fer doux à faible vitesse, le meilleur choix d’outil serait dans ce cas l’acier trempé (si on en a ou si on en fait, sinon HSS ou carbure).
quelques photos du travail... :
On coupe et prépare le barreau de fer doux :
on usine :
Ici l’électronique GbrlCore en test pour piloter le tour proxxon (cela tient dans la main, 4A par moteur ! jusqu'à 6 moteurs NEMA23 ou NEMA54 !) , la carte est équipée de 2 microdrivers TBS109/4A (Z et X) avec une précision de 32 micropas, j'ai aussi testé le TRINAMICS TMC5160 (3.2A),... Elle est montée ici pour l’instant en 3 axes (25 KHz) , mais pourra passer facilement en 6 axes (100 KHz) ou 5 axes (500 KHz) avec des modules additionnels. D’ici 2 semaines, je rajoute le module STM32 Gbrl « 6 axes » pour ma proxxon mais seulement pour 4 axes utilisés. Evidemment le 500 KHz c’est pas pour la proxxon !!!
Mes commentaires :
- CAMBAM reste un outil essentiel pour bidouilleurs (comme moi) que l’on arrive plus ou moins toujours à adapter à ce que l’on veut faire, il se charge en un flash et on peut démarrer des opérations simples en quelques dizaines de seconde. Dommage qu’il ne soit pas plus fourni en fonctions de tournage. L’association FreeCAD + Cambam + NCNETIC + (macros Gcode) peut constituer un outil puissant pour la création de formes complexes pour peu qu’on sache programmer directement en Gcode, l’adaptation de NCNETIC au mode tournage a été rapide et a permis de détecter une anomalie Gcode générée par Cambam (ou de ma façon d’utiliser Cambam). Comme j’ai monté un axe Y sur le chariot (petit étau automatisé) je peux faire aussi de l’usinage en face avant avec mon tour. Donc pour moi – au final – cela se présente bien (tournage et usinage sous CAMBAM). Mon but à terme c’est de monter un raspberry pi 4 avec écran 7 pouces et fonctionner en autonome sur mon tour (CAMBAM pour la conception, bCNC pour la gestion gbrl, ethernet pour piloter Gbrl à distance si je veux travailler à partir de ma station de travail). C’est déjà bien avancé, je vous enverrai les photos quand tout cela sera monté.
- Prochaine action, il faut que j’adapte le post-processeur CAMBAM tournage à Gbrl. Je vais construire 3 posts : un GBRLlegacy-turn, un GBRLHAL-turn et un GbrlHAL-milling. Le nouveau Gbrl est très complet au nouveau Gcode donc cela vaut le coup de le faire. Comme il est maintenant 5 axes, usb ou Ethernet, à interpolation temps réel 500 KHz, Gbrl vaut maintenant aussi le coup d’être monté sur de moyennes machines – c’est ce que je vais faire aussi mais un peu plus tard…
- Côté NCNETIC, il s’intègre bien à FreeCAD et CAMBAM et apporte une visualisation fine du Gcode. Comme éditeur avancé de gcode 4 ou 5 axes c’est plutôt bien. Mais – à mon avis – il manque un PAVE MOUVEMENT NUMERIQUE pour positionner correctement le ou les objects (STL) dans son espace de travail . Ce serait bon en simulation (tournage/usinage) et en ROBOTIQUE pour simuler les mouvements des préhenseurs entre les pièces fixes (prise, insertion, dégagement, …). Une gestion/visualisation/collision de ces préhenseurs (ou « outils » en usinage) avec détection de collision serait évidemment la cerise sur le gâteau. Peut-être en première approche, la collision se limiterait à détecter un contact de « collision » entre les passes Gcode et l’objet STL… Il faudrait préciser aussi comment générer de nouvelles géométries d’outils car en tournage les géométries d’outils sont nombreuses et variées.
- NCNETIC introduit la notion de MACRO GCODE. Ce point est intéressant en tournage et je vais creuser cette fonctionnalité. Le but est d’introduire des développements mathématiques de fonctions connus (triangle, cercle,...) sous forme de GCODE (en interpolation linéaire ou circulaire, ce que gbrl semble faire très bien). Le résultat est une rapidité d’usinage et une précision quasi absolue dans le résultat (à la précision près de la machine et au prix de MACRO pouvant contenir des centaines de lignes) car certaines pièces de précision c’est compliqué de toujours les terminer en tournage à la lime et au papier corindon. Evidemment la précision de NCNETIC permettra de vérifier si la MACRO fonctionne bien. Sans un sw comme NCNETIC la MACRO serait impossible à mettre au point !
- Côté NCNETIC, c’est bien mais il faudrait qu’il précise leur but de développement. Le logiciel est libre aujourd’hui ( mais demain ? ). Pour aller au bout il faut des moyens, un homme ? une équipe ? une société ? Un logiciel non open source insuffisamment supporté dans le futur est condamné à disparaître ou devenir obsolète, comme ce fut le cas de l’excellent CUTVIEWER. Personnellement le fait qu’il tourne sous WINDOWS uniquement peut aussi limiter fortement son utilisation et c’est dommage.
Donc premières conclusions – « personnelles » - à la date d’aujord’hui :
- NCNETIC gagnerait à charger un ou plusieurs objets avec un pavé DEPLACEMENT NUMERIQUE pour bien positionner ce (ou ces) objets dans l’espace de travail
- NCNETIC gagnerait à permettre la réalisation facile d’outils (ou d’objets cinétiques) de différentes géométries. Mais peut-être des solutions existent déjà ?
- NCNETIC gagnerait s’il pouvait proposer une gestion des collisions ad-minima entre l’outil et les objets chargés (ou ad minima un objet). Il pourrait alors prétendre à devenir un puissant simulateur d’usinage/tournage voir de robotique. Mais peut-être des solutions existent déjà ?
- Pour ce type d’éditeurs/simulateurs, une version LINUX serait la bienvenue
Je continue à creuser mais il est clair qu’en tournage je vais utiliser NCNETIC. J’en profite pour remercier pour David qui de tout de suite m’a mis sur les bons rails. Que de temps aurait été perdu sans lui ! là maintenant cela marche et plutôt bien !
Des questions ? n’hésitez pas… je continue mes bidouilles.
A+
Guy-Noel