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

[boleofr]

platformio.iniJ'ai compilé à l'instant avec la dernière version du git

[Epsylon3]

yep je ne sais pas bien ce qui bloque, j'ai pourtant Hexchat qui utilise python3 sans soucis... et j'ai aussi desactivé Intelli-Nonsense pour éviter l'indexation inutile.

Non ca n'a jamais marché sinon, toujours pareil... aucun soucis sous linux, ca a fonctionné direct

Modifié (le) Mai 3, 2019 par Epsylon3

[Acidounet]

J ai relancé VS  et petite erreur : 

LibraryManager: Installing SailfishLCD
Error: Please install Git client from https://git-scm.com/downloads
The terminal process terminated with exit code: 1

Terminal will be reused by tasks, press any key to close it.

Recherche sur le fofo et installation de https://git-scm.com/download/win 

J ai relancer Visual studio, compiler et j ai mon fichier

Merciiiiiiii

Modifié (le) Mai 3, 2019 par Acidounet

[Epsylon3]

@CacaoTor sinon en fait j'ai une V08 sur la U30... V07 U20... je crois j'ai du confondre lol, meme si j'ai pas vu la difference entre les 2...

photo HD : https://drive.google.com/file/d/1GnUvKOGbRQBCHIkyXAv4h27oLxcUk_-Z/view?usp=sharing

[CacaoTor]

il y a 13 minutes, Acidounet a dit :

J ai relancé VS  et petite erreur : 

LibraryManager: Installing SailfishLCD
Error: Please install Git client from https://git-scm.com/downloads
The terminal process terminated with exit code: 1

Terminal will be reused by tasks, press any key to close it.

Recherche sur le fofo et installation de https://git-scm.com/download/win 

J ai relancer Visual studio, compiler et j ai mon fichier

Merciiiiiiii

Yes c'est indiqué en pré-requis Git client sur le tuto  

il y a 3 minutes, Epsylon3 a dit :

@CacaoTor sinon en fait j'ai une V08 sur la U30... V07 U20... je crois j'ai du confondre lol, meme si j'ai pas vu la difference entre les 2...

photo HD : https://drive.google.com/file/d/1GnUvKOGbRQBCHIkyXAv4h27oLxcUk_-Z/view?usp=sharing

Très peu de différences oui entre ces cartes. Ça doit se jouer à quelques références de composants / placements.

Modifié (le) Mai 3, 2019 par CacaoTor

[Epsylon3]

euh oui et j'avais ajouté un radiateur sur le 24 -> 5V  plutot pour pouvoir mesurer sa température

[CacaoTor]

ATTENTION : Ce TOPIC est désormais dédié au dev du portage, ses améliorations et bugs.

Le Tuto a été déplacé ici :

[CacaoTor]

Pour info, j'ai demandé les sources de la U20Pro.

[boleofr]

il y a 4 minutes, Epsylon3 a dit :

J'ai peur que ce soit assez compliqué ca  vu les modifs, ils ont quasi tout changé en mai dernier

C'est clair.... L'assembleur c'est "bien" (encore que) mais en lisibilité, c'est pas humain

        // For ARM Cortex M3/M4 CPUs, we have the optimized assembler version, that takes 43 cycles to execute
        uint32_t flo = 0;
        uint32_t fhi = bezier_AV * curr_step;
        uint32_t t = fhi;
        int32_t alo = bezier_F;
        int32_t ahi = 0;
        int32_t A = bezier_A;
        int32_t B = bezier_B;
        int32_t C = bezier_C;

         __asm__ __volatile__(
          ".syntax unified" "\n\t"              // is to prevent CM0,CM1 non-unified syntax
          A("lsrs  %[ahi],%[alo],#1")           // a  = F << 31      1 cycles
          A("lsls  %[alo],%[alo],#31")          //                   1 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f *= t            5 cycles [fhi:flo=64bits]
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[C]")  // a+=(f>>33)*C;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[B]")  // a+=(f>>33)*B;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           // f>>=33;           1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[A]")  // a+=(f>>33)*A;     5 cycles
          A("lsrs  %[alo],%[ahi],#6")           // a>>=38            1 cycles
          : [alo]"+r"( alo ) ,
            [flo]"+r"( flo ) ,
            [fhi]"+r"( fhi ) ,
            [ahi]"+r"( ahi ) ,
            [A]"+r"( A ) ,  // <== Note: Even if A, B, C, and t registers are INPUT ONLY
            [B]"+r"( B ) ,  //  GCC does bad optimizations on the code if we list them as
            [C]"+r"( C ) ,  //  such, breaking this function. So, to avoid that problem,
            [t]"+r"( t )    //  we list all registers as input-outputs.
          :
          : "cc"
        );
        return alo;

Modifié (le) Mai 3, 2019 par boleofr

[Hobi]

