Problème firmware pour 4eme axe

[manutere]

Bonjour à tous. J'aurais besoin de votre aide.

J'ai installé le firmware pour le 4e axe de mstrens et j'ai plusieurs soucis. Je ne penses pas que tous sont forcément liés au firmware mais bon:

1er problème:

- Dès que je démarre, la machine se met en erreur et je suis obligé de faire un reset et un débloquer à chaque fois. Il me semble qu'il y avait ceci au début sur le firmware et que ça avait été changé (je n'en suis vraiment pas sûr..). Peut-être que la modification n'a pas été faite sur cette version du firmware. Si quelqu'un peut me dire comment faire...

2ème problème:

- l'écran ne veux plus voir ma carte sd. J'ai un message d'erreur qui me dit qu'il n'arrive pas à monter la carte sd. et lorsque je fais un reset, j'ai un message qui apparait qui me dit que un endstop à été activé. c'est bizarre. Je vais essayer de lire la carte sd sur le pc et tester à nouveau. On verra bien.

3ème problème:

-lorsque je bouge suivant l'axe Z avec l'écran ou avec le nunchuck et que j'active manuellement le endstop, la machine s'arrête mais lorsque je lance un "HOME", la broche monte sur Z mais ne s'arrête pas lorsque le endstop est activé. Je n'ai pas pensé à vérifier si cela fait la même chose sur les autres axes. Désolés.

édit: lorsque je monte la broche avec l'écran ou avec le nunchuck, l'axe Z s'arrête automatiquement lorsque le endstop est activé mais toujours pas quand je fait un home.
éedit2: je n'ai pas encore relié le câblage des enstop à la masse de l'alim, est-ce que ça pourrait venir de ça?

Merci pour votre aide.

PS: il faut savoir que j'ai réalisé un boitier externe pour la cnc. J'ai vérifié les branchements et ça à l'air d'être bon....

[mstrens]

La machine qui se met en erreur à la mise sous tension est "normal".
C'est le fonctionnement prévu en standard de GRBL.
C'est une sécurité pour ne pas commencer à l'utiliser avant d'avoir penser à faire un Home.
Si cela te gène vraiment tu peux désactiver cette fonctionnalité dans le fichier config.h
Voici l'extrait de la doc GRBL:

// If homing is enabled, homing init lock sets Grbl into an alarm state upon power up. This forces
// the user to perform the homing cycle (or override the locks) before doing anything else. This is
// mainly a safety feature to remind the user to home, since position is unknown to Grbl.
#define HOMING_INIT_LOCK // Comment to disable

Le problème de la carte SD n'est en principe pas lié au 4ème axe.
C'est un problème rencontré par plusieurs personnes qui se solutionne habituellement en essayant une autre carte SD.
Je ne connais pas l'origine du problème car le programme utilise une bibliothèque complexe SDFAT qui en principe fonctionne bien.

Le problème du Homing est classique. Tu as un fin de course X ou Y qui est raccordé sur la pin prévue pour le fin de course Z de la carte STM32.
Lors d'un déplacement, GRBL s'arrête dès qu'un fin de course est activé même si celui-ci n'est pas dans la direction du mouvement.
Le fait d'inverser la connexion de 2 fins de course n'a donc pas d'effet.
Par contre, lors d'un home, GRBL ne regarde que le(s) fin(s) de course correspondant au déplacement en cours. Si un fin de course X ou Y est activé pendant un homing en Z, GRBL ne le détecte pas.

[manutere]

Merci pour tes réponses, ça me rassure.

La machine qui se met en erreur à la mise sous tension est "normal".
C'est le fonctionnement prévu en standard de GRBL.
C'est une sécurité pour ne pas commencer à l'utiliser avant d'avoir penser à faire un Home.
Si cela te gène vraiment tu peux désactiver cette fonctionnalité dans le fichier config.h
Voici l'extrait de la doc GRBL:

// If homing is enabled, homing init lock sets Grbl into an alarm state upon power up. This forces
// the user to perform the homing cycle (or override the locks) before doing anything else. This is
// mainly a safety feature to remind the user to home, since position is unknown to Grbl.
#define HOMING_INIT_LOCK // Comment to disable

Je n'avais pas cette sécurité sur le firmware sans le 4eme axe du coup je me demande: est-ce que c'est moi qui l'avait enlevé? fort possible que je ne m'en souvienne pas

