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

[Epsylon3]

si tu as peur de l'axe du moteur (ce qui n'est pas vrai, ca se remet ensuite tres vite) tu peux en mettre 2... avant et arriere

Modifié (le) Mai 4, 2019 par Epsylon3

[CacaoTor]

il y a 3 minutes, Epsylon3 a dit :

si tu as peur de l'axe du moteur (ce qui n'est pas vrai, ca se remet ensuite) tu peux en mettre 2... avant et arriere

Bah ça se remet peut-être après, mais pas pendant l'impression... Il existe d'ailleurs des supports à imprimer qui compensent le désaxage avec damper.

Tout ça pour dire ==> Mécanique nickel PUIS adapter/arranger côté software. Le problème reste double.

Modifié (le) Mai 4, 2019 par CacaoTor

[Hobi]

Il y a 5 heures, Epsylon3 a dit :

en rapport : https://github.com/MarlinFirmware/Marlin/issues/12461

Ah bhein on retombe sur la modif faite fin septembre...

et le probleme est visiblement lie a l écran de surveillance, et à l affichage des coordonnees....

 

plus la modif pour utiliser de toute facon le DMA, on va devernir bien....

plus un petit overclocking en bidouillant un peu les PLLs  

Modifié (le) Mai 4, 2019 par Hobi

[Epsylon3]

niveau OC... pour info les dernieres cartes de dev ST (64 pins) qui coutent 16-20€ sont a 180MHz   genre la Nucleo STM32F446RE

https://www.st.com/en/microcontrollers-microprocessors/stm32f446re.html

4/5$ le chip

Modifié (le) Mai 4, 2019 par Epsylon3

[Hobi]

Il y a 6 heures, Epsylon3 a dit :

cherche LCD_UPDATE_INTERVAL

mais... on doit pouvoir améliorer ca sans trop toucher a ca

#if defined(TOUCH_BUTTONS)

#define LCD_UPDATE_INTERVAL 20

#else

#define LCD_UPDATE_INTERVAL 100

#endif

@Epsylon3 C'est la constante que nous avons diminue pour rendre le touch plus reactif, exact? 

L'ecran de surveillance a un effet bien plus fort que les sous menus sur le probleme .... On pourrait deja adapter la constante sur l'ecran de surveillance a 100, par example, et 20 dans les sous menus. 

Ceci dit, toucher au touch durant une impression est pas terrible, car on passe par un reset du LCD, qui stoppe l'impression completement pendant une demi seconde.

[Epsylon3]

hmm bien vu, enfin... on peut faire un "wakeup" avant un reset aussi, en 2 temps

premier = status, puis "menu" = reset

Modifié (le) Mai 4, 2019 par Epsylon3

[Acidounet]

Sinon les coordonnées pendant l impression  ne peuvent pas être supprimé ?  L utilité réel est proche de 0, illisible car ça bouge ts le temps et  trop rapide 

[Hobi]

@Epsylon3 Tu vas rire... Regarde dans l'ancien repo avec les libs 5.1.0, au niveau du fsmc... J'utilisais le DMA! pfff et comme ils ont change le code pour etre compatible U8Gblib, j'ai rechange le code... J'avais le DMA, et je l'ai vire en prenant la version officielle a jour de Marlin... LOL. 

EDIT : Ooops , j'ai melange les codes... Bon DODO!

EDIT 2 : 

@Epsylon3

Non, c'est bien ca! Les vieilles sources ont bien le DMA :

Du coup, c'est pas trop dur a changer. Par contre, il y a toutes tes petites modifs a remettre par dessus....

