Driver de puissance maison pour moteur pas à pas.

[freedom2000]

Bravo à vous 2!

Dites moi, qu'utilisez vous pour le calcul des distances, la norme 2 (distance) ou la norme infinie (max de X et Y)?

Je n'ai pas tout compris, le 2-opt est-il mieux ou pas en temps?

J'ai codé un algo glouton après l'2-opt qui permet encore de gagner 10% du parcours. Le principe regarder si chaque points ne seraient pas "mieux" dans un autre arc (évite les détours pour un points).

Je trouve curieux le grand déplacement au dessus du PCB. Vous avez forcé le premer point? Sinon je pense que votre algo le 2-opt ne prends pas en compte la distance [premier point; dernier point]. il y a peut être des optimisation à faire de ce coté.

En tout cas bon boulot bravo à vous 2.

@Freedom : peux-tu me donner le fichier Gcode pour que je teste si mon algo se débrouille bien avec 600 perçages (il se débrouille bien avec 271 de la breakout board de "PetitPas")? Merci d'avance.

Xavier

Salut Xavier !

La "grande traversée" me trouble aussi --> il doit rester un point en bout de fichier qui n'est pas pris dans l'optimisation !

La distance la meilleure est celle que tu appelles "norme infinie"
Elle donne de meilleurs résultats que la "vraie distance"

Le 2Opt est pour l'instant le meilleur algo parmi le peu qu'on a testé !

Bye
JP Voir la pièce jointe 4axis_PCB_trous_cuivre.zip le Gcode de µstep 4 axis

 

[horsot]

Bonsoir,

Désolé de la pollution, mais je vais parler d'un programme (dont je suis l'auteur) qui ressemble beaucoup à celui de Freedom et Guol. Il génère du gcode à partir d'un fichier de perçage drl de kicad.

Aujourd'hui, je lui ai fait une petite interface graphique. Mais surtout je l'ai adapté pour qu'il puisse être directement appelé depuis EMC2 pour générer du Gcode (depuis un .drl) chargé automatiquement dans ce dernier. Ça réduit beaucoup les manipulations!

Le .drl est le fichier de perçage généré par kicad

C'est une version hautement beta mais marche très bien avec "PetitPas" et sa "BreakoutBoard". Elle ne prend pas encore en compte le changement de diamètre de perçage, ça ne serait tarder.

J'ai pas mal d'améliorations en tête Je vais faire en sorte pour que EMC2 puisse directement ouvrir un fichier drl. J'ai dans l'idée (entre autre) d'implémenter une "transformation d'ajustement" (rotation, taille,...) pour garantir la superposition des coordonnées du .dlr et le PCB réel sur la machine. Il faudra relever quelques points (2 à 4) sur le PCB en coordonnées machine pour faire cet ajustement.

Il est écris en python (multiplateforme) et peut aussi être lancé tout seul (sans EMC2) pour générer un fichier gcode pour un autre programme.

Voici une capture résumant les 3 opérations :

Xavier

 

[horsot]

Merci pour le fichier,

Une petit détail sur le Gcode, à ta place j'utiliserai le G81 fait pour les perçages c'est plus simple que le G0 et c'est fait pour.

Je viens de le tester avec l'algo, ça marche aussi du premier coup (enfin une fois fait l'opération inverse (gcode => drl)

Je vois plus de failles de mon algo (ilot de 4 perçages au centre ). Je vais le corriger.

une petite capture :

 

[freedom2000]

Sympa tout ça Xavier

Il est super sympa ton parcours (mieux que le mien ... )
C'est le "glouton" qui arrange tout ?

