Le projet 4L1C3, micro-cnc format A4

Aujourd'hui à 17h58, j'ai déclaré:
"Waoooooo ! Waoooooo! P....n de sa m..e !!!! le c.. de sa race !!!! çà marcheeeeeee !!".
Que des trucs que je dis rarement.

... Et ça ne nous étonne même plus !

Je débarque comme un poil de c.l sur la soupe, mais plutot que de réinventer la roue, pourquoi ne pas partir sur une base Arduino + RAMPS ?
Ca me parait completement adapté au besoin ?

il faut relire le post depuis le début (et accessoirement voir les autres réalisations de F6FCO) mais en résumé c'est pour le plaisir du défi et le challenge de la programmation. Pour ce qui est des CNC, il a déjà ce qu'il faut

Ah ben oui, dit comme ça, c'est beaucoup plus clair
J'avais lu le début du sujet, mais je n'avais pas saisi que c'était pour apprendre

F6FCO a écrit:Aujourd'hui à 17h58, j'ai déclaré:
"Waoooooo ! Waoooooo! P....n de sa m..e !!!! le c.. de sa race !!!! çà marcheeeeeee !!".
Que des trucs que je dis rarement.

Venant de toi, on doutait pas franchement

Oh noooon, vous êtres trop gentils

Alors cet après-midi je me suis enfin rendu maître de l'axe X qui m'obéit maintenant au doigt et à l'oeil . Enfin presque parce qu'il reste les fonctions POP à intégrer, mais çà je m'y attelle dés demain. J'ai passé l'après-midi à faire des gcodes tests pour faire bouger mon axe et des calculs manuels pour valider ce que je voyais sur l'analyseur logique. Tout colle et l'axe fait ses allers-retours à la demande avec le nombre précis de pulses.
Voilà ou j'en suis pour l'instant:
- démarrage de la machine (du programme sur le PIC).
- envoi du fichier depuis le terminal Teraterm (sur le PC) qui attendra un appui sur le bouton RUN de la machine pour transmettre son premier train de données.
- je fais ma POM par appui sur le poussoir POM, l'axe fait un retour à l'origine jusqu'à faire coller le capteur ILS qui envoie l'info au PIC, puis il continue en faisant un petit jog précalculé pour venir se positionner à 1mm du bâti. Paf ! Origine X.
- appui sur poussoir RUN pour lancer la réception des données par l'UART, le PIC reçoit la première ligne XYZ et bouge l'axe X suivant la valeur prescrite, il reçoit ensuite la deuxième ligne, etc. etc. jusqu'à recevoir la lettre M qui signifie la fin du gcode.

Pour l'instant c'est basique et tout bouge à partir de la référence zéro X, dés que j'aurai fais la routine POP je pourrai faire un déplacement relatif pour commencer l'usinage n'importe ou sur l'axe.

Après pour Y et Z çà ne sera pratiquement que du copier/coller. Enfin j'espère que çà se passera comme çà

Pour répondre à Napo7 (belle photo):
- Ré-inventer la roue ? mais c'est l'essence même du bricoleur  
- je me suis longtemps amusé avec les arduinos qui sont de supers microntrôleurs améliorés très pratiques pour apprendre et faire du prototypage rapide mais je leur reproche quelques limitations et leur interface de déboggage inexistante. A coté de cela j'avais envie de me remettre à l'assembleur que j'avais pratiqué il y a très longtemps, je me suis frotté un moment avec les AVR mais j'en ai eu marre des bugs d'AVR Studio alors le mieux c'était de laisser les arduinos et autres atmégas dans leur tiroir et  faire une immersion complète dans le monde des PIC. Ca à été un peu laborieux au départ, comme à chaque fois qu'on apprend un truc nouveau, j'ai commencé avec un 16F, puis je suis passé aux 18f plus performants et jeu d'instructions plus fourni. Je ne regrette pas et je ne crache pas sur les arduino avec lesquels je me suis bien amusé mais je crois qu'ils vont rester longtemps dans leur tiroir, le monde des PIC est trop fabuleux.

Oui, si on ne réinventait pas la roue, on resterait idiot

Il me semble qu'il y a bien une interface de débogage sur les atmega, nommée DebugWire.
Je ne l'ai jamais mise en pratique cela dit !

AVR Studio, jamais utilisé !
A vrai dire ,j'utilisais au début l'IDE arduino, puis je suis passé (et resté !!) au couple Atom + Platform.io (en plugin pour atom), qui sont super !!

Paradoxalement à ce que tu dis, j'ai lu beaucoup de mal de MPLAB de la part de la communauté des "makers" : pas dispo ailleurs que sous Windows (enfin, pas sous linux en tout cas), compilateur C longtemps payant et reservé aux processeurs de la gamme 18 et +...
J'ai pratiqué le PIC aussi, j'ai toute la solution domotique de ma maison qui est basée sur des PIC 18F2550 (via DOMOCAN, la solution ecrite par BigonOff), mais je change d'ailleurs, non pas a cause des PIC mais à cause du bus CAN, qui au final apporte plus de contrainte que de souplesse de mon point de vue... Mais ca n'est pas le sujet du jour

Bonjour Napo7,
DebugWire n'est pas une interface mais un moyen de déboggage, disponible entre-autre sous AVRStudio. Je l'ai utilisée en son temps mais AVRStudio m'a fait tellement de misères que j'ai migré sur PIC, depuis que du bonheur. Pour utiliser DebugWire il faut posséder un émulateur/programmateur qui fait l'interface entre ton circuit et l'IDE. J'utilisais le moins onéreux, l'AVR Dragon qui est l'équivalent du PICKit3 chez Microchip, ce Dragon dort lui aussi en ce moment dans le tiroir AVR/Arduinos, peut-être ressortira-t'il un jour.

MPLab buggé ? certainement oui, tous les gros softs le sont plus ou moins, mais à mon point de vue bien moins qu'AVR Studio dont je n'ai rien pu tirer de bon, le mien avait vraiment un fonctionnement instable. Encore faut-il savoir si on parle de la version MPLab 8.92 utilisée par les codeurs en assembleur ou bien de MPLabX, version plus récente dédiée au C, que je n'ai encore pas utilisée mais qui semble être une vraie usine à gaz.

J'avais installé Atom en son temps ainsi que plusieurs autres IDE (Context, Notepad++, Jext, Sublime Text, etc.) pour pallier à celle d'arduino, mais elles n'amenaient pas ce que je cherchais, pouvoir débugger en pas à pas avec visu des variables, etc., tout ce que doit faire une véritable IDE. J'ai un peu améliorée l'IDE d'origine car sa pauvreté graphique me désolait, et fait quelques macros pour faire du pseudo débuggage pas à pas via l'interface série: http://f6fco.pagesperso-orange.fr/IDE.htm. Mais bon, toujours pas ce que je recherchais.

On peut faire des comparaision entre AVR et PIC (bien que maintenant tout sorte de chez Microchip) mais pas entre arduino et PIC. Arduino n'est rien d'autre qu'un AVR bridé pour le simplifier et être mis à la portée du plus grand nombre, ce qui est une bonne chose.

As tu essayé platform.io ?
Si non, je t'invite à y consacrer quelques heures, il vaut largement le coup
PS : c'est un "package" pour Atom. Atom sans platform.io n'est autre qu'un simple editeur de texte...

C'est vrai que toutes les 'IDE' que j'ai citées ne sont que des éditeurs de texte un peu améliorés. Qu'est-ce que Platform.io amène à Atom ? La seule chose essentielle pour un programmeur est de pouvoir faire du déboggage pas à pas avec visu des variables et mieux encore, des registres.

Platform.io apporte , pour commencer, la compilation du code (C, C++) directement depuis l'IDE, le support des librairies tierces (une sorte de library manager comme celui de l'IDE Arduino), un support de centaine de CPU différents, l'autocomplétion, l'analyse syntaxique "en live" avec soulignement des erreurs en live, etc...
Coté Python je l'ai déjà utilisé pour débugger, mais je n'ai jamais testé avec des µC, il y a peut etre (surement! ) moyen de le faire !

D'accord, finalement pas beaucoup plus que l'IDE arduino et pas l'essentiel qui est le débuggage d'un programme en temps réel et in-circuit, à moins peut-être de bidouiller ce qu'on n'a pas forcément envie de faire, perso je préfère me prendre la tête sur un bon algorythme que sur le fonctionnement d'une IDE

Pour en revenir au sujet je viens de faire des captures d'écran du fonctionnement d'4L1C3:
Petit gcode qui me sert à faire mes tests:



