Discussion :

[Jay M]

La seule grosse différence entre le code de test que j'ai envoyé et le gros programme c'est que le gros programme teste beaucoup plus de chose et effectue l'animation pendant qu'on demande au moteur de faire des pas donc appelle mois souvent la fonction qui fait se déplacer le moteur (et encore moins quand plusieurs moteurs se mettent en route en même temps)

je vais regarder d'un peu plus près, c'est sûr que sans le matériel sous la main c'est pas simple de tester tout cela. J'utilise wokwi pour simuler mais ça reste une simulation mais ça avait l'air de fonctionner...

https://wokwi.com/projects/455127249161077761

[Jay M]

juste pour voir si on perd trop de temps dans les animations pouvez vous dans le fichier Piste.cpp mettre en commentaire la ligne qui appelle les animations

il y a la ligne (364 si je ne me trompe pas) qui dit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
      animation(); // animer les bandes leds des bordures en cas de marquage de points

on rajoute juste // devant pour qu'elle soit commentée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
//      animation(); // animer les bandes leds des bordures en cas de marquage de points

si vous faites cela est-ce que vous voyez un changement notable de comportement ?

[jojodu71]

si vous faites cela est-ce que vous voyez un changement notable de comportement ?

Ça fonctionne nickel à l’aller. Au retour, toujours le problème d’augmentation de la vitesse des chariots en déplacement dès qu’il y en a qui sont sur la ligne d’arrivée. De plus, les moteurs ayant du chemin à parcourir s’arrête et se mettent à grogner
C’est beaucoup mieux,

[Jay M]

Ça fonctionne nickel à l’aller.

L'animation des bandeaux est sans doute trop couteuse en temps donc...

Au retour, toujours le problème d’augmentation de la vitesse des chariots en déplacement dès qu’il y en a qui sont sur la ligne d’arrivée.

De plus, les moteurs ayant du chemin à parcourir s’arrête et se mettent à grogner

J'ai mis une vitesse x2 sur le chemin du retour je pense que c'est beaucoup trop.
ligne 177 enlevez le * 2 du

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
      moteur.setSpeed(VITESSE_MAX * 2);

et je pense qu'il faut mettre VITESSE_MAX à 500 au max.

Si les 4 sont en fonctionnement pour le retour, il faut que le code passe 2000 fois par seconde dans la fonction runSpeedToPosition(). ça laisse à peine 500µs pour faire la loop, tester les fins de course etc.

---

Votre code initial était moins asynchrone que le mien - avec le risque de rater des événements car vous étiez bloqué dans des boucles.

Je vais regarder demain pour essayer de nettoyer plus le code en prenant certains raccourcis pour les fonctions critiques.


Pour les animations, est-ce que ce serait compliqué pour vous de ramener la commande des 2 bandeaux sur la même broche plutôt que d'utiliser 2 broches séparées ? (en gros lors de l'animation de la bordure, on fait la même chose des 2 côtés mais avec 2 pins on demande deux fois le travail à l'arduino)

[jojodu71]

J’ai fait des essais en jouant sur la vitesse, max. En la mettant à 500 les déplacements aller sont trop justes, je l’ai donc laissé à 2000 et j’ai ajusté la vitesse de retour en mettant le coefficient à 1,2. Le fonctionnement est parfait, tout fonctionne bien.
Est-il possible par contre de diminuer la longueur de déplacement au départ de cycle ? Sur quel paramètre faut-il jouer ?
Pour ce qui est de câbler les deux rubans LED sur une seule sortie, il n’y aurait pas de problème, à condition qu’une sortie arrive à supporter 2 × 28 LED. Si c’est le cas je pourrais vous faire ça demain en utilisant les sorties du bandeau gauche à savoir 35 37, 39 et 41.
Merci pour tout

[Jay M]

C’est OK pour le moment mais vous n’avez pas les animations… on va gagner un peu si vous joignez les 2 bandeaux sur une broche mais on va quand même y passer pas mal de temps…

Je vais regarder si on peut faire plus serré et gagner en performance.

Pour le déplacement au début du cycle - vous voulez dire quoi exactement ?

