Le projet 4L1C3, micro-cnc format A4

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.

Hello tout le monde,

Ca y est l'axe Y est également fonctionnel.
Comme je n'ai toujours pas fais de vidéo voici une petite capture de l'analyseur qui en dit autant voire plus, de toutes façons on n'aurait vu que deux axes faire des aller-retours, rien de bien fascinant.
le gcode est identique pour le X et le Y ce qui permet de comparer et rechercher des erreurs éventuelles.
Les pulses qui sont avant le marqueur vert N°1 à gauche sont les retours aux POM avant de commencer la lecture du gcode. On voit que les axes fonctionnent en séquentiel, d'abord le X, ensuite le Y avant de passer à la ligne gcode suivante.

Je vais encore faire quelques tests avant de m'attaquer au Z.



@David, si tu nous lis:
J'ai voulu faire un premier gcode un peu plus élaboré pour tests avec le postpro spécial 4L1C3. Mais j'ai des informations I et J perturbatrices qui se sont insérées dans le code. J'ai scruté le postpro sans trouver d'ou elles proviennent, tu auras certainement une idée comme d'hab

PS: Je viens de trouver: centres X et Y d'en arc, je retourne voir çà de près.

Re,
Je pense que la solution est pour l'instant de ne pas insérer de cercles ou d'arcs dans mes gcodes. Je reviendrai la-dessus quand la machine sera opérationnelle.

Et voilà comment se termine un projet presque abouti  
L'axe Z est celui qui est le plus délicat à programmer car tout y est inversé. Un moment inattention, mauvaise direction et CRACK !!! La pièce du bas du chariot Z est cassée, elle n'a pas supporté la pression du moteur Z. Et comme je n'ai pas les moyens techniques pour réparer çà en ce moment....



Il ne manquait plus grand chose à faire pour qu'elle soit fonctionnelle, les deux axes X et Y étaient fonctionnels, le Z presque fini, il ne restait plus qu'un petit bug à régler sur cet axe.
Finalement ma signature ce n'est pas de l'humour   Il faut barrer le mot "enthousiaste" pendant quelques jours.

F6FCO a écrit:Re,
Je pense que la solution est pour l'instant de ne pas insérer de cercles ou d'arcs dans mes gcodes. Je reviendrai la-dessus quand la machine sera opérationnelle.

Argh, pas de chance pour la casse !! (on dirait que c'est aussi fendu en haut !)

Pour avoir une succession de courtes lignes à la place des arcs, dans ton PP, section Options – Sortie des arcs, met le réglage sur Convertir en lignes

++
David

Bonjour à ceux qui suivent.

J'essaie de réparer mais sur un coin de table et sans atelier pour faire quelque chose de sérieux ce sera juste du rafistolage. J'ai essayé de consolider avec du recollage et quelques vis supplémentaires, le but c'est que çà tienne au moins jusqu'à la fin du projet. Mais bon, le médium...   .
Qui vivra verra.





En attendant que tout çà sèche j'ai fais un peu de 3D

hello,

Waouh super image ! Bravo
Et désolé pour tes déboires, le parcours vers la réussite et la gloire est souvent semé d’embûches
La fin du projet n'en sera que plus beau.

Merci Athanase, il fallait que je fasse au moins quelque chose de bien pour me remonter le moral

J'ai rafistolé 4L1C3 mais bon, elle marche un peu moins proprement, le chariot X gigote un peu quand il translate. J'ai été obligé de tout démonter pour faire la réparation mais les fixations par vis dans du médium, forcément au remontage...
Pas grave je ne compte pas l'encadrer, le tout c'est que je puisse mener mon projet de programmation à son terme, après je pense qu'elle sera cannibalisée pour récupérer les moteurs et deux ou trois autres trucs.

Et puis bientôt, la V2, en alu anodisé !

A+

Tu me fais rêver là mais il faut avoir un atelier pour faire çà.

Hello

Toujours surlecutant le F6

F6FCO a écrit:Tu me fais rêver   là mais il faut avoir un atelier pour faire çà.

dixit le gars qui a une cnc de ouf en béton

bon, en attendant, il te faudrait l'atelier d'un gentil membre qui a une cnc opérationnelle et qui est parti en vacances, ou qui est dans le coin

Lol.
Voilà à quoi ressemble mon atelier actuel, et pas prêt de changer je dois finir la maison avant



Y'a tout ce qu'il faut mais faut des échasses.

Bonsoir à tous,
Ca y est, 4L1C3 commence à faire ses premiers gribouillis mais elle ne sait pour l'instant faire que des lignes verticales et horizontales et elle en a marre de dessiner des carrés, c'est le moment de lui apprendre à tracer des diagonales.


Question à David :
Pour l'instant pour dessiner une diagonale bleue elle fait le parcours rouge (fig.1), donc je me retrouve avec un angle au lieu de ma diagonale. Pour obtenir une pseudo diagonale je suis obligé de décomposer manuellement cette diagonale avec poly add point dans cb, j'obtiens l'escalier rouge (fig.2) suivant le nb de points rajoutés.
C'est laborieux et impensable sur un tracé compliqué.
Tu aurais une idée pour résoudre le truc ? Vu qu'on a fait un postpro vraiment simplifié c'est certainement de là que vient le pbm.



NOTA: bizarrement tout ce que j'ai dessiné en rouge sous Paint sort en gris sur MB mais l'idée est là.

Salut,

J'ai fait une diagonale allant de X0 Y20 à X20 Y0 et en utilisant le PP Brat robot XY V5, j'obtiens bien un code correct.

Z000005
Z000005 X000000 Y000020 'positionnement à X0 Y20, Z en l'air
Z000000 X000000 Y000020 'descente à Z = 0 (c'est ma prof finale)
Z000000 X000020 Y000000 'usinage jusqu'à X20 Y0
Z000005 X000020 Y000000 'remontée du Z
Fin

Je pense que c'est ton code qui n'interprète pas correctement le Gcode ; il doit lui même faire l'interpolation (donc calculer des points sur la droite)

Il n'y a pas de fonction du PP pour faire ça ; la seule méthode via CamBam, c'est de créer des listes de points sur les polylignes, par exemple avec Dessiner/Points/Contour géométrie par pas avec une valeur de pas de par exemple 0.1mm sur les polylignes sélectionnées, ce qui créera une liste de points dense puis ctrl + P sur cette liste de points pour la convertir en polyligne. Cela peut être fait en utilisant un plugin qui fait la même chose (il utilise les mêmes fonctions)

C'est le plugin lisser polylignes ; il n'a pas été fait pour ça, mais ça marche quand même.
http://www.atelier-des-fougeres.fr/Cambam/Aide/Plugins/PolylineSmooth_FR.html



++
David

Bonsoir David,
OK, je pensais que pour une diagonale CB créait un gcode d'escalier, et au vu de ce que tu me dis il n'en est rien.

Effectivement mon programme traite les infos successivement, d'abord le X, ensuite le Y et enfin le Z.
Si on prend ton code exemple (je suis maintenant en 32bits donc sur 4 octets mais çà n'a pas d'importance ici)
X0000 Y0020
X0020 Y0000