à l’instant, boleofr a dit :

C'est clair.... L'assembler c'est bien mais en lisibilité, c'est pas humain

        // For ARM Cortex M3/M4 CPUs, we have the optimized assembler version, that takes 43 cycles to execute
        uint32_t flo = 0;
        uint32_t fhi = bezier_AV * curr_step;
        uint32_t t = fhi;
        int32_t alo = bezier_F;
        int32_t ahi = 0;
        int32_t A = bezier_A;
        int32_t B = bezier_B;
        int32_t C = bezier_C;

         __asm__ __volatile__(
          ".syntax unified" "\n\t"              // is to prevent CM0,CM1 non-unified syntax
          A("lsrs  %[ahi],%[alo],#1")           // a  = F << 31      1 cycles
          A("lsls  %[alo],%[alo],#31")          //                   1 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f *= t            5 cycles [fhi:flo=64bits]
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[C]")  // a+=(f>>33)*C;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[B]")  // a+=(f>>33)*B;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           // f>>=33;           1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[A]")  // a+=(f>>33)*A;     5 cycles
          A("lsrs  %[alo],%[ahi],#6")           // a>>=38            1 cycles
          : [alo]"+r"( alo ) ,
            [flo]"+r"( flo ) ,
            [fhi]"+r"( fhi ) ,
            [ahi]"+r"( ahi ) ,
            [A]"+r"( A ) ,  // <== Note: Even if A, B, C, and t registers are INPUT ONLY
            [B]"+r"( B ) ,  //  GCC does bad optimizations on the code if we list them as
            [C]"+r"( C ) ,  //  such, breaking this function. So, to avoid that problem,
            [t]"+r"( t )    //  we list all registers as input-outputs.
          :
          : "cc"
        );
        return alo;

Oooops, j'avais pas regarde ca... OMG! 

[Hobi]

puree.... Ca existe encore ca... mon dieu... 

[Epsylon3]

non, la difficulté n'est pas de remettre un fichier à telle date.... c'est super simple à faire : 

git checkout <hash> ./fichier.cpp

le probleme c'est que les .h sont liés etc, les HAL etc

Modifié (le) Mai 3, 2019 par Epsylon3

[Hobi]

il y a 3 minutes, boleofr a dit :

C'est clair.... L'assembleur c'est "bien" (encore que) mais en lisibilité, c'est pas humain

        // For ARM Cortex M3/M4 CPUs, we have the optimized assembler version, that takes 43 cycles to execute
        uint32_t flo = 0;
        uint32_t fhi = bezier_AV * curr_step;
        uint32_t t = fhi;
        int32_t alo = bezier_F;
        int32_t ahi = 0;
        int32_t A = bezier_A;
        int32_t B = bezier_B;
        int32_t C = bezier_C;

         __asm__ __volatile__(
          ".syntax unified" "\n\t"              // is to prevent CM0,CM1 non-unified syntax
          A("lsrs  %[ahi],%[alo],#1")           // a  = F << 31      1 cycles
          A("lsls  %[alo],%[alo],#31")          //                   1 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f *= t            5 cycles [fhi:flo=64bits]
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[C]")  // a+=(f>>33)*C;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           //                   1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[B]")  // a+=(f>>33)*B;     5 cycles
          A("umull %[flo],%[fhi],%[fhi],%[t]")  // f>>=32; f*=t      5 cycles [fhi:flo=64bits]
          A("lsrs  %[flo],%[fhi],#1")           // f>>=33;           1 cycles [31bits]
          A("smlal %[alo],%[ahi],%[flo],%[A]")  // a+=(f>>33)*A;     5 cycles
          A("lsrs  %[alo],%[ahi],#6")           // a>>=38            1 cycles
          : [alo]"+r"( alo ) ,
            [flo]"+r"( flo ) ,
            [fhi]"+r"( fhi ) ,
            [ahi]"+r"( ahi ) ,
            [A]"+r"( A ) ,  // <== Note: Even if A, B, C, and t registers are INPUT ONLY
            [B]"+r"( B ) ,  //  GCC does bad optimizations on the code if we list them as
            [C]"+r"( C ) ,  //  such, breaking this function. So, to avoid that problem,
            [t]"+r"( t )    //  we list all registers as input-outputs.
          :
          : "cc"
        );
        return alo;

Les beziers, normalement, ca sert pas... C'est le super algo linear xyz, qui est desactive.

[boleofr]

@Hobi c'est juste pour l'exemple, le src/feature/stepper.cpp est plein de "trucs" dans le genre...

[Hobi]

snif.... Bon je vais me pendre.... 

[Hobi]

Hmmm, le code assembleur ne nous sert pas.... 

Le codeur qui a fait ca vient des annees 50... OMG. 

Vu tout le code qui ne nous sert pas, on peut decouper, et virer tout l'assembleur. C'est plus clair apres. 