void LCD_IO_WriteMultiple(uint16_t data, uint32_t count) {
	while (count > 0) {
	dma_setup_transfer(FSMC_DMA_DEV, FSMC_DMA_CHANNEL, &data, DMA_SIZE_16BITS, &LCD->RAM, DMA_SIZE_16BITS, DMA_MEM_2_MEM);
	dma_set_num_transfers(FSMC_DMA_DEV, FSMC_DMA_CHANNEL, count > 65535 ? 65535 : count);
	dma_clear_isr_bits(FSMC_DMA_DEV, FSMC_DMA_CHANNEL);
	dma_enable(FSMC_DMA_DEV, FSMC_DMA_CHANNEL);

Modifié (le) Mai 4, 2019 par CacaoTor

[Epsylon3]

il y a 17 minutes, Acidounet a dit :

Sinon les coordonnées pendant l impression  ne peuvent pas être supprimé ?  L utilité réel est proche de 0, illisible car ça bouge ts le temps et  trop rapide 

ca changera rien.... le temps d'affichage != changement des données

[Hobi]

Hmmm ce qui n est pas très clair encore pour moi . 

Passer de dogm au lcd > transfert dma possible à re- implanter. 

par contre pour construire l image dans dogm et l afficher , il y a un petit frame buffer exact? On  peut aussi jouer du dma mais faut que ça en vaille la peine...

[Epsylon3]

pas si sur, vu que ca affecte les LCD texte aussi...

il vaut mieux gérer un boolean global pour empecher de raffraichir quand ca "print" sur les drivers, qq nano/ms a mon avis

Modifié (le) Mai 4, 2019 par Epsylon3

[Hobi]

Exact. 

Donc le plus simple > remettre le dma complet uniquement au niveau de fsmc ( effacement de l écran par exemple ou bien affichage des icônes complètes comme les flèches ou logos genre “sd” et amélioration de la gestion de dogm avec un Boolean global... exact? 

[Hobi]

@Epsylon3

juste pour que tu aies les mêmes infos que moi. Les pulses de stepper sont espacés de 100 à 600us. Le bout de code qui prend la main, visiblement lié à l affichage  bloque  tout pendant 16ms. Et à priori empêche par exemple le planner de préparer les steps pour la tache d interruption des steppers... 

[schragner.jgw@gmail.com]

Salut je viens de l’Autriche, je serais ravi d’utiliser de firmware à partir d’eux que je voudrais qu’il ait la langue allemande lui Marlin comme je peux changer la langue parce que je comprends Français pas Dane pour l’aide  

[CacaoTor]

il y a 14 minutes, schragner.jgw@gmail.com a dit :

Salut je viens de l’Autriche, je serais ravi d’utiliser de firmware à partir d’eux que je voudrais qu’il ait la langue allemande lui Marlin comme je peux changer la langue parce que je comprends Français pas Dane pour l’aide  

Hello,

We have to code for the new requested language...

Sorry, not for now.

[Hobi]

il y a 17 minutes, schragner.jgw@gmail.com a dit :

Salut je viens de l’Autriche, je serais ravi d’utiliser de firmware à partir d’eux que je voudrais qu’il ait la langue allemande lui Marlin comme je peux changer la langue parce que je comprends Français pas Dane pour l’aide  

We have to fix a nasty bug before releasing it again... should not be too long as we found out one of the main root cause... 

[boleofr]

@Hobi @Epsylon3

Ce matin je me pose une question et je ne vois pas de lien entre l'interruption de l'écran et le fait de booster les vref. 

Si pas de temps cpu pour piloter les moteurs, ça veut dire que l'augmentation de la vref permet de rattraper le retard juste après ? 

[Hobi]

@Epsylon3

Quelques petite mesures de timing faites pour verifier la lenteur.... Et ca donne ca : 

Le signal LA_TRIG est genere par le code du LCD U8_dev_tft_320x240_upscale_from128x64.cpp : 

case U8G_DEV_MSG_PAGE_NEXT:

OUT_WRITE(LA_TRIG,HIGH);

for (uint16_t y = 0; y < 8; y++) {

uint32_t k = 0;

for (i = 0; i < (uint32_t)pb->width; i++) {

const uint8_t b = *(((uint8_t *)pb->buf) + i);

const uint16_t c = TEST(b, y) ? TFT_MARLINUI_COLOR : TFT_MARLINBG_COLOR;

buffer[k++] = c; buffer[k++] = c;

}

for (k = 0; k < 2; k++) {

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)buffer);

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[64]));

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[128]));

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[192]));

}

}

OUT_WRITE(LA_TRIG,LOW);

break;

Waveform 1, on voit bien le trou au niveau des steps, et ensuite la séquence de transfert de l'image vers le LCD, qui prend au total 42ms, avec 8 phases > rien que la c'est environ 30ms de CPU. 

Waveform2 : On recommence environ toute les 158ms à ecrire dans le LCD. 

1/ Avec le DMA, le temps CPU libere va permettre de calculer les steps a faire plus souvent ( si j'ai bien compris c'est le code du "planner") . Et je me demande si le CPU serait pas en train d'ecrire des bytes... et pas des words de 16 bits. Le DMA sera 16 bits, c'est sur. 

