Crzay Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 2 minutes, Hobi a dit : Bon, resultat des tests : La ou j'ai 60 sauts avec l'ecran, que cela soit avec ou sans DMA accélérateur, il en reste 5 sans écran. C'est bien mieux, mais pas idéal. Et ce sont toujours des sauts de 16.2ms. Toujours. ... zut. Ceci est valable a 100 ou a 170mm/s . Meme resultat, mais la vitesse d'impression de toute facon diminue car le planner a son buffer interne trop peu plein, et ralentit la machine afin d'eviter les fameux sauts. Je pousse tout ca chez Marlin... PI j'ai fait des prints de plusieurs heures ce week end à vitesse élevée (140) et aucun souci de décallage Y mais en effet: autre cm autres drivers autre ecran ah j'ai plus grand chose d'origine en fait
Crzay Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 1 minute, Epsylon3 a dit : autre marlin aussi ? aussi oui je suis parti de la bugfix-2.X original
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) mon repo perso est dessus aussi, et y'a eu pas mal de chamboullement depuis le 3 mai... pas qu'en bien Modifié (le) Mai 6, 2019 par Epsylon3
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 Au point ou nous en sommes, c'est en effet du profiling de code qu'il faudrait faire. Il y a qqchose qui bouffe du temps CPU. Ce qui me surprend, c'est que le CPU est loin d'etre un AVR... Et toujours ce trou de 16.2ms... Visiblement tu as la bonne oreille de thinkyhead.... Tu veux pas lui envoyer ma waveform???? Waveform-1.pdfWaveform-1.pdf Et le gcode associe. CFFFP_test_disc100.gcode
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) apres je me demande si on produit pas des versions de "debug" aussi.... + pt que l'écriture sur le serial 2 prend du temps -g, -ggdb DEBUG: CURRENT(stlink) EXTERNAL(blackmagic, jlink, stlink) Modifié (le) Mai 6, 2019 par Epsylon3
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 4 minutes, Crzay a dit : PI j'ai fait des prints de plusieurs heures ce week end à vitesse élevée (140) et aucun souci de décallage Y mais en effet: autre cm autres drivers autre ecran ah j'ai plus grand chose d'origine en fait Tu peux pas forcement detecter les sauts en imprimant. Il te faut un analyseur logique, meme de base.
Crzay Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 1 minute, Epsylon3 a dit : mon repo est dessus aussi, et y'a eu pas mal de chamboullement depuis le 3 mai... pas qu'en bien mon clone date d'avant en effet
Crzay Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 1 minute, Hobi a dit : Tu peux pas forcement detecter les sauts en imprimant. Il te faut un analyseur logique, meme de base. C'est dans ma wish list mias pour l'instant j'ai pas
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 Je me demande si un simple saleae 8 bits a environ 5 euros suffit pas pour voir le probleme. L'analyseur logique HP que j'ai permet de faire un trigger (CLKX ou CLKY) pendant plus de 15ms=0 > TRIG.
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 4 minutes, Epsylon3 a dit : apres je me demande si on produit pas des versions de "debug" aussi.... + pt que l'écriture sur le serial 2 prend du temps -g, -ggdb DEBUG: CURRENT(stlink) EXTERNAL(blackmagic, jlink, stlink) Ahhh possible. Je pensais que pour la version de debug, il fallait lancer le debugger... mais tu as peut être raison. En tout cas, dans le code, les pins du ST Link sont restee enablees. Mais par contre, cote switch de compilation, tu as peut etre ( et j'espere certainement raison) . Ceci dit, ton environnement de compilation est different? donc, est-ce bien pareil?
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) euh je pense, oui, j'ai juste fait 2 entrées distinctes pour U20/U30 sur mon repo, mais idem que vous quand je bosse sur le git "chronologique" (notre propre branche donc) Modifié (le) Mai 6, 2019 par Epsylon3
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) je ne parlais pas du stlink/SWD.. je ne sais pas si ca ajoute bcp de code vu que le debug est hardware.... mais plutot du serial 2 deja (genre de terminal des logs je suppose) Modifié (le) Mai 6, 2019 par Epsylon3
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) Test en cours . Config = Pas d'ecran 1 seul port serie > deuxieme supprime flags -g et -ggdb enleves Et il me fait toujours les memes trous... 16.25ms... environ 4 ou 5. Toujours avec ma rondelle a 100mm/s Donc en resume pas de changements. Il faudrait trouver le bout de code qui genere les 16.25 ms. Du genre un trigger externe hardware qui stoppe le CPU des que la condition est detectee, et qui permettrai de lire le PC pour voir ce que le CPU fait.... Si tu as une autre idee, je suis preneur Edit : Il serait interessant d'avoir un autre imprimeur qui fait le meme test à l'analyseur logique, car c'est binaire. Il y a , ou pas de trous. Sur une autre marque de CPU Modifié (le) Mai 6, 2019 par Hobi 2
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) pas vraiment dsl, mais ces libs externes non trackées par le git... ca me déboussole un peu (mais merci des tests, ca m'aidera a orienter mes futures recherches) @Hobi tu as reessayé les différents timings des drivers dans stepper/planner ? style MINIMUM_STEPPER_DIR_DELAY to 2018 value (400) mais les autres associés j'ai pas regardé Modifié (le) Mai 6, 2019 par Epsylon3
CacaoTor Posté(e) Mai 6, 2019 Auteur Posté(e) Mai 6, 2019 il y a 29 minutes, Hobi a dit : Il serait interessant d'avoir un autre imprimeur qui fait le meme test à l'analyseur logique, car c'est binaire. Il y a , ou pas de trous. Sur une autre marque de CPU J'ai ce qu'il faut mais pas possible de tester avant ce week-end...
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 1 minute, CacaoTor a dit : J'ai ce qu'il faut mais pas possible de tester avant ce week-end... Nous ne sommes pas pressés!
CacaoTor Posté(e) Mai 6, 2019 Auteur Posté(e) Mai 6, 2019 il y a 3 minutes, Hobi a dit : Nous ne sommes pas pressés! Okay je met ça au planning.
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 21 minutes, Epsylon3 a dit : pas vraiment dsl, mais ces libs externes non trackées par le git... ca me déboussole un peu (mais merci des tests, ca m'aidera a orienter mes futures recherches) @Hobi tu as reessayé les différents timings des drivers dans stepper/planner ? style MINIMUM_STEPPER_DIR_DELAY to 2018 value (400) mais les autres associés j'ai pas regardé Hmmmm, je vais regarder, mais en tout cas, le probleme de direction, ou de timing n'est pas vraiment un soucis. Le vrai probleme, c'est que les clocks disparaissent. Et pourtant, les clocks sont déja bien elargies a 6µs, et ca c'est bien stable. C'est tres tres etrange. Je n'ai jamais utiise de profiler SW. Premiere question, est il possible d'en avoir un pour STM32? J'imagine que oui...
Epsylon3 Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) oui apres il reste au pire les methodes "manuelles" avec le cpu pointer register => sortie - entree = nombre de cycles cpu https://visualgdb.com/tutorials/profiler/embedded/sampling/ j'avoue que vu que j'arrive meme pas a compiler sous vscode... lol j'ai pas cherché EDIT : piste peut etre: réduire la priorité des dma plutot que la monter... pour laisser le temps au code des isr... (interrupts etc) Modifié (le) Mai 6, 2019 par CacaoTor 1 1
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 il y a 3 minutes, Epsylon3 a dit : piste peut etre: réduire la priorité des dma plutot que la monter... pour laisser le temps au code des isr... (interrupts etc) Oui, je m’étais fait cette remarque. ça pourrait aider. Ce qui est surprenant cependant c'est le comportement identique avec ou sans dma. il faudrait mesurer amélioration réelle de performances.
Hobi Posté(e) Mai 6, 2019 Posté(e) Mai 6, 2019 (modifié) @Epsylon3 je repense à la différence entre un chip 100 pin et un 144 pins . Nous avons eu au début un problème de timer avec la pin de pwm. Jmz52 avait suggéré de changer le timer 2 pour le timer 4 pour éviter tout conflit. C’est une des différences avec les autres board stm 32. Peut être aucune influence mais ça vaut le coup d essayer ... des fois que au fin fond d’un morceau de code le timer 2 soit remis à 0 de manière sauvage... et repasser le fan soft pwm en vrai pwm hard ( avec open collector!!) Modifié (le) Mai 7, 2019 par Hobi
Acidounet Posté(e) Mai 7, 2019 Posté(e) Mai 7, 2019 Vous en êtes ou ? on retest ? la version en ligne est fonctionnel ?
Epsylon3 Posté(e) Mai 7, 2019 Posté(e) Mai 7, 2019 (modifié) bon aujourd'hui plus calme, j'ai nettoyé un peu pour mettre les nouveaux define dma une seule fois dans le board pins.h restera tout le (sous) projet de calibration à nettoyer/adapter aussi pour reduire le code en double. Sinon oui tu peux compiler/utiliser pas de soucis Modifié (le) Mai 7, 2019 par Epsylon3 1 1
Hobi Posté(e) Mai 7, 2019 Posté(e) Mai 7, 2019 (modifié) @Epsylon3 merci! Le seul truc en plus à faire, c'est une version headless, qui diminue l’occurrence du problème d'un facteur 10, sans pour autant supprimer ce soucis complètement. C'est juste une histoire de defines > faut désactiver robin_tft_lcd, touchscreen, custom_boot_screen je crois, filament sensor, advance pause, et nettoyer les defines de calibration. Le code sera aussi propre, et aussi fonctionnel qu'il peut l’être, et je te remercie de tout ce temps passé à corriger, et nettoyer. C'est un super boulot que tu as fait. Je continue a traquer le bug > identifier le morceau de code qui prends toujours 16.25ms... @Acidounet : Le code est fonctionnel dans le git. Le seul workaround simple pour l'instant c'est d'avoir un Vref Y un peu plus haut, et de ne pas accélérer trop fort ni aller trop vite, et d'avoir un jerk faible, comme Epsylon3 a indique ci dessous. Modifié (le) Mai 7, 2019 par Hobi
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