première ligne (on part du principe qu'on est en POM=0):
il va d'abord positionner le stylo (outil) à X0,Y0 et ensuite en traitant le Y partir sur X0,Y20, donc tirer un trait vertical
deuxième ligne:
ensuite à partir de là il va s'occuper du X de la deuxième ligne et tirer un train horizontal de X0 à X20,
et finir par s'occuper du Y pour redescendre à Y0, donc de nouveau un train vertical.

Le problème vient que les infos sont traitées séquentiellement et il faudrait plutôt les multiplexer, cad traiter les X et Y ensembles . Facile à faire en C mais hyper chaud en assembleur au vu des divisions obligatoires, l'assembleur n'est pas très à l'aise avec ce type d'opérations.
pfffttt

Je ne connaissais pas ce plugin, je vais le tester mais c'est apparemment une fausse solution, c'est à mon programme de détecter les diagonales et faire ce travail.

............c'est apparemment une fausse solution, c'est à mon programme de détecter les diagonales et faire ce travail.

Oui, tout à fait ; c'est le job de la carte d’interpolation ; dans mon cas l'ESS. Dans le cas d'un pilotage par port //, c'est le "pulsing engine" de Mach3 qui s'en charge (ce que l'on appel à tort le "pilote" du port // mais qui est en fait une carte d'interpolation virtuelle) ..

Pour chaque pas fait sur un moteur, il faudra calculer combien en faire sur l'autre par trigonométrie pour obtenir la pente souhaité, et pour les arcs, il faudra aussi interpoler par la méthode sinus/cosinus (lorsque tu en sera à gérer les arcs )

++
David

Pour les diagonales pas besoin d'utiliser la trigo, j'avais déjà fait çà avec mon robot M4RC3L (http://f6fco.pagesperso-orange.fr/M4RC3L.htm, la page n'est pas à jour sur la finalité du projet). Il suffit de définir quelle est la valeur de X ou Y la plus grande et la diviser en segments avec l'autre valeur, on avance d'un segment pour la première valeur et d'une unité pour l'autre, çà crée une pente à la bonne valeur.
Mais bon, j'avais programmé çà en pseudo C arduino et c'était facile, en assembleur c'est une autre paire de manches , comme je l'ai dit plus haut il n'y a pas d'instructions de division dans ce langage.

Par contre pour les courbes.... , sacré challenge mais je pourrais peut-être m'en sortir avec des tables sinus et cosinus pré-calculées.

Bonjour,
Oui c’est un beau challenge que de réaliser tout ça en assembleur ,les fonctions mathématiques ne sont pas toutes présentes comme dans un langage de haut niveau.

Si j'aurai su ...
j'aurai fait çà en C.
Je vais parcourir le net pour voir s'il existe des routines de division en assembleur PIC, si je me lance dans la création de ce genre de truc çà va me prendre tellement de temps que je vais déconnecter du projet 4L1C3, et tu sais comme moi qu'il n'y a pas pire que d'essayer de remettre le nez dans un vieux programme assembleur . Surtout quand il atteint les 1300 lignes comme c'est le cas avec le mien.

En assembleur la division comme la multiplication n'existent pas. Pour fiare des divisions ou des multiplication il faut faire des décalages de bits à droite ou à gauche selon le cas.
Ces liens pourrons peut-être t'aider ;

http://www.piclist.com/techref/microchip/math/index.ht

http://www.piclist.com/techref/microchip/math/basic.htm

https://openclassrooms.com/forum/sujet/assembleur-la-division-78651

Beaucoup de routines et de sous-routines aident bien aussi...
Bon courage !

Petite remarque complémentaire, en assembleur il vaut mieux éviter de travailler sur des réels et préférer les entiers c'est BEAUCOUP plus simple. Pas besoin de démonter le réel en signe, mantisse et exposant...
On commence par transposer d'entrée les réels en entiers en les multipliant par exemple par 1000 et en les tronquant. Il deviennent ainsi des entiers. Ensuite on ne fait plus que des décalages de bits pour multiplier ou diviser, c'est plus simple et plus rapide.

C'est sur, j'ai fais le choix au départ de ne pas employer de nombres signés pour simplifier la chose, c'est déjà bien assez compliqué comme çà   .
J'ai fureté sur le net et finalement ce n'est pas si compliqué que çà, la division n'est finalement qu'une suite de soustractions. Des fois on se fait une montagne d'un truc

La limitation des décalages c'est que tu ne peux qu'utiliser et obtenir des nombres pairs, ex: 8/2 --> 1000 décalé à droite = 100 (4), si tu décales encore un coup tu as 10 (2).

Il y a bien cette méthode https://sitelec.org/cours/abati/division_binaire.htm
Mais je ne suis pas loin de préférer celle-ci: http://infoindustrielle.free.fr/Logique/Combi_pdf/Cours/Cours_02_04-08.pdf

Division sur 16bits fonctionnelle, du coup je me suis fais ma propre méthode. Ce qu'il y a de passionnant dans la programmation c'est qu'il y a toujours trente six mille façons de résoudre un problème   . Une division n'étant qu'une suite de soustractions, j'ai utilisé ce principe en incrémentant le quotient à chaque soustraction. A la fin il reste le reste trop petit pour y soustraire le diviseur.

Je suis maintenant armé pour m'attaquer aux trajectoires des pentes.
Voici l'ordinogramme pour Momoclic:

Bonsoir tout le monde,

Ca y est, 4L1C3 dessine ses pentes
Merci la routine de division.
Je suis d'abord parti de l'équation de droite y=ax+b (vous vous rappelez à l'école ?), mais j'ai vite laissé tomber car pour certaines pentes je me retrouvais avec des valeurs de b négatives, pas pratique à gérer en assembleur.
J'ai finalement utilisé le calcul de la tangente de l'angle formé par la pente pour calculer la position du Y pour chaque valeur de X.
Je peux développer si çà intéresse certains.
Déjà à partir de là le soft est capable de tracer des PCB avec lignes horizontales, verticales et pentes, on utilise rarement de courbes dans le dessin des circuits imprimés.

Je m'intéresse maintenant à la gestion des courbes mais ce n'est plus la même affaire, hormis le fait que çà dérange la belle ordonnance de mon gcode spécial bien formaté je ne comprend pas du tout comment fonctionnent les instructions gcode I et J avec Cb. Par exemple pas de souci avec le gcode expliqué dans cette page http://www.helmancnc.com/how-to-mill-full-circle-cnc-program-example-code/ ou il est expliqué que i est le centre X des données d'un arc et j le centre Y des données d'un arc.
Mais CB donne trop d'infos dont je ne sais que faire, en plus çà ne correspond pas, par exemple pour un cercle de diam 20 situé à X20 et Y20 j'obtiens çà et çà me cause pas.

Salut,

cool pour les diagonales ...

J'ai finalement utilisé le calcul de la tangente de l'angle formé par la pente pour calculer la position du Y pour chaque valeur de X.

Ne faudrait il pas choisir l'axe de référence en fonction de sa longueur ? par exemple si tu calcul Y en fonction de X et que X est bien plus petit que Y, tu n'exploitera pas tous les pas possibles du Y ; ça ne risque pas de faire des "escaliers" ?

Pour les cercles, c'est compliqué, car il y a 5 modes d'arcs possibles sur CB (à régler dans le PP ou dans le dossier Usinage) ... et en plus il te manque des infos avec ce PP, car le sens de courbure est donné par le G (G2 ou G3) et les nombres décimaux sont indispensables.

voila le Gcode normal (PP default) . un cercle est crée par 3 arcs sur CB en mode C-P1

G0 X30.0 Y20.0
G0 Z1.0
G1 F600.0 Z0.0
G3 F800.0 X15.0 Y28.6603 I-10.0 J0.0
G3 Y11.3397 I5.0 J-8.6603
G3 X30.0 Y20.0 I5.0 J8.6603
G0 Z3.0

Absolu: I & J sont les coordonnées absolues du centre de l'arc

Incremental (C-P1): I & J sont les coordonnées du centre de l'arc, relatives au premier point de l'arc. C'est le mode incrémental typique.

Incremental (P1-C): I & J sont les coordonnées du premier point de l'arc relatives au centre de l'arc.

Incremental (C-P2): I & J sont les coordonnées du centre de l'arc, relatives au second point de l'arc.

Incremental (P2-C)I: & J sont les coordonnées du second point de l'arc relatives au centre de l'arc.

Un exemple en C-P1 correspondant au GCode plus haut.



Si on remplace le G3 par un G2, sans toucher au reste, alors on obtiens l'arc complémentaire (donc le 2/3ier de cercle en blanc au lieu du 1/3 en jaune)

M'est avis que ça va pas mal compliquer les choses !! .... heureusement que tu peux utiliser l'option du PP qui convertis les G2/G3 en G1 ... mais la aussi je pense qu'il faudra les décimales, sinon je doute que le résultat soit un cercle  

++
David

Hello,
Tu fais Help ! Help ! et paf, tu as la réponse à 3h45 du matin Un vrai livre ce David.

David a écrit:Ne faudrait il pas choisir l'axe de référence en fonction de sa longueur ? par exemple si tu calcul Y en fonction de X et que X est bien plus petit que Y, tu n'exploitera pas tous les pas possibles du Y ; ça ne risque pas de faire des "escaliers" ?

Pour les pentes c'est tout frais, çà date d'hier après-midi et je suis en pleines simulations, je vais tester ce que tu dis et çà bugue je ferai une condition pour déterminer l'axe le plus long. Le calcul de la tangente c'est tan()=deltaY/deltaX mais après tout c'est moi qui nomme les segments comme je veux, je suis Dieu dans mon programme  

Pour les courbes, c'est pas très simple en effet, même un peu décourageant je dirais... Je vais déjà digérer ce que tu viens d'expliquer et voir si c'est adaptable à mon soft, mais çà fait tout refondre car comme tu sais l'UART m'envoie des trains bien formatés XYZ qui sont mis dans des variables 32bits. Il faudrait déjà modifier çà mais le pbm c'est que les I et J semblent arriver un peu en vrac et vont foutre la zone dans la belle ordonnance de mes données. C'est même le plus gros problème, à savoir çà au début j'aurai construis le programme d'une autre façon, en faisant la reconnaissance de la première lettre du train pour reconnaître l'axe par exemple. Trop tard maintenant, je suis à environ 1600 lignes de code, je ne recommence pas.

Gérer un cercle en assembleur n'est pas insurmontable mais l'histoire des 3 arcs complique bien la chose.
Le sens de la courbure n'est pas critique je choisis toujours le même sens et basta, quitte à faire des déplacements rapides pour se positionner au début.

D'un autre coté le soft est déjà capable de tracer des PCB (il y a rarement des courbes dans un tracé), çà commence à faire pas mal de temps que je planche dessus et j'ai pas mal de nouveaux projets en tête qui m'appellent en hurlant, alors si au bout d'un moment je vois que je ne m'en sors pas avec les courbes je finaliserai tout çà et la machine sera quand même opérationnelle   . Mais je vais quand même plancher encore un peu.