arrêts en cours d'usinage

[mstrens]

D'après les messages affichés à l'écran, j'aurais tendance à croire que les problèmes viennent de la liaison entre l'ESP32 et le STM32 (caractères déformés).
En effet, je vois des caractères anormaux sur le tft "OOO" et "O+".
Je vois aussi une alarme 3 (Reset while in motion) qui se produit notamment quand GRBL reçoit une commande soft reset pendant qu'il est en mouvement.


A titre de test, tu pourrais essayer de diminuer la vitesse de transmission entre les 2 cartes (baudrate actuel = 115200, pourrait être réduit par exemple à 38400).
Cela implique de modifier les 2 firmwares et de reflasher les 2 micro-ordinateurs.
Dans grbl_controller_esp32.ino, il y a actuellement
Serial2.begin(115200, SERIAL_8N1, SERIAL2_RXPIN, SERIAL2_TXPIN); // initialise le port série vers grbl
Tu peux le changer en par exemple
Serial2.begin(38400, SERIAL_8N1, SERIAL2_RXPIN, SERIAL2_TXPIN); // initialise le port série vers grbl

Il faut alors aussi modifier GRBL. Dans le fichier config.h, il y a actuellement
#define BAUD_RATE 115200
Tu peux le changer en par exemple (même valeur que dans l'autre fichier)
#define BAUD_RATE 38400

[HTheatre]

(Re)bonjour Fran27,

[...]J’avais vu ces tb6600, mais en regardant de près les composants il n’y a pas de réglage à 2,8 pour nos moteurs, c’est soit 2,5 ou 3.[...]

J'ai vu aussi, mais l'intensité de 2,8A données pour nos moteurs est une intensité maximale admissible. On peut donc les faire fonctionner avec une intensité de seulement 2,5A sans problème. Il auront seulement un peu moins de couple, mais avec poulies et courroies fermées de démultiplication, je ne suis pas trop inquiet. Enfin, j'ai de très forts doutes sur le fait que l'on ait bien un courant de 2,8A qui arrivent à nos moteurs, vu la section et la longueur de leurs fils. Par conséquent, en comptant sur l'effet Joule, configurer les steppers en 3,0A ne devrait pas non plus poser de problème.

Enfin, si vraiment cela ne va pas... Comme je devais de toute façon racheter des NEMA23, je prendrai ceux-là et j'utiliserai ceux que j'ai actuellement pour mon autre projet.

@+

[mstrens]

A mon avis, la section du fil sur les moteurs n'a pas d'influence car les TB6600 sont prévus pour générer le courant prévu. Ils adaptent donc le taux de hachage du 24V pour atteindre le courant prévu. La résistance dans les fils (tout comme la résistance interne des moteurs) ne jouent donc pas directement un rôle.

[HTheatre]

A mon avis, la section du fil sur les moteurs n'a pas d'influence car les TB6600 sont prévus pour générer le courant prévu. Ils adaptent donc le taux de hachage du 24V pour atteindre le courant prévu. La résistance dans les fils (tout comme la résistance interne des moteurs) ne jouent donc pas directement un rôle.

Tsss... En fait tu as entièrement raison. Je raconte n'importe quoi. J'ai complètement zappé le fait que le TB6600 envoyait des impulsions aux moteurs.
Et je n'avais pas vu ton premier message. Je vais diminuer la vitesse de transmission entre les 2 cartes, comme tu le suggères.

@+

[HTheatre]

Bonjour mstrens,

A titre de test, tu pourrais essayer de diminuer la vitesse de transmission entre les 2 cartes (baudrate actuel = 115200, pourrait être réduit par exemple à 38400).
Cela implique de modifier les 2 firmwares et de reflasher les 2 micro-ordinateurs.
Dans grbl_controller_esp32.ino, il y a actuellement
Serial2.begin(115200, SERIAL_8N1, SERIAL2_RXPIN, SERIAL2_TXPIN); // initialise le port série vers grbl
Tu peux le changer en par exemple
Serial2.begin(38400, SERIAL_8N1, SERIAL2_RXPIN, SERIAL2_TXPIN); // initialise le port série vers grbl

Il faut alors aussi modifier GRBL. Dans le fichier config.h, il y a actuellement
#define BAUD_RATE 115200
Tu peux le changer en par exemple (même valeur que dans l'autre fichier)
#define BAUD_RATE 38400

Il semble que le fait d'avoir baissé le BAUD RATE fonctionne. Pour l'instant, je n'ai pas eu de nouvelle interruption en cours d'usinage, mais le dernier programme que j'ai lancé n'était pas non plus très long. Je confirmerai après avoir lancé un job plus conséquent.

@+

[Fran27]

Bonjour,
Content pour toi que ça fonctionne, mais effectivement il faut tester plus longuement.
Je vais aussi appliquer ces modifications, car j’ai toujours un doute, même si pour le moment je n’ai pas eu d’arrêt depuis l’installation des nouveaux tb6600.

[HTheatre]

Bonjour Fran27,

Content pour toi que ça fonctionne, mais effectivement il faut tester plus longuement.
Je vais aussi appliquer ces modifications, car j’ai toujours un doute, même si pour le moment je n’ai pas eu d’arrêt depuis l’installation des nouveaux tb6600.

En fait j'avais lancé un usinage de 2h30 mais j'ai pété la fraise en cours de route. Mais la RS-CNC a bien tourné 1 heure sans s'arrêter (j'usqu'à ce que la fraise pète en fait).
Par contre, pour les drivers, je me suis fait avoir. Ils m'ont envoyé des copies chinoises identiques à celles que nous avons tous achetées et non des TB6600 équipés de puces originales TOSHIBA TB6600HG. J'ai tout retourné à l'expéditeur qui doutais quand même. Il a fallu que je lui face des photos de l'intérieur des drivers pour lui montrer que la puce n'y était pas. J'attends son remboursement.

@+

[HTheatre]

Bonsoir,

Fausse joie, le fait d'avoir paramétré une vitesse de transmission (de 38400 baud) pour les communications entre l'ESP-32 et le STM-32 n'a pas résolu mon problème d'arrêts en cours d'usinage, même si le temps qui s'écoule désormais entre 2 arrêts a nettement augmenté. Peut-on diminuer la vitesse de transmission encore en deçà de 38400 baud ou pas ?

Voilà 2 des messages respectifs que j'ai eu suite à 2 des arrêts d'usinage que j'ai eu ce soir.





Après une heure d'usinage sans interruption, j'ai relevé que le moteur des X, et plus encore celui des Y, était bouillant. Sur celui des Y, il faut faire un effort de concentration à la David CARRADINE (Kung Fu) pour pouvoir laisser le doigt posé dessus tellement il est chaud. Est-ce normal ? Cette chauffe ne pourrait-elle pas être la cause de mes soucis ? J'ai actuellement des NEMA23 qui fonctionnent sous 2.8A max. Est-ce que passer sur des NEMA fonctionnant sous 4.0A max. ne serait pas une bonne chose ? Je me disais que des moteurs plus puissants devraient avoir moins d'efforts à fournir et donc moins chauffer ?

Par contre, en dehors d'un seul qui est un peu plus chaud que les 2 autres, je trouve que mes drivers/steppers ne chauffent pas beaucoup.

Sinon, je vais quand même essayer de raccourcir au maximum ma liaison entre la carte GRBL 32bits et la carte adaptateur GRBL.

@+

[mstrens]

Tu peux encore réduire la valeur du baudrate à 19200 ou même à 9600. Je ne sais pas si cela va réellement résoudre le problème.
Un baudrate très faible doit réduire les risques de perturbation sur la liaison ESP32/STM32 mais risque aussi de ralentir l'usinage (les commandes n'étant plus transmises aussi vite). 9600 était la valeur par défaut des premières versions de GRBL

Suite à ces 2 arrêts quel statut avais tu sur l'écran INFO?

Les screenshots ont ils été pris juste après l'arrêt(avant d'avoir lancé des commandes)?

