Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Coté MMU c'est bon mais coté CM le message n'est pas bon: https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/feature/prusa_MMU2/serial-protocol.md
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 je n'arrive pas à communiquer avec le MMU, si j'envoie S1, j en'ai pas de rertour, comme si mes commandes ne l'atteigne pas
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 (modifié) coté CM c'est OK ! le serial dialoque en 250 000 au boot, et ensuite il change en 115 200 pour le MMU : 250000: 115200 Modifié (le) Octobre 6, 2019 par lolvince
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Tu as un écran en UART en même temps? Est-il configuré dans Marlin?
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Si c'est un TFT, il est probablement en UART aussi et utilise peut-être le même port série.
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 je ne comprend pas ce qui te fait dire ça concernant l’écran, je devrai avoir des traces dans mon sérial du coup non ? coté MMU on à bien le "start", et coté CM on trouve bien le "MMU <= Reset", d’ailleurs, ne devrait-il pas être simplement envoyé "reset" ? les indications MMU => ou mmu <= sont la pour le débug Série via le port 1 afin de voir ce qu'il se passe coté octoprint par exemple...
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Les caractères avant MMU sont bizarres et anormaux je pense.
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 je pense que mon problème est ici : le serial 2 est aussi utilisé pour le contrôle via octrpint par exemple
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 (modifié) Bien vu, désactive le pour tester. Modifié (le) Octobre 6, 2019 par Tircown
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 bon la COM avec l'unité MMU fonctionne parfaitement, j'arrive à émuler 1
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 (modifié) bon compilation terminé, pas d’activité sur le port COM2 en désactivant ceci : Modifié (le) Octobre 6, 2019 par lolvince
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Je pense que define NUM_SERIAL 2 ne doit pas être commenté, juste la première ligne.
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 bon si je commente les 2 lignes, que je déclare : MMU2_SERIAL Mserial2 je n'ai rien sur le port COM si je déclare : MMU2_SERIAL Serial2 je me retrouve avec la même console qu'avant...
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 pour que ça soit plus simple, j'ai mis : #define BAUDRATE 115200
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 j'ai par contre beaucoup de mal à envoyer des messages via le port COM2, ceci sont tronqué ou déformé !
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Là pour le coup il manque le retour de la carte.
Tircown Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 Question bête: t'as bien décommenté //#define PRUSA_MMU2 dans Configuration.h
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 ça y est !!! j'ai commenté : SERIAL_PORT2 2 MMU2_RST_PIN afin de d'envoyer le reset via le port série (X0) mis : MMU2_SERIAL SERIAL2 et maintenant c'est OK,sauf que le reset initial, n'st pas pris en compte, il faut en renvoyer un grâce au menu MArlin, et la liaison se fait correctement. je pense que le MMU boot trop rapidement, et envoie la trame START avant le reset ^^
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 reste la partie fonctionnement MMU2 sur notre U20 avec notre système actuel, sinon passer en direct Drive mais ce n'est plus trop mon domaine de compétence
Epsylon3 Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 j'avais oublié de pusher le commit pour désactiver le serial2 sur le repo Hobi... pour définir le baudrate juste pour Serial2... il faut ajouter Serial2.begin(115200); qqpart.. genre dans HAL_init() (Marlin/src/HAL/HAL_STM32F1/HAL.cpp)
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 il y a quand même un truc étrange sur le port série. il y a bien l'instruction Reset envoyé qui reste sans réponse. bien que le MMU fait son reset au boot, et envoie donc start de suite. si on relance un reset depuis le menu : Recv: MMU <= reset Recv: rx buffer overrun Recv: echo:enqueueing "�\x01" Recv: echo:Unknown command: "�\x01" Recv: echo:enqueueing "�\x01" Recv: echo:Unknown command: "�\x01" Recv: MMU => 'start' Recv: MMU <= 'S1' Recv: MMU => 106 Recv: MMU <= 'S2' Recv: MMU => 372 Recv: MMU <= 'P0' Recv: MMU => 0 Recv: MMU - ENABLED ce qui semble se trouver entre le reset et le start ne semble pas être bon signe... j'ai le serial USB en 250000 Baud et le serial 2 en 115 200. la trace plus haut correspond au MMU debug via le port série USB depuis octoprint
lolvince Posté(e) Octobre 6, 2019 Posté(e) Octobre 6, 2019 @Epsylon3 c'est le composant MMU2.cpp qui initialise le port 2 à 115200 mmuSerial.begin(MMU_BAUD);
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant