Modification d'une petite CNC Kosy2

Bonsoir à tous les bricolos, ferraillous et autres en soif de savoir !

Moi aussi, j'aimerais bien savoir ! J'ai récupéré dernièrement une petite CNC Kosy2 format A4 distribuée à l'époque par Max Computer GmbH. Cette dernière fonctionne bien avec un convertisseur USB/RS232 ainsi que son logiciel nccad. Cependant, ce dernier a vite des limites et, qui plus est, fonctionne sous Windows XP mais pas ultérieur.

Je cherche donc à pouvoir piloter ma petite CNC avec un Arduino Uno. Et c'est là que je demande un peu d'aide... Quelle est, selon vous, la meilleure option.

- Solution 1 : conserver moteurs et drivers d'origine
- Solution 2 : conserver uniquement les moteurs puis prendre un shield CNC pour Arduino
- Solution 3 : remplacer drivers et moteurs

Je joins quelques photos pour la bonne cause...

D'avance merci pour votre aide.

















Eric

Salut,

Le problème en passant à un Arduino, c'est que tu vas devoir utiliser le langage GRBL au lieu d'un "vrai" Gcode ISO ; le GRBL à pas mal de limitations. (pas de gestion de changement d'outil, pas de gestion des cycles de perçage, performances limités ..) .. à moins que tu ne fasse que des travaux ultra basiques (gravure, découpe 2D) je te déconseille le GRBL.

Tu peux simplement la piloter en port // via une simple Breakout Board à 20€ des drivers séparé basique et Linux CNC (gratuit) ou Mach3 si tu préfère rester sous Windows, et la tu pourra utiliser du Gcode ISO nettement plus performant. (dans la cas de Mach3, il faut un windows en 32 bits ; XP, 7, ou autre, mais en 32bits)

Ce sujet devrait t'intéresser
http://www.metabricoleur.com/t13857-modifications-d-une-fraiseuse-cnc-kosy

Par contre pour la carte SmoothieBoard qu'a mis Wyldix, même pb qu'avec l'arduino et GRBL, ça ne comprend qu'un Gcode très limité, et qui plus est, totalement orienté impression 3D et non fraisage.

http://smoothieware.org/supported-g-codes

Donc même chose que GRBL, pas de gestion des changements d'outil (M6), des cycles de perçage (G81/82/83), du dispositif de vitesse constante/arrêt exact (G64/G61) de la compensation du rayon d'outil (G40/41/42) de la longueur d'outil (G43) ....

++
David

Bonjour,
David a tout dit sur les désavantages de GRBL, même si ça reste mon choix en raison de l'énorme différence de coût. Si je passe à une CNC plus pro je franchirai surement le pas, à moins que d'ici là une carte open source fasse le job ou qu'il existe une solution GRBL évoluée (peu probable vu que son concepteur veut rester sur l'arduino uno dont la mémoire est saturée par l'actuel GRBL).

Si néanmoins tu restes sur une solution Arduino/GRBL, je te conseille de garder tes moteurs et tes drivers, j'ai câblé les miens sur un arduino nano sans soucis alors sur une uno tu n'auras aucun problème. Tu peux aussi utiliser un shield type ramps, les drivers qui sont dessus me semblent bien légers mais tu peux y câbler les tiens.

Bonjour,

J'avais le même problème que vous il y a 2 ans.

J'ai récupéré une kosy3 (A4,IF5,64b).

Après plusieurs analyses (coût/gain), j'ai décidé de :
   • garder l'électronique de max-computer (avec une petite mise à jour du contrôleur du MSC en le passant à 128b(fait par max-computer pour ~60€)) ;
   • Pour le fraisage :
       ◦ utiliser Fusion360 pour :
            la CAD ;
            la CAM ;
            la génération du G-CODE (générique)
            le post-traitement du G-CODE pour l’adapter aux machines Kosy
       ◦ utiliser nccad (soft de kosy) pour uploader le G-CODE dans la machine.
   • Pour l’impression 3D
       ◦ utiliser Fusion360 pour générer un STL ;
       ◦ utiliser slic3r pour générer un G-CODE à partir d’un STL ;
       ◦ utiliser un script maison pour adapter le G-CODE à Kosy en utilisant le C-AXE pour piloter le moteur pas à pas de l’extrudeuse de l’impression (le contrôle de la température de l’extrudeuse est réalisée par un petit nano-arduino) ;

ça marche à merveille.

Cordialement.

Bonjour,

Ce topic n'est pas très jeune, mais j'y apporte ma contribution au cas où ça puisse être utile à d'autres.

Je suis dans la même situation (KOSY2 récupérée) et ai opté pour une solution plus radicale, permise par ce qui est disponible actuellement. J'ai totalement remplacé l'électronique de contrôle par une carte Makerbase MKS SGEN v1, flashée avec la version CNC du firmware. Je n'ai gardé de l'électronique d'origine que la partie alimentation et commutation de la broche.



La MKS et les drivers sont dans un coffret externe déporté pour faciliter la maintenance:



Pour ce qui est du logiciel de contrôle, je fais partie de ceux qui ont jeté leur dévolu sur Linux depuis presque 10 ans (après un très long parcours chez Apple et Microsoft, et sachant que mon premier contact avec les ordinateurs remonte à... 1977 et les mainframes IBM). C'est ce qui me convient le mieux pour un tas de raison (et pas financières), aussi bien à titre professionnel que personnel. Je ne cherche à convertir personne, à chacun ses choix et ses raisons.

Dans ce contexte, le design se fait avec n'importe quelle application pouvant produire du SVG (par exemple Inkscape) et je pense utiliser bCNC pour la génération du GCode et le pilotage de la machine. Si j'ai écrit "je pense", c'est que pour l'instant les travaux sont en cours et avancent lentement faute de temps libre. Encore que le confinement actuel limitant les possibilités de sortie, les progrès sont plus importants depuis ces dernières semaines. Voilà au moins un point positif à cette situation pour le moins préoccupante.

Une autre option que j'envisage très sérieusement et que j'ai commencé à explorer est la génération de GCode par scripts Python. Je suis en effet un peu réfractaire aux clicodraumes, dans lesquels on perd beaucoup de temps à mon avis à chercher où le concepteur de l'appli a caché les commandes et options, à faire des aller-retours entre clavier et souris, et à se battre pour répéter des opérations. Or la plupart du temps, les pièces que nous les amateurs réalisons peuvent se décrire assez facilement par des primitives géométriques simples, de positions et dimensions connues (segments, rectangles, arcs,...). Je trouve du coup plus efficace de dire tout cela par une succession de commandes équivalentes, regroupées dans un script. Il est alors facile pour quoi sait programmer un peu de répéter une forme de base, de la transformer,... et surtout d'apporter des modifications rapidement. Par exemple si j'ai dupliqué n fois un certain motif, et que je veux en changer une caractéristique, ou sa distribution sur la pièce, je n'ai qu'un endroit à modifier, au niveau de la définition du motif ou de la logique de duplication, et c'est tout. Pas de série de clics, saisie de valeur, validation, re-clic, re-saisie,... Ajoutons à cela qu'il est facile de se créer des bibliothèques de formes complexes simples à réutiliser, et on imagine le gain de temps à la clé.

Là encore, je ne dis pas que cette option est meilleure que la voie graphique, mais c'est celle qui a des chances de me convenir le plus. Je suis d'accord avec le fait qu'elle requiert certaines aptitudes en matière de programmation (sans pour autant demander d'être un développeur pro de logiciel), mais elle peut valoir la peine.

