[Dev] AlfaWise U20x-U30 : Marlin 2.x (firmware alternatif)

[Crzay]

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

[Epsylon3]

autre marlin aussi ?

[Crzay]

il y a 1 minute, Epsylon3 a dit :

autre marlin aussi ?

aussi  oui je suis parti de la bugfix-2.X   original

[Epsylon3]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Epsylon3]

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]

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]

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]

il y a 3 minutes, Hobi a dit :

Nous ne sommes pas pressés!

Okay je met ça au planning.

[Hobi]

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]

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

[Hobi]

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]

@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]

Vous en êtes ou ? on retest ? la version en ligne est fonctionnel ?

[Epsylon3]

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

[Hobi]

@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