CNC DVD : Avancement du 18 Février 2013

Autres articles de la série:

 

Résumé

Voici le résumé des choses faites cette semaine:

  • Câblage du moteur numéro 2
  • Câblage des drivers L293
  • Suppression des vibrations
  • Programmation!

C’est la troisième semaine du projet, il commence à devenir assez long et maintenant que l’enthousiasme initial s’est calmé, il me demande de la concentration pour ne pas dévier sur un nouveau projet secondaire (les occasions de distraction ne manquent pas!). J’ai vraiment l’intention de pousser ce projet au maximum malgré les limitations du matériel. L’objectif à atteindre est la gravure d’un objet (papier, bois) avec un laser fixé sur le chariot.

Câblage

Le câblage supplémentaire n’appelle pas de remarque particulière. J’ai utilisé du fil à wrapper pour connecter le CPU aux drivers L293, et les drivers au moteurs par l’intermédiaire de petits câbles au pas de 2,54 mm. Voici quelques images pour vous en donner une idée:

Modules L293
Modules L293 avec une tentative de refroidissement!
Carte de controle
La carte de controle avec ses modules L293
Vue du câblage
Vue du câblage

Suppression des vibrations

Des essais rapides ont révélé que le montage est très bruyant, car les moteurs sont “violents” et produisent un choc à chaque pas! Les petits jeux du coté du rail qui est opposé à la vis d’avancements produisent ces chocs, j’ai résolu le problème en ajoutant un petit morceau de plastique replié en forme de ressort qui fait pression contre le rail. C’est maintenant nettement mieux côté bruit!

Réduction des vibrations
Des patins en plastique pour éviter les vibrations

Programmation

Cette semaine j’ai eu à faire un déplacement à l’étranger impliquant un aller retour en avion, que j’ai pu mettre à profit pour développer.

J’ai fini d’écrire le code de déplacement G1, qui doit piloter les deux moteurs pas à pas à la bonne vitesse pour que les deux axes arrivent à destination en même temps. L’algorithme calcule maintenant le nombre de pas à réaliser sur chaque axe, et en fonction du feedrate, le délai entre pas nécessaire sur chaque axe. Les moteurs sont ensuite déplacés chaque fois que ces délais expirent.

Aujourd’hui j’ai pu tester tout cela et les résultats sont très étranges: tout se passe bien quand je demande le déplacement d’un axe, mais rien ne marche quand je demande le déplacement de deux axes simultanément! Je n’ai pas encore trouvé la cause du bug. Il semble que cela fonctionne mieux quand on demande des vitesses plus lentes, donc je pense avoir un problème avec les délais, la gestion des timers, etc.

J’ai aussi passé un peu de temps à regarder comment est écrit le logiciel grbl, qui fonctionne sur arduino et permet le pilotage d’un grand nombre de machines comme les repraps (Ce logiciel ne me convient pas en tant que tel, car il ne peut piloter que des indexeurs (sorties STEP+DIR), alors que mon PIC pilote directement les bobines des moteurs, et il est conçu pour AVR, et en plus je veux apprendre en réalisant, et non en recopiant.) . J’y ai remarqué des choses intéressantes. Déja il est très bien structuré (il faut que je réorganise mon propre code!) et il fait appel à un “planificateur de mouvements” qui lui permet de faire des changements de vitesse réguliers entre les différents segments à tracer. En résumé c’est un buffer FIFO des déplacements prévus, qui permet de calculer les accélérations et les ralentissements entre les segments à tracer. Cette accélération ne m’intéresse pas pour l’instant, mais ce concept de buffer est quand même bien utile pour séparer totalement les opérations de tracé des autres tâches du programme. Il suffit de PUSHer une ligne, elle est stockée dans le FIFO, et une autre partie du firmware se charge de l’exécution. C’est aussi de cette manière qu’on peut tracer des arcs: ils sont en fait constitués d’un grand nombre de petits mouvements linéaires.

Une autre chose qu’il m’a semblé voir dans ce firmware, mais que je n’ai pas regardé en détails, est l’algorithme de tracé de lignes. De mon coté, je calcule “bêtement” la vitesse des moteurs, mais une lecture rapide m’a suggéré qu’ils utilisent l’algorithme de tracé de lignes de Bresenham. Cet algorithme est capable de calculer combien de “pas horizontaux” sont nécessaires pour chaque pas vertical. D’ailleurs la lecture de la page wikipédia vous montrera que cet algo a été utilisé originellement pour piloter un traceur! Il me suffira de faire un pas “X” tous les N pas “Y”, et l’algo me donnera N! Selon l’angle de la ligne, bien entendu, ce sera N pas “X” pour chaque pas “Y”. Un autre défi sera de définir correctement la vitesse de déplacement!

Tracé de ligne selon Bresenham
Tracé de ligne selon Bresenham (Wikipédia)

Donc encore pas mal de travail!

A venir

Dans la semaine qui vient, je vais reprendre le logiciel pour l’améliorer. Je compte implémenter le buffer de mouvements et séparer le code en unités logiques plus claires.

Autres articles de la série: