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.

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.