Pour en revenir à la Kozy, j'ai essayé de trouver les caractéristiques de ses moteurs, et leur résolution ne figure pas dessus. Si je me base sur la résolution très théorique de 1.25 microns, compte tenu du pas des vis (4mm) j'aurais tendance à supposer que ce sont des 400 pas/tour utilisés en 1/8 de pas. Mais ça peut aussi être des 200 pas/tour utilisés en 1/16 de pas. Je verrai cela avec ce que ça donne une fois la MKS connectée aux moteurs, mais si d'aventure quelqu'un avait l'info, je suis preneur.

Je reviendrai ici pour donner des nouvelles du projet si ça peut intéresser du monde.

Cordialement.

Salut,

Quelques jours de congé ont permis de bien avancer le projet, qui est maintenant quasiment terminé:



Le carter avait été récupéré avec la machine. Il a nécessité une petite remise en état, dont la supression de la sécurité porte, qui actuellement coupe l'alimentation (avec dérogation possible via l'interrupteur à clé). Si ça se comprend totalement dans un contexte d'usage scolaire, c'était un peu too much pour mon usage perso. Et si on perd la clé, c'est ballot

La table sous le carter a été réalisée à base de chutes (teintées en noyer ancien pour le look) et de roulettes récupérées sur des chaises de bureau qui partaient à la benne à mon boulot.