[jojodu71]

Pour le déplacement au début du cycle - vous voulez dire quoi exactement ?

Lorsque j’appuie sur le bouton départ, tous les moteurs se déplacent d’une valeur afin de libérer les butées de départ. C’est cette valeur que je voudrais diminuer ( voir supprimer) pas la peine qu’ils avancent de un ou deux pas.
Concernant les rubans LED, vu qu’ils arrivent au même endroit, je vais les brancher en parallèle, j’espère que ça fonctionnera au niveau de l’animation.
Merci

[Jay M]

Lorsque j’appuie sur le bouton départ, tous les moteurs se déplacent d’une valeur afin de libérer les butées de départ. C’est cette valeur que je voudrais diminuer ( voir supprimer) pas la peine qu’ils avancent de un ou deux pas.

Il n’y a aucun code pour cela - ce n’est pas dans l’algorithme. Si vous mettez DEBUG à 1 dans le fichier Globals.h et que vous ouvrez le moniteur série à 115200 bauds, que voyez vous dans la console ? (La seule façon d’avancer c’est si un capteur laser dit qu’il a été déclenché )

[jojodu71]

Il n’y a aucun code pour cela - ce n’est pas dans l’algorithme. Si vous mettez DEBUG à 1 dans le fichier Globals.h et que vous ouvrez le moniteur série à 115200 bauds, que voyez vous dans la console ? (La seule façon d’avancer c’est si un capteur laser dit qu’il a été déclenché )

C’est un phénomène que j’ai depuis le début même avec l’ancien code. Chat GPT me l’avait limité à quelques millimètres juste pour relâcher les butées de départ. Après dans votre code, vous aviez réussi à supprimer le phénomène pour tout les cycles sauf le premier à la mise sous tension.

[Jay M]

