probleme liaison série

[skal]

Bonjour,
j'ai trouvé du temps pour avancer sur mes différents problèmes, mais je n'ai toujours pas mon module de broche PWM qui fonctionne
Suite aux problèmes électriques et après réception des STM32, j'ai repris l'électronique et la programmation à la base...
Côté programmation, j'ai pris les sources directement sur github (6-AXIS-USBCNC-GRBL et grbl_controller_esp32) et pas eu de soucis lorsque j'ai flashé le code (avec WEMOS LOLIN32 en carte).
Le démarrage s'est bien passé: écran TFT et récupération de l'adresse IP ok.
Vu que je cherche à paramétrer les vitesses de broche, j'ai recommencé à me connecter en mode série.
Le simple fait de connecter le PC portable provoque un reboot de la carte (jusque là ok), mais le redémarrage est incessant toutes le 3 / 5 secondes, et impossible de se connecter en mode série.
Le pilote utilisé pour la communication est le silicon labs CP210x.
J'ai tenté d'isoler le problème en ne branchant que la carte ESP32 avec le module STM32 (débranché les drivers, fins de course, ...) ainsi qu'un câble blindé, mais j'ai le même souci.

Est-ce possible d'avoir le wifi et la liaison série ?
Côté wifi, existe-t-il la possibilité d'un tty ?
Je suis à cours d'idées et l'impression d'avoir épluché une bonne partie des fils de discussion...

[mstrens]

Je présume que c'est l'ESP32 qui reboote continuellement.
Est-ce que je comprends bien que le problème ne se produit que quand tu relies l'ESP32 au PC via l'USB.
Donc quand l'ESP32 est seul (avec le TFT) ou uniquement relié au STM32, il n'y a pas de reboot???

C'est étrange car je ne vois pas pourquoi la connection série forcerait un reboot.

Une raison "classique" qui provoque le reboot de l'ESP32 est le fait d'avoir une alimentation qui n'est pas assez puissante.
En effet l'ESP32 a des appels de courant très importants (entre 0.5 et 1A pendant un temps très court). Si les condensateurs de découplage sont insuffisant, ces appels peuvent provoquer les reboot.
Une façon simple de tester cela est d'éviter les appels de courant dû au wifi en déactivant le wifi dans le fichier config.h de l'ESP32.
Peux-tu faire ce test?

[skal]

Je confirme,
c'est lorsque je relie l'ESP32 au PC via l'USB.
J'ai désactivé le wifi dans le fichier config.h, même problème.
Je suis reparti sur un Hello World et j'ai des soucis pour me connecter au port série de l'IDE (port COM en 115200 bds de chaque côté), donc le problème doit venir de mon PC ou d'ailleurs, mais a priori pas des cartes de la rs-cnc32.
J'ai également mesuré avec ce que j'avais sous la main le condensateur polarisé, j'arrive aux limites de mon calibre 600uF donc je suppose qu'il est bon.
Plus beaucoup de temps ce soir, merci tout de même pour l'aide.

[mstrens]

Une autre raison qui peut provoquer le reboot de l'ESP32 est l'utilisation d'un type de carte incorrecte pour la compilation/flashage dans l'arduino IDE.
Il se pourrait que le type wemos lolin 32 ne soit pas adaptée à ton module (l'ESP32 permet en effet de réaffecter les pins et il peut y avoir des conflits).
Le mieux est alors de déconnecter le module ESP32 du shield et de flasher un programme simple comme "Hello World" en essayant d'autres types de carte.

[skal]

J'ai trouvé le bon type de carte et j'ai fait un hello world serie qui fonctionne, en utilisant également un autre PC...
J'ai une carte ESP wroom 32 avec les paramètres suivant:

IMG_20191230_144032.png

2019-12-30 14_42_17-.png

J'ai reflashé le code (une première fois avec le wifi désactivé, et une deuxième avec le wifi activé) et je me suis reconnecté en mode série: mes problèmes de reboot ont disparus.
J'ai recommencé des tests manuellement, j'ai une alerte jog lors de déplacement en X (environ 70 mm) suivi d'une alarme
J'ai déjà vu la description d'une erreur du genre sur le forum il me semble.
Avec bCNC en mode communication série, j'arrive à me connecter et à voir les paramètres GRBL: je devrais donc pouvoir continuer, et gérer les paramètres de ma vitesse de broche...

Merci pour l'aide

[mstrens]

bravo, cela a bien avancé.
Les messages d'erreurs en jog ne sont pas bloquants. C'est juste un message d'attention.
Il est possible qu'il disparaisse après modifié des paramètres GRBL.
Par contre l'alarme, il faut voir le code (et le texte). Cela doit permettre de comprendre.

[skal]

Pour l'alarme, je suis en A1. fin de course atteint en étant au milieu de nulle part et en ayant effectué un home auparavant.
Sans remettre en cause le code, ça ressemble à un faux contact...
Par contre, lors de l'arrêt le statut sur le LCD passe en ?? (avec l'alerte jog) .
Après le reset je suis en Alarm, et après le débloqué, je repasse en Idle.
Dans le cas ou le fin de course serait activé, il devrait rester en Alarm, ou bien ?
J'utilise bien des câbles blindés pour les endstops.

[mstrens]

Quand l'afficheur donne ??, cela signifie que GRBL ne répond plus aux demandes de l'ESP32 (demandes envoyées plusieurs fois pas secondes pour connaître la position, le statut,...).
En fait c'est normal: GRBL est ainsi conçu qu'après une alarme (comme A1) , il se bloque et ne réagit plus à rien sauf une commande reset (et/ou peut-être unlock). Il considère qu'il n'est plus sûr de la position et attend une intervention manuelle (en principe on doit refaire un Home)

[skal]

Merci pour les précisions.
J'ai reflashé le .hex fourni par Romain dans le topic concernant la gravure des PCB histoire de repartir sur une base correcte.
A force de faire bouger la machine dans tous les sens, j'ai trouvé et résolu mon problème:
- j'avais de temps a autre les dolly qui touchait une des vis du plateau de serrage (plateau démonté en ce moment)
- le fin de course Y qui restait en position fermé après le home -> petit coup de pince sur la lamelle et c'est reparti.
Plus qu'a s'occuper de la reconnexion de la broche pour pouvoir se remettre à l'utilisation

[RoMaker]

Bonne nouvelle, t'es sur la bonne voie