Je présume que les 4 lignes commençant par [PRB: sont bien le résultat de commandes probe lancées auparavant et sont donc normales

Sur le premier screenshot, je ne vois d'anormal.
Sur le second screenshot, je ne comprends pas d'où vient le texte " mk" et de plus il semble y avoir eu un reset puisqu'on retrouve ensuite un message Grbl 1.1f....

Le fait que les moteurs soient chauds n'a rien à voir avec l'effort qu'ils doivent fournir.
Comme ce sont des moteurs pas à pas, ils sont parcourus par un courant constant lequel provoque un échauffement (effet joule).
Cet échauffement est directement proportionnel à l'intensité du courant.
Tu peux régler les drivers pour fournir un courant plus faible (par exemple à 2A). Cela réduira aussi le couple des moteurs mais il est possible que ce couple soit encore suffisant pour éviter des pertes de pas.
Une autre solution est d'augmenter leur refroidissement par exemple en ajoutant une souflerie (ou un petit ventilateur).

Je ne crois pas que ce soit cet échauffement qui provoque l'arrêt du système car GRBL n'a aucun retour d'information des drivers. Il ne sait donc pas si les moteurs tournent ni même si des drivers sont connectés ou non.

Je présume que tout est alimenté par la seule alimentation 24V. Il se pourrait que celle-ci aient des micros coupures. As tu déjà essayé d'alimenter les cartes ESP32 et STM32 par une alimentation 24V séparée de celle qui alimente les drivers (et donc les moteurs). Il suffit d'une alimentation de faible puissance (1 A est largement assez).

[Fran27]

Petit bilan des pistes de recherches sur les arrêts intempestifs :
- diverses modifications du programme grbl préconisées par mstrens,
- pose de ferrites sur plusieurs câbles d’alimentation,
- passage câblages moteurs et reset en fils blindés,
- changement bouton marche arrêt (j’avais un problème de faux contact),
- remplacement tb6600 (mauvaise fixation interne des composants, moteurs moins chaud maintenant),
- alimentation katsu extérieur à la chaine,
- vérifications et revérifications du câblage.
- test de diverses cartes mémoires.
L’ensemble de ces modifications a réduit la fréquence des arrêts, mais ils sont toujours présents.

J’ai appliqué la dernière modification conseillé par mstrens, concernant la vitesse de transmission entre grbl et esp32. J’ai usiné une pièce qui me posait problème, aucun arrêt.
Après une dizaine d’heures d’usinage sur différentes pièces, pas d’arrêt intempestifs.
Cette modification semble la bonne, j’attend de lire le résultat des essais de HTheatre en espérant que de son coté tout fonctionne.
Merci à tous pour les pistes de recherches de pannes et en particulier à mstrens pour le temps qu’il a consacré en recherches et conseils.