Je n'ai pas de code pour relâcher le FdC de départ si on essaye d'avancer vers l'arrivée, ce FdC n'est pas testé, juste celui d'arrivée donc le fait qu'il soit appuyé ou pas ne change rien.
(je suppose que le FdC n'est pas câblé pour influencer le driver ?)

Dans ce cas je pense qu'il faudra rajouter les résistances de pulldown.

Pour améliorer aussi le fonctionnement et compenser les besoins d'animation il faudra peut-être passer en pas complets plutôt qu'en demi pas, ça diviserait par deux la pressions sur la boucle moteur.

Vous avez dit que les petits interrupteurs de configuration sont difficilement accessibles dans les drivers donc je sais que ce n'est pas idéal. Y-avait il une raison pour laquelle vous étiez passé en demi pas ?

[jojodu71]

Je n'ai pas de code pour relâcher le FdC de départ si on essaye d'avancer vers l'arrivée, ce FdC n'est pas testé, juste celui d'arrivée donc le fait qu'il soit appuyé ou pas ne change rien.
(je suppose que le FdC n'est pas câblé pour influencer le driver ?)

Non, ils sont câblés directement sur les entrées arduino. Après je ne souhaite pas que les moteurs bougent à la mise sous tension, mais c’est comme ça que ChatGPT avait conçu le code et comme je suis incapable de faire mieux, je m’en contentais 😉

Vous avez dit que les petits interrupteurs de configuration sont difficilement accessibles dans les drivers donc je sais que ce n'est pas idéal. Y-avait il une raison pour laquelle vous étiez passé en demi pas ?

Avec l’ancien code, les déplacements étaient plus fluides en demi pas qu’en pas entier, c’est pour cela que j’avais opté pour ces réglages. Après comme je vous l’ai dit, si il faut je démonte tout ce week-end et je le refais. J’en profiterai pour rajouter les résistances. Par contre, j’espère que je ne devrais pas faire machine arrière ensuite car j’ai peur que le timing soit juste avant la kermesse. Merci

[jojodu71]

J’ai commencé à démonter les drivers et je me suis rendu compte en fait que tous les communs des drivers étaient reliés ensemble (commun de l’alim 24v). Mais il n’était pas relié au commun de l’Arduino qui lui est sur l’alim 5 V , est-ce normal ? faut-il bien les relier ensemble même si c’est sur deux alimentations différentes ? Concernant le réglage des drivers, si j’ai bien compris, il faut que je les mets à 4 microsteps, c’est-à-dire, on off off, on, on off (1 à 6)?
Merci d’avance

[Jay M]

J’ai commencé à démonter les drivers et je me suis rendu compte en fait que tous les communs des drivers étaient reliés ensemble (commun de l’alim 24v). Mais il n’était pas relié au commun de l’Arduino qui lui est sur l’alim 5 V , est-ce normal ? faut-il bien les relier ensemble même si c’est sur deux alimentations différentes ? Concernant le réglage des drivers, si j’ai bien compris, il faut que je les mets à 4 microsteps, c’est-à-dire, on off off, on, on off (1 à 6)?
Merci d’avance

ah ça pourrait expliquer bien des choses... Non on ne mélange pas le GND de la partie puissance (qui est potentiellement pollué par le moteur) au GND des signaux logiques qui vont dans des optocoupleurs sur le driver pour justement avoir une bonne isolation.

Le bon montage pour le TB6600 :

- vous emmenez la puissance sur VCC et GND
- vous connectez les 4 fils de votre moteur sur A+ A- B+ B- dans le bon ordre

Pour la partie signal, il faut décider si vous êtes en cathode ou anode commune.

Le GND de l’Arduino doit être relié au côté signal du driver, pas à la partie puissance.
Dans le câblage le plus courant dit cathode commune, le GND de l’Arduino est relié ensemble à PUL−, DIR− et ENA−.
Les sorties Arduino STEP, DIR et ENABLE sont reliées respectivement à PUL+, DIR+ et ENA+.
Dans ce mode, un LOW sur ENA+ coupe le courant dans l’opto d’ENABLE et désactive le driver.

---

Concernant le réglage des drivers n'y touchez pas. Comme on a un problème de rapidité avec 4 moteurs à gérer plus les bandeaux qui bloquent tout quand on essaye de changer leur affichage il faudrait passer en pas complet plutôt qu'en demi pas. Ne mettez pas en quart de pas (même si c'est moins bruyant) car on va galérer encore plus au niveau de la vitesse.

---

J'ai préparé une nouvelle version "toute neuve" du code. Pour l'instant il n'y a aucune animation des bandeaux lorsqu'on marque des points, je voudrais valider le reste du fonctionnement d'abord.

Pouvez vous essayer de charger ce code et me dire ce qu'il se passe ?

NewEscargot.zip

[jojodu71]

J’ai chargé votre dernier code, tout fonctionne parfaitement, la vitesse est bonne et fluide, et le moteur ne gronde plus.
En revanche, il y a toujours le décalage au départ lors de la première mise sous tension. Pour les parties suivantes,les escargots ne bougent pas il reste sur la ligne de départ lorsqu'on appuie sur le bouton départ.
J’ai pourtant rajouté les résistances sur l’Enable comme convenu mais cela fait pareil
Pour info, j’ai également regroupé les deux rubans led des pistes sur la même sortie et ça fonctionne.
Sinon, la roue codeuse ne fonctionne pas, mais elle est sans doute pas gérer dans cette version.
À l’allée, la vitesse de 1000 convient parfaitement. Au retour, si il y avait possibilité de la passer à 1500 ou 2000, ça pourrait être bien
Voilà pour le retour sur cette version, mais on est pas loin de la vérité.👍

[jojodu71]

ah ça pourrait expliquer bien des choses... Non on ne mélange pas le GND de la partie puissance (qui est potentiellement pollué par le moteur) au GND des signaux logiques qui vont dans des optocoupleurs sur le driver pour justement avoir une bonne isolation.

Le bon montage pour le TB6600 :

- vous emmenez la puissance sur VCC et GND
- vous connectez les 4 fils de votre moteur sur A+ A- B+ B- dans le bon ordre

Pour la partie signal, il faut décider si vous êtes en cathode ou anode commune.

Le GND de l’Arduino doit être relié au côté signal du driver, pas à la partie puissance.
Dans le câblage le plus courant dit cathode commune, le GND de l’Arduino est relié ensemble à PUL−, DIR− et ENA−.
Les sorties Arduino STEP, DIR et ENABLE sont reliées respectivement à PUL+, DIR+ et ENA+.
Dans ce mode, un LOW sur ENA+ coupe le courant dans l’opto d’ENABLE et désactive le driver.

Ok donc c’est bon mon câblage était correct

[Jay M]

Ok donc c’est bon mon câblage était correct

Oui sauf si vous avez fait comme sur la photo - la résistance de pulldown doit aller sur le GND du signal pas du moteur.

Pour gagner en vitesse la roue codeuse n’est traitée que avant le démarrage du jeu - une fois le jeu commencé je ne la lis plus.

Ok pour les rubans leds je vais modifier le code en conséquence

[Jay M]

Pour info, j’ai également regroupé les deux rubans led des pistes sur la même sortie et ça fonctionne.

Vous avez conservé quelles broches ? Vous aviez dit

je pourrais vous faire ça demain en utilisant les sorties du bandeau gauche à savoir 35 37, 39 et 41.

ce sont les broches des fin de course ça. Les LEDs sont entre 22 et 33. Je vais supposer que vous avez bien conservé le câblage à gauche donc les pins 23,26,29 et 32 ont été libérées et recablées sur 22,25,28,31.

---

Voici une version avec les animations . J'ai limité à un seul passage de flèches pour limiter l'impact sur le temps dispo pour le moteur.

NewEscargotV1.1.zip

- J'ai augmenté la vitesse max pour le retour (3x la vitesse) mais je ne sais pas si l'arduino Mega sera capable de faire cela pour les 4 moteurs à la fois
- La roue codeuse est prise en compte mais doit être réglée avant la partie (ou interrompre en appuyant le bon départ quand il n’y a pas de mouvement, régler, puis relancer) directement pour le nombre de pas lorsqu'on marque des points. J'ai simplifié la formule c'est maintenant le nombre de pas de base x la (roue codeuse + 1). Dans le fichier Globals.h vous avez cette ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

const long nbPasPourUnPoint = -400;       // négatif pour aller vers l'arrivée (1 tour en demi pas)

donc si la roue codeuse dit 5 par exemple, pour une balle passant devant le laser des trous rouge (3 points) on aura comme distance parcourue

400 pas x 3 points x (5 + 1) = 7200 pas ==> le moteur fait 18 tours

[jojodu71]

Merci beaucoup pour ce nouveau code. Après avoir recablé les résistances correctement, c’est-à-dire sur le commun de l’Arduino, j’ai chargé ce nouveau code et voici les premiers résultats :
- Les moteurs se décalent toujours et l’animation de déplacement se lance lorsque qu’on appuie sur le bouton départ à la première mise en route.
Pour les parties suivantes, les moteurs ne bougent plus.
- Les moteurs grognent de nouveau tant que l’animation de déplacement est en cours et après le déplacement est fluide et silencieux.
- La roue codeuse impacte bien les déplacements des moteurs, mais il y a trop de différence que l’on soit sur le deux ou sur le quatre par exemple.
En position quatre, le déplacement total de l’Escargot sur la piste se fait en 3 × 3 points et si je mets la roue codeuse sur neuf, le déplacement total sur la piste, se faire en 1x3points, Ce qui est beaucoup trop rapide.

L’animation a l’air de poser problème sur le fonctionnement . Et si on gardait que le défilement des LED et qu’on enlevait le défilement de la flèche est-ce que ça résoudrait le problème sinon on supprime cette animation. Dommage apportait un vrai cachet à ce jeu mais si c’est pas possible on va pas se prendre la tête.
J’ai diminué le coefficient de la vitesse max pour le retour à deux car trois c’était trop important.
Voilà pour le retour de cet essai. Encore merci et à bientôt

[Jay M]

- Les moteurs se décalent toujours et l’animation de déplacement se lance lorsque qu’on appuie sur le bouton départ à la première mise en route.
Pour les parties suivantes, les moteurs ne bougent plus.

Pas cool... ça ne vient pas du code qui met bien "en urgence" les pins enable en sortie et à LOW, c'est la première chose qui est faite dans le setup.
A mon avis ça vient du driver. Je pensais que la résistance de pulldown empêcherait cela, manifestement ça ne suffit pas, peut-être j'ai été trop agressif en disant 10kΩ et 1kΩ aurait été plus judicieux... peut-être que Step flotte aussi et crée un front avant que enable se stabilise...

- Les moteurs grognent de nouveau tant que l’animation de déplacement est en cours et après le déplacement est fluide et silencieux.
L’animation a l’air de poser problème sur le fonctionnement . Et si on gardait que le défilement des LED et qu’on enlevait le défilement de la flèche est-ce que ça résoudrait le problème sinon on supprime cette animation. Dommage apportait un vrai cachet à ce jeu mais si c’est pas possible on va pas se prendre la tête.

J'ai optimisé pourtant le code d'affichage de bitmap en inversant les bits et les octets dans le tableau pour éviter les calculs d'inverse sur x et y que vous aviez et j'ai limité le nombre d'affichages et on a diminué par 2 le nombre de leds à gérer sur les côtés mais clairement le temps mis pour gérer les leds est trop important. On ne peut pas faire grand chose de plus car le type de led que vous utilisez n'est pas super rapide et nécessite un timing ultra précis. Pour ce faire, lors de l'affichage du bandeau (quand on appelle show) la bibliothèque suspend les interruptions et est complètement bloquante, la durée dépend du nombre de leds. On a 28 leds sur le côté à gérer et 64 dans l'afficheur. On a 30 µs par LED plus un temps fixe de 50 µs à la fin de la transmission.

Donc chaque affichage des bandeaux prend (28 + 64) x 30 µs + 2 x 50 µs ~3ms
Si on veut faire 1000 pas par seconde, il faut appeler run() toutes les 1 ms
et si plusieurs moteurs/animations tournent c'est encore pire

=> à chaque fois qu'on demande l'animation on retarde l'appel à run() et donc on a un fonctionnement saccadé qui est ce que vous constatez.

On pourrait modifier le code pour que lorsqu'on marque des points on ait l'animation graphique puis on laisse par exemple la flèche affichée sur l'écran et le bandeaux en blanc, et une fois l'animation finie on démarre le moteur. à la fin du déplacement on remet l'affichage de la piste par défaut avec sa bonne couleur.
Inconvénient - ça bloque pendant un petit moment l'avancée du jouer.
autre option, on ne fiat qu'un seul affichage en blanc et avec la flèche, ça ne bloque pas longtemps

Qu'en pensez vous ?

- La roue codeuse impacte bien les déplacements des moteurs, mais il y a trop de différence que l’on soit sur le deux ou sur le quatre par exemple.
En position quatre, le déplacement total de l’Escargot sur la piste se fait en 3 × 3 points et si je mets la roue codeuse sur neuf, le déplacement total sur la piste, se faire en 1x3points, Ce qui est beaucoup trop rapide.

OK - oui la formule est trop agressive.

En gros vous dites que la piste fait 12 000 pas ((9+1) x 3 points x 400 pas)

On pourrait faire un tableau en fonction de la roue codeuse qui définit le nombre de pas à effectuer en fonction du nombre de points marqués

Si vous remplissez les xxx dans ce tableau c'est assez facile ensuite de mettre ça dans le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Roue      Nombre de pas par points
             1 point                   2 points                   3 points
0            xxx pas                  xxx pas                    xxx pas
1            xxx pas                  xxx pas                    xxx pas
2            xxx pas                  xxx pas                    xxx pas
3            xxx pas                  xxx pas                    xxx pas
4            xxx pas                  xxx pas                    xxx pas
5            xxx pas                  xxx pas                    xxx pas
6            xxx pas                  xxx pas                    xxx pas
7            xxx pas                  xxx pas                    xxx pas
8            xxx pas                  xxx pas                    xxx pas
9            xxx pas                  xxx pas                    xxx pas

Dites moi ce que vous pensez de ces idées et je mettrais ça dans le code

[jojodu71]

Pas cool... ça ne vient pas du code qui met bien "en urgence" les pins enable en sortie et à LOW, c'est la première chose qui est faite dans le setup.
A mon avis ça vient du driver. Je pensais que la résistance de pulldown empêcherait cela, manifestement ça ne suffit pas, peut-être j'ai été trop agressif en disant 10kΩ et 1kΩ aurait été plus judicieux... peut-être que Step flotte aussi et crée un front avant que enable se stabilise...



J'ai optimisé pourtant le code d'affichage de bitmap en inversant les bits et les octets dans le tableau pour éviter les calculs d'inverse sur x et y que vous aviez et j'ai limité le nombre d'affichages et on a diminué par 2 le nombre de leds à gérer sur les côtés mais clairement le temps mis pour gérer les leds est trop important. On ne peut pas faire grand chose de plus car le type de led que vous utilisez n'est pas super rapide et nécessite un timing ultra précis. Pour ce faire, lors de l'affichage du bandeau (quand on appelle show) la bibliothèque suspend les interruptions et est complètement bloquante, la durée dépend du nombre de leds. On a 28 leds sur le côté à gérer et 64 dans l'afficheur. On a 30 µs par LED plus un temps fixe de 50 µs à la fin de la transmission.

Donc chaque affichage des bandeaux prend (28 + 64) x 30 µs + 2 x 50 µs ~3ms
Si on veut faire 1000 pas par seconde, il faut appeler run() toutes les 1 ms
et si plusieurs moteurs/animations tournent c'est encore pire

=> à chaque fois qu'on demande l'animation on retarde l'appel à run() et donc on a un fonctionnement saccadé qui est ce que vous constatez.

On pourrait modifier le code pour que lorsqu'on marque des points on ait l'animation graphique puis on laisse par exemple la flèche affichée sur l'écran et le bandeaux en blanc, et une fois l'animation finie on démarre le moteur. à la fin du déplacement on remet l'affichage de la piste par défaut avec sa bonne couleur.
Inconvénient - ça bloque pendant un petit moment l'avancée du jouer.
autre option, on ne fiat qu'un seul affichage en blanc et avec la flèche, ça ne bloque pas longtemps

Qu'en pensez vous ?

Ca pourrait être une bonne option avant de se dire de tout supprimer l'animation; je ne me rend pas trop compte de ce que cela donnerait, si c'est possible de faire un essai, je veux bien essayer. Est ce que ça ne loupera pas de point si le moteur démarre après l'animation, les points suivants peuvent s’engranger alors que le moteur se déplace toujours du point d'avant ? merci

Si vous remplissez les xxx dans ce tableau c'est assez facile ensuite de mettre ça dans le code

si on considère que 1 tour de moteur fait 400 pas soit 4cm sur la piste
la piste mesure 1m25 soit 12500 pas
voici la compilation du tableau avec le code actuel :
Roue Nombre de pas par points
1 point 2 points 3 points
0 400 pas 800 pas 1200 pas
1 800 pas 1600 pas 2400 pas
2 1200 pas 2400 pas 3600 pas
3 1600 pas 3200 pas 4800 pas
4 2000 pas 4000 pas 6000 pas
5 2400 pas 4800 pas 7200 pas
6 2800 pas 5600 pas 8400 pas
7 3200 pas 6400 pas 9600 pas
8 3600 pas 7200 pas 10800 pas
9 4000 pas 8000 pas 12000 pas

on se rend compte que ces valeurs sont trop importantes. je pense qu'en divisant toutes ces valeurs par 2 voir par 3, ce serait mieux et ça laisserait plus de facilité de réglage avec la roue codeuse

En relisant les post précédents, quelqu'un avait soumis l'idée d'utiliser un arduino par piste. je viens de me rendre compte qu'il me restait un Arduino Uno en stock. Est ce que ca pourrait résoudre nos problèmes si on l'utiliser pour gérer les leds et toutes les animations ? quelles modifications cela nécessiterait-il ?
merci d'avance