2/ Il y a le refresh de 158 ms qui est eleve > Ca doit etre le timing global du LCD qui à ete mis a 200ms... ca semble à peu pres coherent.

Et puis, il ya des optimisations au niveau des champs à mettre a jour... X,Y,Z n'ont pas besoin d'etre mis a jour tres souvent... 1s suffirait. Idem la temperature. Faut juste que le CPU soit pas monopolise trop longtemps. 

Waveform-1.pdf Waveform-2.pdf

[Hobi]

il y a 1 minute, boleofr a dit :

@Hobi @Epsylon3

Ce matin je me pose une question et je ne vois pas de lien entre l'interruption de l'écran et le fait de booster les vref. 

Si pas de temps cpu pour piloter les moteurs, ça veut dire que l'augmentation de la vref permet de rattraper le retard juste après ? 

En fait, on ne perds pas de steps, mais comme tu pourras le constater, il y a un "trou", et pendant quelques ms, les steppers n'avancent pas. Et les steps recommencent de manière ultra brutale. Le fait de monter Vref permet au moteur de re-accelerer très fort, et tres vite, pour ne pas perdre le step demande. C'est ce que je pense... L'inertie du plateau aide aussi un peu à la décéleration, pour commencer a faire tourner le stepper ver le pas suivant, meme si compte tenu du probleme, la commande de step est retardee... 

Et oui, on rattrape le retard juste apres. Mais vu l'irreguarite de la chose, des fois, ca passe pas. Il suffit que le trou sanssteps demandes soit un peu plus grand, et hop > on decale le print. 

Suis-je clair? 

[boleofr]

@Hobi limpide ! 

[Epsylon3]

@Hobi je n'ai pas gardé les premiers repos privés par contre, je pensais qu'on avait le meme code pour le dogm/lcd...

tu pourrais essayer de le commiter ?

[Hobi]

Le ralentissement du refresh de LCD ne permet pas de completement enlever le probleme. C'est diminue, mais une autre partie du code consomme trop de temps.

Resultat en PJ > Y a encore des trous....Faut ameliorer le code! 

 

#if defined(TOUCH_BUTTONS)

#define LCD_UPDATE_INTERVAL 75

#else

#define LCD_UPDATE_INTERVAL 100

#endif

Waveform-3.pdf

[sdelehaye]

bon çà faisait plusieurs fois que j'avais un doute. J'ai donc creusé un peu ce matin.

 

Impression de 4 tiges de 1 mm espacé de 100 sur des coordonnées définit pour être facile à lire en x et y. j'ai lancé a 100, 150, 175 ... avec le lcd on jerk 10

 

De temps à autre les cordonnées affichés n'ont RIEN a voir avec la position de la tête, par exemple sur l'une des tiges en 130/150 j'ai vu des valeur y s'afficher tel que 326 et 871 (et regulierement des 0) ! 0 décalage mais bien des problèmes de gestion des données

Modifié (le) Mai 5, 2019 par sdelehaye

[Hobi]

il y a 13 minutes, Epsylon3 a dit :

@Hobi je n'ai pas gardé les premiers repos privés par contre, je pensais qu'on avait le meme code pour le dogm/lcd...

tu pourrais essayer de le commiter ?

LOL, Si tu parles du premier repo prive compile avec la lib STM 5.1.0, je l'ai aussi jete, mais il me semble que @CacaoTor ou @Crzay l'ont encore.... Je l'espere. En effet, dans celui la le DMA est present. Je crois meme que Cacaotor l'a envoye a clement directement. On croise le doigts. 

Je n'ai rien touche dans Dogm. C'est juste au niveau des 2 fichiers FSMC qu'il y a des modifs. 

Edit... J'ai du toucher pas mal de fichier pour regreffer le touch...  zut , ca me revient... 

Modifié (le) Mai 5, 2019 par Hobi

[Epsylon3]

ok, j'ai mis 50 et 150 en interval (50 dans les menus et 150 sur l'écran d'accueil)

j'ai aussi pushé l'enregistrement de la calibration... toujours pas fait auto au démarrage

et réduit aussi HOMING_FEEDRATE_XY pour le bienêtre des sensors fragiles

restera ce dma fsmc à faire...

Modifié (le) Mai 5, 2019 par Epsylon3