Capture du premier train de données reçues X0001 Y0001 Z0001. On y voit les valeurs ASCII contenues dans le train (le 13 et le 10 finaux sont le retour ligne et l'interligne),
- la ligne CTS passe à l'état bas pour autoriser la réception UART venant du PC.
- on reçoit la première ligne gcode XYZ
A la fin du train:
- la ligne CTS repasse à l'état haut pour stopper la réception
- la série de pulses démarre et est transmise aux moteurs via les drivers
- la ligne de direction (CW/CCW) passe à l'état haut donc translation en sens avant.



Capture un peu plus large de ce qui se passe entre deux trains de données, ici entre la première et la deuxième ligne du gcode:

X0001 donc 1mm à parcourir, en 1/4pas çà fait 800 pulses, ce qui est validé par l'analyseur logique
La ligne CTS reste à l'état haut le temps aux axes de se mouvoir, ceci fini elle repasse à zéro le temps d'autoriser le deuxième train (la deuxième ligne de gcode) et rebelote.
La ligne de direction ne change pas car on reste en sens avant.
L'analyseur indique aussi la fréquence des pulses qui est de 4,59Khz, fréquence idéale de fonctionnement pour ce couple driver/PAP, définie aux essais avec le géné TTL.



A noter que pour le programme recalcule le nombre de pulses à générer, pour le deuxième train X=0003 donc on devrait générer 3x800=2400pulses mais on en fera en réalité que 1600 car on a déjà parcouru 800 dans la même direction.

Superbe travail F6FCO!

Par contre à la vue de ton train de pulses, est-ce que tu gères les accélérations/décélérations?

Bonne journée.

Non, c'était prévu au début et en fait je n'en ai pas besoin. La machine est très petite et ne force pas pour emmener son stylo et il n'y a pas de perte de pas. Il n'en serait pas de même avec un axe lourd et entrée dans la matière.

Bonjour a tous les instigateurs de ce post.
Mais ne pensez vous pas que l'on est à des années lumière du bricoleur lambda !!!!!!

F6FCO a écrit:Non, c'était prévu au début et en fait je n'en ai pas besoin. La machine est très petite et ne force pas pour emmener son stylo et il n'y a pas de perte de pas. Il n'en serait pas de même avec un axe lourd et entrée dans la matière.

Tant mieux car ça aurait été assez compliqué à gérer en assembleur...

Tu as raison, pas simple à faire quand on creuse la chose, tu touches le point sensible parce que j'ai pas mal cogité dessus. Pas tant l'accélération par elle-même, ou même la décélération, qui sont assez simple à mettre en oeuvre, avant de commencer ce projet j'avais fais quelques routines pour tester çà:



Petit algorigramme qui donne çà une fois codé (si çà intéresse certains je tiens le code à disposition):



Çà marchait très bien, pas difficile de faire une incrémentation ou décrémentation de durée des alternances basses par exemple (ou hautes si on veut). Le souci que j'ai eu c'est que pour faire une accélération il faut avoir un certain nombre de pulses, on ne fait pas une accél sur deux ou trois pulses. Comme on ne trouve pas beaucoup d'infos sur le web sur ce sujet je me suis débrouillé tout seul pour me faire ma culture: j'ai baissé la vitesse de ma grosse CNC au minimum pour pouvoir observer son comportement. J'ai espionné LinuxCNC
J'ai baladé les axes et il en est ressorti qu'elle faisait ses accélérations sur environ 15mm.
Bien sur c'est propre à ma CNC, çà doit varier en fonction du réglage micro-pas, des réglages et du poids des chariots pour chaque machine.

Je ne me rappelle plus trop mais comme çà de mémoire il me semble que je l'ai réglée en 1/8e de pas, donc 1600pas pour faire 1 tour, VAB1605 donc un tour 5mm --> 1600pulses pour 5mm donc 15mm=4800pulses pour faire une accélération (je viens de faire les calculs de tête, vous me dites si je dis des c.....ies ). Donc à partir de là pas de souci, çà se fait bien.
Mais....
Si on doit parcourir moins de 15mm ???? ce qui est le cas le plus souvent en usinage, disons 1mm ou 2, voire même 0.1mm ? ou moins encore ? On fait une accélération comment sur quelques pulses ?

Je n'ai pas la réponse du coup je suis bien content de ne pas être obligé de gérer l'accélération/décélération sur cette petite CNC

Ah au fait, çà y est les POP sont fonctionnelles. (enfin celle du X puisque je ne gère que cet axe pour l'instant)

Salut,
super projet bien au delà de mes compétences
Pour l'accélération sur ma grande machine j'ai des pentes faibles donc pour un déplacement court la vitesse de consigne ne pourra jamais être atteinte. la pente d'accélération ne change pas suivant la distance.
Si j'ai bien tout compris....
Denis

Donc tu veux dire une pente tronquée pour des petites distances ? tes observations sont visuelles ou tu as des données ? si tu en as de quelques sortes sur le sujet je suis preneur

Donc tu veux dire une pente tronquée pour des petites distances ?

Exactement

Non c'est un constat visuel car j'ai une pente d'accélération faible vu les masses mis en mouvements.
Mais il me semble que j'ai lu ça quelque part, dans la doc mach3 je crois.

C'est une info intéressante qui amène de l'eau à mon moulin. Et puis même si la pente est tronquée finalement ce n'est pas grave puisqu'on n'a pas à atteindre la vitesse maxi sur les petites distances.
Du coup c'est jouable de programmer (pour une machine plus grosse que la mienne) des pentes d'accélération.

@rofra, et bien même si je désespère de savoir un jour faire des trucs pareils il me semble, sans vouloir offenser aucun des protagonistes, qu'on reste dans le domaine du bricolage sauf qu'au lieu d'être dans le domaine du bois ou du métal, on est dans celui de l'électronique (et encore, seulement pour les derniers posts, le début du sujet ayant été consacré à la construction mécanique).
Comparativement, que ce soit en terme d'équipement ou de connaissance, ce qui est présenté dans ce post me semble tout à fait comparable à ce que peuvent présenter sur ce forum différents "bricoleurs" du bois ou du métal (il n'y a qu'à aller voir le sujet de Pili et son ulm ou avant ses rabots!)

Salut,
D'accord avec ce dernier message, nous ne sommes pas égaux face au bricolage. Nous n'avons heureusement pas tous les mêmes compétences, centres d'intérêt ou équipements, ce qui permet aussi le partage et c'est tant mieux.
Pour avoir pratiqué l'assembleur il y a fort longtemps je suis tout de même admiratif face à F6FCO. Le problème n'est pas tant la programmation, il se situe surtout dans l'analyse de tout ce qui doit être programmé. Par exemple le point qui vient d'être évoqué en parlant des accélérations.

Petite boutade sur le sujet :
Un programmeur est un imbécile !
Et ça se vérifie simplement, le plus inculte d'entre nous, cependant intelligible, à besoin de 3 000 mots pour s'exprimer.
Un langage de programmation, assembleur ou autre, a besoin de 50 à 100 mots pour fonctionner.
Donc un imbécile peut facilement maitriser ce langage...

Si je dis ça en toute liberté c'est que j'ai programmé pendant plus de vingt ans.

Tout ça pour dire que le difficile dans la programmation ce n'est pas de programmer, mais de bien analyser le problème à résoudre. Et quand je dis le problème, il s'agit en fait de la multitude de problèmes qu'a rencontré et que rencontre notre ami F6FCO pour faire bouger comme il se doit sa machine. Bravo à lui

Quand on parle de GCode le raisonnement est le même, c'est un langage comme un autre. Si on n'analyse pas correctement la façon dont on doit usiner sa pièce, on va aussi droit dans le mur !

Je trouve aussi que c'est du bricolage, on est loin d'un LinuxCNC ou d'un MACH3. Je me suis lancé dans la CNC sans rien y connaître (comme tout le monde en fait), mais j'aime bien aller au fond des choses. Après avoir construit plusieurs CNC d'amateur la finalité était forcément d'essayer de créer un soft pour faire le tour du sujet.

Oui, je pense aussi que la démarche d'esprit est similaire entre la programmation et l'analyse d'un usinage. En fait c'est juste de la logique.
J'aime bien ta boutade, je me la met de coté

Je pense que le plus gros du boulot est fait. Je m'attaque à l'axe Y, normalement rien que du copier/coller du X en changeant des labels mais il y a tellement de lignes que l'erreur va guetter au passage.