Le problème de la carte SD n'est en principe pas lié au 4ème axe.
C'est un problème rencontré par plusieurs personnes qui se solutionne habituellement en essayant une autre carte SD.
Je ne connais pas l'origine du problème car le programme utilise une bibliothèque complexe SDFAT qui en principe fonctionne bien.

Ok je vais tester, il me semble que j'en ai une autre quelque part.

Le problème du Homing est classique. Tu as un fin de course X ou Y qui est raccordé sur la pin prévue pour le fin de course Z de la carte STM32.
Lors d'un déplacement, GRBL s'arrête dès qu'un fin de course est activé même si celui-ci n'est pas dans la direction du mouvement.
Le fait d'inverser la connexion de 2 fins de course n'a donc pas d'effet.
Par contre, lors d'un home, GRBL ne regarde que le(s) fin(s) de course correspondant au déplacement en cours. Si un fin de course X ou Y est activé pendant un homing en Z, GRBL ne le détecte pas.

Si j'ai bien compris, je serais mal branché sur la carte qui supporte le STM32. j'aurais inversé des pin entre le x ou y et le z. tu me dis si je me trompe. Du coup je vais aussi vérifier ça. J'ai du passer à coté cet aprem car j'ai résolu un problème de connexion sur ses pins justement parce que j'avais inversé des trucs et que les endstop de x et z ne fonctionnaient pas. on va recommencer, ce n'est pas grave

encore merci.

[mstrens]

Je crois que c'est Romain qui avait désactivé cette option de blocage à la mise sous tension dans une des première versions.
C'est juste un choix personnel.

Oui tu dois avoir fait une inversion. C'est facile d'identifier quel fil correspond à quel fdc avec un Ohmmètre en les activant manuellement.

[HTheatre]

2ème problème:

- l'écran ne veux plus voir ma carte sd. J'ai un message d'erreur qui me dit qu'il n'arrive pas à monter la carte sd. et lorsque je fais un reset, j'ai un message qui apparait qui me dit que un endstop à été activé. c'est bizarre. Je vais essayer de lire la carte sd sur le pc et tester à nouveau. On verra bien.

Vérifie également que dans ARDUINO IDE, tu n'aies pas une autre version que la version 1.1.0 de la SdFat. Jette un œil au fascicule dédié à la programmation de l'ESP-32 dans la notice de montage, c'est expliqué. Si tu as une autre version d'installée, ré-installe la version 1.1.0 et reflashe ton ESP-32. C'est ARDUINO IDE qui propose automatiquement à chaque démarrage de mettre à jour les bibliothèques qui sont chargées. Si tu as, ne serait-ce qu'une fois, accepté la mise à jour des bibliothèques entre 2 flashes de l'ESP-32, il y a de fortes chances que tu aies une autre version que la version 1.1.0 de la SdFat qui soit chargée et donc utilisée lors des flashes.

[manutere]

Vérifie également que dans ARDUINO IDE, tu n'aies pas une autre version que la version 1.1.0 de la SdFat. Jette un œil au fascicule dédié à la programmation de l'ESP-32 dans la notice de montage, c'est expliqué. Si tu as une autre version d'installée, ré-installe la version 1.1.0 et reflashe ton ESP-32. C'est ARDUINO IDE qui propose automatiquement à chaque démarrage de mettre à jour les bibliothèques qui sont chargées. Si tu as, ne serait-ce qu'une fois, accepté la mise à jour des bibliothèques entre 2 flashes de l'ESP-32, il y a de fortes chances que tu aies une autre version que la version 1.1.0 de la SdFat qui soit chargée et donc utilisée lors des flashes.

En fait, la carte fonctionnait et d'un coup, ça s'est mis à ne plus fonctionner. Il me semble que j'avais justement vérifié avant de flasher.
Je vais quand même y jeter un oeil. Merci

[manutere]

Je crois que c'est Romain qui avait désactivé cette option de blocage à la mise sous tension dans une des première versions.
C'est juste un choix personnel.

Oui tu dois avoir fait une inversion. C'est facile d'identifier quel fil correspond à quel fdc avec un Ohmmètre en les activant manuellement.

Ah!! C'est pas ma mémoire qui me joue des tours