Tu fais quoi au juste :
- un tri sur un axe
- un 2opt (jusqu'à épuisement des permutations)
- un glouton

Pour le Gcode, il faut aussi qu'on change la "pause" de changement d'outil par un vrai changement d'outil (ça ne fait pas classe une pause de 3s ) !

A+
JP

 

[guol64]

Ben dites moi, on ne peut pas vous laisser seul un week-end , bientôt le plus long ça va être de changer les forêts .

Super ton programme horsot, en fait on fait a peu près la même chose.

Je mets l'exe dès que possible.

 

[horsot]

Merci,

Pour la mesure de distance, j'utilise la norme infinie "pondérée" en fait je prends distance = max(deltaX,deltaY)+0,01*min(deltaX,deltaY). Ça évite d'aller trop loin en diagonale et de croiser les chemins inutilement.

Pour l'optimisation, il y a trois algos :
- Le plus proche voisin, va d'une ville à son plus proche voisin non présent dans le chemin. Ça fait du bon boulot mais oublie des points au fur et à mesure et génère de très longs trajets sur le fin du parcours.

- L'algo 2-opt. J'ai remarqué que l'algo 2-opt marchait mieux avec une "fenêtre" qu'avec 1 villes "quasi fixe" (premier "for") et une ville "flottantes" (for imbriqué). En gros je déplace la fenêtre (de X points consécutifs) dans le parcours j'inverse l'ordre des points dedans je teste si c'est mieux... etc...

-L'algo "gouton" (capture des points proches), il parcoure les villes du chemin et regarde pour chacune d'entre elles si le parcours ne serait pas plus court si elle appartenait à un autre arc (2 villes du parcours). Pour l'instant l'algo ne le fait que pour une ville mais je pense l'implémenter pour un groupement de ville consécutive du parcours mais ça risque de prendre beaucoup de temps de calcul.

Tous ces algos sont décrits sur ce site :
http://www.crdp.ac-grenoble.fr/imel/jlj/pvc/2opt.htm

En fait au départ je voulais juste faire mumuse avec des algo du voyageur de commerce, j'ai pris le PCB de "Petitpas" comme exemple. Puis je me suis dit "pourquoi ne pas générer le gcode qui va avec" et voila je me retrouve avec un soft!

Xavier

 

[freedom2000]

Xavier,

J'ai fait comme toi... pris au jeu

Je viens de rajouter le "inter-Opt" tel que décrit dans la coupe de France de robotique...

J'ai donc dans l'ordre :
- un simple tri en abscisse "arrondie à 1mm"
- un 2 Opt systématique dont la première passe est sur les parcours longs (je ne retourne que des parcours dont le gain est > 0,6 * largeur du pcb)
- un inter Opt quand le 2Opt ne sort plus rien
- et on boucle sur le 2 Opt + interOpt jusqu'à épuisement !

L'origine est astucieusement dans l'optimisation mais est fixée

J'ai donc maintenant un parcours qui ressemble au tien et qui n'a plus de "grande traversée"

Résultat :
encore un high score d'usinage de 6min 21s
pour une distance de parcours de 2334 mm

JP

 

[horsot]

Bravo c'est du joli!

Ok je pense avoir compris le principe.

Pour la distance parcourue que tu indiques elle est en norme 2 ou infinie?

Xavier

 

[freedom2000]

Bravo c'est du joli!

Ok je pense avoir compris le principe.

Pour la distance parcourue que tu indiques elle est en norme 2 ou infinie?

Xavier

infinie (en partant de 0,0 positionné sur la coin supérieur droit du pcb)

Pour que ça soit vraiment nickel il me reste deux ou trois croisements de chemin (toujours sur 3 points adjacents) qui ne font pas beau mais qui ne rallongent pas (du coup je laisse comme ça !)

Ah, j'oubliais : Guol ayant détecté les différents diam de mèche, j'ai trié chaque chemin indépendamment... Mais sur les essais que j'ai montrés j'ai désactivé l'option pour qu'il y ait plus de points !

et j'oubliais aussi : Merci Xavier pour nous avoir montré l'existence de ces algo

JP

 

[Zorg]

Messieurs, je vous tire mon chapeau.

félicitations.

 

[freedom2000]

Messieurs, je vous tire mon chapeau.

félicitations.

Merci Zorg,

Mais ... félicitations surtout à ceux qui ont pondu ces algo qui sont finalement redoutablement efficaces

Comme quoi notre algo en zig zag n'était pas le meilleur

JP

 

[horsot]

Merci des encouragements

@Freedom :
J'ai codé la prise en compte de l'origine pièce, j'arrive à un résultat d'environ 10mm plus long que le tien, l'élève n'a pas (encore ) dépassé le maitre, je m'incline!

J'ai réfléchi à la première phase de ton algo. Je pense que de privilégier un sens (trie en X) va très bien pour les circuits comme ustep qui ont bcp de points alignés dans le sens des Y et je pense que ça peut être pénalisant pour les circuits dont les points sont plutôt alignés en X ou de manière disparate. La transformé de hough, dont tu as parlé plus haut, pourrait être utile pour repérer le sens du circuit (reconnaissance de droites) et les trier perpendiculairement à ce sens (angle) privilégié.

Xavier

 

[freedom2000]

10 mm --> surtout ne change rien

Ton parcours est plus "humain" (pour ne pas dire "rigoureux" ou plus "joli") que le mien ... qui a un côté aléatoire assez poétique.

Il faut que je refasse un essai avec la "distance euclidienne classique" pour voir si mes CI seront parcourus linéairement comme toi ou resteront en zigzag (cf connecteur DB25 du port//)

JP

 

[horsot]

10 mm --> surtout ne change rien

Ton parcours est plus "humain" (pour ne pas dire "rigoureux" ou plus "joli") que le mien ... qui a un côté aléatoire assez poétique.

Il faut que je refasse un essai avec la "distance euclidienne classique" pour voir si mes CI seront parcourus linéairement comme toi ou resteront en zigzag (cf connecteur DB25 du port//)

JP

Merci mais c'est quand même moins performant!
J'utilise la norme infini "pondérée" (voir quelques post plus haut) pour l'optimisation du trajet ce qui dissuade l'algo de croiser les chemins lorsque 2 distances en norme infinies classiques sont identiques. Par contre pour le calcul de la distance totale j'utilise la norme infinie classique.

Je regarde en ce moment les transformations projectives du plan pour palier à des défauts de désalignement Gcode/Réalité (rotations, homothéties, projective...). C'est une simple matrice 3*3 pour du 2D et il y a bien au pire 8 coefficients à trouver (1 des coeff est lié par un relation externe) donc 4 points de références devraient suffire (les 4 extrêmes pour une meilleure définition).

Xavier

 

[freedom2000]

Je regarde en ce moment les transformations projectives du plan pour palier à des défauts de désalignement Gcode/Réalité (rotations, homothéties, projective...). C'est une simple matrice 3*3 pour du 2D et il y a bien au pire 8 coefficients à trouver (1 des coeff est lié par un relation externe) donc 4 points de références devraient suffire (les 4 extrêmes pour une meilleure définition).

Xavier

Moi j'ai fait avec un simple facteur de zoom sur chaque axe (et encore la même valeur sur les deux axes peut suffir !)

JP

 

[freedom2000]

Pour le fun j'ai testé l'optimisation avec une distance euclidienne.

Le parcours est plus joli à l'œil ; mais il est aussi moins performant en usinage de + 9s

Guol avait donc raison, la distance "infinie" est celle qui minimise bien les temps de déplacement.

JP

optimisation avec distance Euclidienne

 

[freedom2000]

Merci mais c'est quand même moins performant!
J'utilise la norme infini "pondérée" (voir quelques post plus haut) pour l'optimisation du trajet ce qui dissuade l'algo de croiser les chemins lorsque 2 distances en norme infinies classiques sont identiques. Par contre pour le calcul de la distance totale j'utilise la norme infinie classique.

Xavier

J'ai codé ta distance "pondérée" --> effectivement ça désoptimise un micro poil le temps de parcours tout en "décroisant" quelques chemins.

Donc ça confirme bien la théorie de Guol qui dit qu'il est aussi efficace de se déplacer sur la diagonale d'un carré que de parcourir un côté (en temps de déplacement bien sûr !).
Et donc que, bien que moins joli à l'œil, le parcours optimisé en distance "infinie" reste le meilleur

J'ai aussi testé de d'abord trier en y et pas en x pour voir l'influence de l'alignement des pcb.
Tu as raison mon parcours en "tri y" est un poil moins optimisé que celui trié en x... Mais si peu

JP

 

[freedom2000]

Un petit test de robustesse ...

Où est la limite de l'algo ???

J'avoue ne pas l'avoir encore trouvée
J'ai juxtaposé 4 cartes µsteps ce qui logiquement fait plus de 2400 trous à optimiser

J'ai d'abord fait péter la mémoire vive de mon PC ... pour charger l'image à 1000 dpi... J'ai du la redimensionner à 500 dpi

Puis on lance Trutti Frutti et miracle ça sort

Pratique pour faire des grands PCB ou une série de 4 cartes à découper avant usage

Sur mon écran avec firefox, il faut zoomer deux fois en cliquant sur l'image pour la voir "en grand" ... 10 mètres de parcours (70 mètres avant optimisation)

JP

4 cartes µstep 4 axis percées en une fois !

 

[freedom2000]

4824 trous sur 8 cartes juxtaposées, si si je vous jure que je n'ai pas triché

Je pense que je vais arrêter là les tests aux limites ça fait tout de même un pcb de 58 cm x 86 cm

8 cartes µstep 4axis

 

[guol64]

Bon maintenant il va falloir construire la cnc de 12m de long par 3 de large pour tester le perçage de 28.000 trous ...

 

[freedom2000]

Bon maintenant il va falloir construire la cnc de 12m de long par 3 de large pour tester le perçage de 28.000 trous ...

ça va péter avant

Soit par débordement mémoire, soit par temps de calcul trop long (déjà 2 minutes sur un quadri cores)...

Par contre j'adore voir le chemin de perçage, ça ressemble à un parcours fractal

En jaune ce qui est percé en rouge ce qu'il reste à percer : il y a bien une optimisation globale mais ça ressemble à la théorie du hasard...

En plus il faudra changer la mèche avant la fin des 4800 trous

Au total 56 minutes 44 secondes, ce qui ramené à une carte µstep fait 7 minutes 9 secondes de perçage. Le chemin est donc plus long que 8 fois une seule carte (de 8 * 40 secondes ...)

 

[horsot]

Espèce de fou!
Au fait tu peux me dire le temps de calcul uniquement pour l'optimisation d'un ustep?

Aller je prêche pour ma paroisse : décroiser les chemins économise la CNC...


Xavier

 

[freedom2000]

Espèce de fou!
Au fait tu peux me dire le temps de calcul uniquement pour l'optimisation d'un ustep?

Aller je prêche pour ma paroisse : décroiser les chemins économise la CNC...


Xavier

C'est vrai que l'exercice était complètement inutile sauf à vérifier la robustesse du code (c'est un peu mon métier alors on ne se refait pas...)

Pour une simple µstep4axis ça doit être de l'ordre de 4 à 5s ...

JP

 

[horsot]

Bon... comme mon code en python ramait (et c'est rien de le dire!), je me suis appuyé sur le code de la coupe du monde de robotique en C (merci Freedom de me l'avoir donné ) pour implémenter le code en C que j'avais déjà codé en python. Bref, je gagne un bon facteur 100 sur le temps de calcul (pas vraiment mesuré pour le python) et je pense pouvoir encore faire des améliorations (en optimisation de codage et en regardant l'algo de freedom). Fort de ceci j'ai fais marcher mon programme comme un taré Résultat parcours minimum trouvé 2284.4887mm (comment ça j'ai fait ma brute?!).

Le problème de ce genre de jeux c'est qu'il n'y a pas vraiment de limites...

Xavier

Edit : je fais tourner l'algo en écrivant ce post et il vient de trouver 2276.6782 mm

Le parcours (le premier et dernier indice sont la position (0,0) le reste est l'ordre du fichier de perçage de ustep donné par Freedom):

Vous devez être connecté pour voir ce contenu.

la capture :

PS: on peut voir que ce n'est pas l'optimum, la capture de plusieurs points améliorerait encore le chemin... A coder...

 

[enolay]

bonjour
je viens de lire un an de f il d un coup et sans optimization de parcour! en suivant les liens divers (fil de lil....) et je n aies qu un mot bravo!!!
si ca ce ne sont pas des fils constructif je veux bien etre transformé en outils à wrapper!!
et j adore la phylosophie decouverte et autodidacte
pour m amuser je vais faire le test du gcode avec ENC pour voir s il fait mieux que vous!!!

 

[ordinerf]

j'ai hate de connaitre le résultat avec e-NC

 

[horsot]

Bonsoir

pour m amuser je vais faire le test du gcode avec ENC pour voir s il fait mieux que vous!!!

Fais attention à ce que e-NC prenne comme norme le norme infinie (Max(abs(Xa-Xb),abs(Ya-Yb))) et non le norme 2 classique (racine((Xa-Xb)²-(Ya-Yb)²)).

Fais attention aussi que le premier et le dernier point soit bien de coordonnées (0,0)

Un collègue a trouvé 20mm de moins que mon meilleur chemin en partant de celui-ci et en faisant des optimisations locales en force "brute" sur des bouts de chemin allant jusqu'à 30 points de long.

Bon amusement et je suis aussi curieux de savoir le temps de calcul et la norme infinie du parcours minimum.

Xavier

 

[freedom2000]

bonjour

si ca ce ne sont pas des fils constructif je veux bien etre transformé en outils à wrapper!!
et j adore la phylosophie decouverte et autodidacte
pour m amuser je vais faire le test du gcode avec ENC pour voir s il fait mieux que vous!!!

C'est vrai qu'on se marre bien sur ce thread
Dommage que Mdog ne réponde plus ... tout ça a commencé grâce à lui

JP

 

[guol64]

Je passe par là pour m'excuser

En effet voilà maintenant 2 semaines que j'aurais dû poster l'exe, mais en voulant vous faire une petite surprise j'ai perdu un peu de temps et je n'ai pas pû y retoucher depuis pour finaliser.
La surprise : traçage du tracé directement sur l'image des trous, ça c'est fait, et réorganisation du code pour pouvoir rajouter des algorithmes et choisir ceux que l'on veut utiliser.

C'est le problème quand on a plusieurs projets en même temps: il faut choisir car on ne peut pas tout faire, et pour l'instant il me tarde trop de voir ma petite fraiseuse faire des copeaux , mais je vais essayer de trouver une paire d'heures dans la semaine pour finir.

 

[freedom2000]

Je passe par là pour m'excuser

En effet voilà maintenant 2 semaines que j'aurais dû poster l'exe, mais en voulant vous faire une petite surprise j'ai perdu un peu de temps et je n'ai pas pû y retoucher depuis pour finaliser.
La surprise : traçage du tracé directement sur l'image des trous, ça c'est fait, et réorganisation du code pour pouvoir rajouter des algorithmes et choisir ceux que l'on veut utiliser.

Je brûle d'impatience

surtout que ma semaine de ski est finie.... je vais repasser aux choses sérieuses

JP