Comme dit précédemment, l'électronique de contrôle a été remplacée par un carte MKS SGEN de Makerbase :



J'ai aussi remplacé les boutons poussoir (!!!) faisant office de fins de course par de vrais fins de course :



Quelques finitions encore au programme, dont la révision du système de la tablette. Elle se replie actuellement vers le haut façon portes "élytres" (avec loquet magntéique pour la maintenir en place), ce qui présente l'inconvénient de laisser la béquille proéminante (ce n'est que de la valeur de sa section, mais on risque de l'accrocher en passant une porte). Le repli se fera vers le bas, mais il faut du coup modifier la béquille pour l'articuler en deux parties.

Et on pourra enfin usiner ensuite... dès que j'aurai approvisionné les fraises. Si vous avez des plans intéressants sur ce point, je suis preneur.

Cordialement.

Hoooo, une linux mint ! Un linuxien de plus sur le forum, on va finir par être plus nombreux que les adorateurs de la pomme

meles a écrit:Hoooo, une linux mint

Je vois que nous avons affaire à un connaisseur : il a reconnu le logo

Concernant Linux, il faut reconnaître qu'il n'y a pas mieux pour recycler des machines à bout de souffle. Je les collectionne, car mon entrourage me donne son "vieux" matériel avant d'aller jeter son dévolu pour un nouveau portable sous Fenêtres 10. Du coup, c'est nickel pour une bécanne qui va passer du temps dans un atelier.

Bonne journée,
Merci pour toutes ces informations sur la modification de la fraise Kosy2. J'aimerais utiliser un Arduini Uno pour faire fonctionner la fraiseuse avec GBRL. Pour cela, j'aimerais réutiliser les anciens pilotes de moteur pas à pas. Je pense que l'on pourrait tout simplement débrancher le circuit imprimé avec le processeur (étiqueté Con2) et connecter l'Arduino aux 51 broches. Mais comment se passe exactement la connexion ? Un Arduino n'a pas 51 broches ? Malheureusement, je ne comprends pas les inscriptions.
L'un d'entre vous a-t-il trouvé comment relier exactement les différentes broches ?
Avec mes meilleures salutations d'Ulm, Allemagne
Stefan

PS : J'utilise DeepL pour la traduction - j'espère que c'est compréhensible.

Traduit avec DeepL.com (version gratuite)

Bonjour Stefan,

Pas de problème pour la traduction, c'est tout à fait compréhensible  

Il y a peu de chances que les 51 signaux soient utilisées, car le contrôle de chaque axe n'en demande que deux (step et dir). Si on ajoute un fin de course par axe, on arrive à 9 signaux. On peut en ajouter encore un pour la commande de broche si on veut l'automatiser, et un autre pour un palpeur d'outil. On est donc très loin des 51.

En fait, si tu envisages d'utiliser une Arduino, j'aurais tendance à te conseiller une approche similaire à la mienne, à savoir mettre de côté  l'électronique d'origine. Il existe pas mal de shields destinés à piloter une imprimante 3D ou une petite CNC sur la base d'une Arduino chargée avec un firmware Grbl. Ne conserve que l'alimentation au mieux et connecte les moteurs aux drivers du shield.