Bon, je vais diner et reflechir...

Modifié (le) Mai 3, 2019 par Hobi

[Hobi]

Petite question : Si on lance une impression a partir d'octoprint, et que la machine a plus de filament > Normalement, le deroulement du Gcode s'arrete, exact? 

Et il possible de voir ou la machine s'est arretee dans le fichier du Gcode? J'suis en train de preparer mon prochain scenario avec l'analyseur....

[boleofr]

@Hobi peut-être pas de base mais sinon https://plugins.octoprint.org/plugins/filament_sensor/

[Hobi]

il y a 2 minutes, boleofr a dit :

@Hobi peut-être pas de base mais sinon https://plugins.octoprint.org/plugins/filament_sensor/

Ok. Merci!

[Hobi]

J'ai detourne la prise du filament comme trigger pour l'analyseur, et j'ai printe mon ecrou ducati favori, sans filament, bed à 20 degres, et ma main sur le plateau pour sentir les coups de boutoir dans le plateau, et j'ai trigge l'analyseur en enlevant le filament à la main... 

Il s'avere que mon temps de reaction est d'environ 4/10eme de secondes. Et j'ai trouve ca : 

Des pulses de clock du stepper Y espaces de 120µs > 104 mm/s, ( 80 pas/mm) donc V = 1/( 120E-6*80) = 104mm/s > Waveform 1

Puis plus rien, pas de deceleration, pas de pulses pendant ... 16,50ms, soit de quoi placer environ 137 steps, pas loin de 2mm.... Waveform 2

Puis a nouveau des steps espaces de 120µs > waveform 3. 

Pas etonnant que ca soit brutal. On a un Jerk de .... 100!! 

Ca part chez Marlin, car a mon avis, ca ca deconne à pleins tubes. 

@Epsylon3@CacaoTor la on parle plus de 40ns, mais de 16 ms!!!! C'est pas une chimere!

Waveform-1.pdf Waveform-2.pdf Waveform-3.pdf

[boleofr]

@Hobi si je comprends bien, il y aurait des faux positifs dans le capteur de filament ? 

Genre une micro coupure ? Me semble avoir justement vu dans le code une histoire de gestion/filtrage des "rebonds" sur les capteurs 

Modifié (le) Mai 4, 2019 par boleofr

[Epsylon3]

yep, actuellement le défaut c'est 5 lectures de suite sans filament (mais ca va tres tres vite entre les lectures d'apres ce que j'ai vu)

https://github.com/MarlinFirmware/Marlin/pull/13895/files

attention c'est un int8_t donc 127 max...

et vérifiez que vous avez bien la derniere version de Configuration.h avec #define FIL_RUNOUT_INVERTING false

Modifié (le) Mai 4, 2019 par Epsylon3

[Hobi]

Il y a 4 heures, boleofr a dit :

@Hobi si je comprends bien, il y aurait des faux positifs dans le capteur de filament ? 

Genre une micro coupure ? Me semble avoir justement vu dans le code une histoire de gestion/filtrage des "rebonds" sur les capteurs 

Ah non non c est pas du tout ça. J ai utilisé le capteur de filament et branche une sonde d analyseur dessus pour trigger au moment où j’ai senti un “bing” dans le plateau . A ce moment là j ai déclenché l analyseur en retirant le fil! C est degeu mais ne sachant pas ce que je cherchais exactement ..... c est ce que j ai imaginé. Et ça a marché ....

je simulai un print, pas de fil dans l extrudeur et juste un bout de fil dans le capteur qui m à permis de faire un interrupteur pour ma sonde logique 

Modifié (le) Mai 4, 2019 par Hobi

[Hobi]

@boleofr les waveforms montrent simplement que en plein déplacement à environ 100mm par seconde, brutalement , pendant 16ms, les commandes du stepper stepclk y disparaissent. Ceci ne devrait jamais arriver, ou alors le moteur devrait ralentir jusqu au jerk mini , 20mm/s, puis à arrêter pour ensuite ré accélérer ... je vais maintenant faire deux choses:

brancher deux sondes en plus sur x step clk et x dir , et en utilisant le même code , refaire la manip pour voir si au moment du trou sur y, il y a un trou sur x > si oui, une autre tâche que le générateur de pulse prend la main pendant 16ms ( le rafraîchissement de l écran par exemple ) , et du coup, plus de pulses x et y....

si il y a encore des pulses sur x pendant le trou sur y, le bug est dans la generation des pulses... 

deuxieme chose à faire : isoler le bout de gcode qui fait ça...

Modifié (le) Mai 4, 2019 par Hobi

[Epsylon3]

On arrive tj pas a trouver/isoler une série simple de lignes gcodes qui reproduisent le probleme (sans imprimer) ? Ca pourrait aider