Pour ce qui est de l'Arduino, attention cependant au fait que les modèles 8 bits peuvent se révéler un peu limités question puissance de traitement, d'autant plus que les calculs d'interpolation pour des droites ou des arcs nécessitent des opérations sur des flottants. A ce titre, une carte à base de proc 32 bits (genre Cortex Mx ou équivalent) est préférable. C'est ce qui est au coeur de la Smoothie board, qui semble malheureusement être un projet arrêté actuellement (encore que j'ai vu un Kickstarter assez récent pour une version 2 de la carte). Dommage si c'est vraiment le cas, car ça fonctionne vraiment très bien.

J'ai également entendu parler de solutions à base d'Arduino 8 bits, mais dont le rôle se limite à la génération des pulses pour les moteurs pas à pas su la base de commandes envoyées par un PC, qui se charge de l'interprétation du GCode. Je n'ai aucun retour d'expérience concernant cette option, mais elle ne me séduit pas beaucoup car très tributaire de la stabilité de la communication PC<->Arduino. Tout "hoquet" à ce niveau peut en effet se révéler catastrophique au niveau du comportement de la CNC.

Cordialement
Eric

Sinon, il y a en GRBL la solution de la carte développée par Romain sur maker.fr.
J’ai vu un article décrivant le retrofit d’une CNC Jeulin avec ce système, apparemment satisfaisant…

il y a aussi Cambam, gbrl est repris dessus, investissement leger, ou tu installe mach 3 avec un vieux pc sous windows 7, ça fonctionne parfaotement, ici tu as un grand spécialiste, dans ce cas tu part sur des bases hyper saines et simples pour toi, et surtout des conseils tres avisés(j'en reçu pas mal ici).
achat drivers , carte interpolation, cela supprime les arduinos uno qui limités en puissance.

Quand on fraise on a besoin de fiabilité, c'est tellement rageant de voir une piece, foirer a cause du hard. Au debut je suis passer par du pas cher etc, j'ai mis plus de 3 ans pour arriver au resultat final, bien sur en passant par des arduino, pas la bonne solution.

ce n'est qu'un avis

charrier a écrit:il y a aussi Cambam, gbrl est repris dessus, investissement leger, ou  tu installe mach 3  avec un vieux pc sous windows 7, ça fonctionne parfaotement, ici tu as un grand spécialiste, dans ce cas tu part sur des bases hyper saines et simples pour toi, et surtout des conseils tres avisés(j'en reçu pas mal ici).
achat drivers , carte interpolation, cela supprime les arduinos uno qui limités en puissance.

Quand on fraise on a besoin de fiabilité, c'est tellement rageant de voir une piece, foirer a cause du hard. Au debut je suis passer par du pas cher etc, j'ai mis plus de 3 ans pour arriver au resultat final, bien sur en passant par des arduino, pas la bonne solution.

ce n'est qu'un avis

Bonjour,

il est bien évident que la solution arduino/GRBL n'est pas comparable avec une vraie carte et des logiciels pro. C'est comme si on comparait une Dacia d'il y a 10 ans achetée 200€ à une Mercedes rutilante à 50 000€. Chacune va te transporter d'un point à un autre mais l'agrément et le confort ne sont pas les mêmes.

Un Arduino Nano coûte moins de 2€ sur Ali, 4€ avec le port, Steffinuss à déjà les drivers donc pas besoin de shield ; pas non plus besoin d'un PC dédié avec une antique version de Windows et un port parallèle, on peut utiliser n'importe quel PC et avec Linux ce qui fait aussi baisser le coût. Pas de logiciel à acheter GRBL et Bcnc sont des logiciels libres.

Mais depuis que ce fil existe il y une révolution coté GRBL, il existe maintenant une version pour ESP32 qui est beaucoup plus puissant et rapide que l'Arduino, il a beaucoup plus de mémoire. Un grand pas en avant a été fait en direction du matériel pro.
Un lien en français qui date de 2019 : https://civade.com/post/2019/09/29/CNC%3A-GRBL-sur-ESP32-serait-l-arme-absolue-pour-piloter-des-machines-%C3%A0-commande-num%C3%A9rique
Mais depuis beaucoup d'eau a coulé sous les ponts et FluidNC à pris le relais de GRBL : http://wiki.fluidnc.com/

Ces mots n'ont pas pour but de convaincre qui que ce soit, ils sont juste là pour informer sur l'avancement de GRBL.

Merci Michel74 pour l'info concernant FluidNC que je ne connaissais pas jusqu'ici. Et je suis d'accord avec toi concernant le côté trop limité question puissance de l'Arduino.

En me documentant sur FluidNC j'ai au passage découvert l'existence d'un certain nombre de cartes de contrôle qui le supportent et qui sont du coup une alternative à la Smoothie Board, projet semblant maintenant abandonné (le site smoothieware.org n'est plus inaccessible, même si le GitHub l'est toujours et semble toujours recevoir des updates). Dommage car le tandem Smoothie Board / bCNC sous Linux fonctionne plutôt bien (en tout cas pour l'usage que je fais d'une CNC).