Marlin patch activare babystep Z cu 2 butoane

Ideea acestei modificari este sa permita utilizarea a doua butoane care sa ridice sau coboare axa Z, independent de orice altceva, chiar si in timpul printului. Motivul este reglarea la ochi a inaltimii primului strat de plastic. Modificarea a mai fost mentionata aici si aici si pe linukul de la github. In marlin exista aceasta implementare (babystepping) si este utilizata prin meniul lcd.

Modificarea de mai jos vizeaza utilizarea aceleiasi functii (existente), insa fara lcd, ci doar prin 2 pini gpio la care se leaga doua butoane.

Liniile cu (~) sunt deja existente in marlin, nu trebuie facut nimic cu ele, sunt incluse doar ca puncte de referinta. Adaugirile ar fi trebuit sa aibe un semn (+) dar nu au nimica pentru a usura copy-paste. Pt patchul asta nu exista linii cu (-) pt ca se sterge nimic din codul marlin.

Adaugiri in configuration_adv.h:

(~)  #define BABYSTEPPING
(~)  #ifdef BABYSTEPPING
(~)    #define BABYSTEP_XY  //not only z, but also XY in the menu. more clutter, more functions
(~)    #define BABYSTEP_INVERT_Z false  //true for inverse movements in Z
(~)    #define BABYSTEP_Z_MULTIPLICATOR 2 //faster z movements
  
  #define BABYSTP_GPIO_Z /*nbm alternate babystepping Z with 2 GPIO buttons (no lcd, no menu) */
  	#ifdef BABYSTP_GPIO_Z
  	#define BABYSTP_GPIO_ZUP 46 // Babystep pin for up
  	#define BABYSTP_GPIO_ZDN 48 // Babystep pin for down
  	#define BABYSTP_GPIO_NUM 1  // Impact variable, sort of number of steps, default 1
  #endif //BABYSTP_GPIO_Z

  #define BABYSTP_DLYU_FCT 1000  // only applies if babystep() in stepper.cpp is using delayMicroseconds()

(~)    #ifdef COREXY
(~)      #error BABYSTEPPING not implemented for COREXY yet.
(~)    #endif
(~)    #ifdef DELTA
(~)      #ifdef BABYSTEP_XY
(~)        #error BABYSTEPPING only implemented for Z axis on deltabots.
(~)      #endif
(~)    #endif
(~)  #endif

Pinii pe care i-am utilizat eu sunt 46 si 48, dar se pot folosi orice pini liberi in functie de electronica pe care o utilizeaza fiecare. Pinii vor utiliza pullup intern, si valoarea lor va fi citita periodic, vor fi legati la butoane care ii vor scurtcircuita la gnd, iar cand marlin va citi 0v pe pinii respectivi va executa pasi pe axa z, fie in sus fie in jos in functie de care pin va fi la 0v.

Adaugiri in temperature.h:

(~)  #ifdef PIDTEMPBED
(~)   extern float bedKp,bedKi,bedKd;
(~)  #endif

#ifdef BABYSTP_GPIO_Z
   void babystp_gpio_z_setup();
   void babystp_gpio_z_read();
#endif /*BABYSTP_GPIO_Z*/

(~) #ifdef BABYSTEPPING
(~)   extern volatile int babystepsTodo[3];
(~) #endif

Adaugiri in temperature.cpp:

(~) //===========================================================================
(~) //============================= functions ============================
(~) //===========================================================================

#ifdef BABYSTP_GPIO_Z
void babystp_gpio_z_setup() /*nbm actual pin setup*/
	{
	SET_INPUT(BABYSTP_GPIO_ZUP); /*maybe simpler with pinmode etc, instead fastio*/
	WRITE(BABYSTP_GPIO_ZUP,1);
	SET_INPUT(BABYSTP_GPIO_ZDN); 
	WRITE(BABYSTP_GPIO_ZDN,1);
	}

void babystp_gpio_z_read() /*nbm pin reading changing the babystepsTodo*/
	{
	if      ((READ(BABYSTP_GPIO_ZUP))==LOW) /*prioritize up and ignore case with both*/
		{    babystepsTodo[Z_AXIS]+=BABYSTP_GPIO_NUM; }
	else if ((READ(BABYSTP_GPIO_ZDN))==LOW)
		{    babystepsTodo[Z_AXIS]+=BABYSTP_GPIO_NUM*(-1); } /*double check whats up and down*/
	}
#endif /*BABYSTP_GPIO_Z*/

(~)  void PID_autotune(float temp, int extruder, int ncycles)
(~)  {

Adaugiri in Marlin_main.cpp:

(~)  void setup()
(~)  {

#ifdef BABYSTP_GPIO_Z 
  babystp_gpio_z_setup(); /*nbm call for _setup() from marlin_main void setup(){at the start...} */
#endif /*BABYSTP_GPIO_Z*/

(~)    setup_killpin();
(~)    setup_powerhold();

Adaugiri tot in temperature.cpp, incluziune pt functia care citeste pinii in interiorul isr:

(~)         target_temperature_bed = 0;
(~)         bed_max_temp_error();
(~)      }
(~)  #endif
(~)    }

#ifdef BABYSTP_GPIO_Z  
  babystp_gpio_z_read(); /*nbm call for read() for babystepsTodo update*/
#endif /*BABYSTP_GPIO_Z*/

(~)  #ifdef BABYSTEPPING
(~)    for(uint8_t axis=0;axis<3;axis++)
(~)    {
(~)     int curTodo=babystepsTodo[axis]; //get rid of volatile for performance

In legatura cu ultima parte, functia babystp_gpio_z_read() poate fi apelata si din alte parti pentru a schimba variabila babystepsTodo. Daca este chemata din alte parti, copiaza caracteristicile functiei in care in care este inclusa cat de des e apelata aceea, etc. De exemplu se poate adauga si la sfarsitul functiei "static void updateTemperaturesFromRawValues()", si se poate testa si incadrarea in alte functii. Probabil nu e recomandabila incluziunea in functii care citesc pinii analogi de la thermistori pentru ca sa nu se afecteze reciproc citirile si zgomotele de la comparatorii adc.

Dupa ce se compileaza si se face upload cu modificarile de mai sus, cu un multimetru se poate verifica daca pinii definiti pentru Zup si Zdown au 5v (adica au pullup activ). Si se poate lua un fir si scurtcircuita pinii respectivi la gnd, moment in care axa z ar trebui sa se miste pe directia respectiva. Apoi daca totul este ok, se pot monta doua butoane pentru utilizare practica. Bafta!

Edited 5 time(s). Last edit at 04/25/2014 09:35AM by NoobMan.

neneee...nici n-am citit mai mult de doua randuri si pot spune (ca-n bancul cu fiul lu' Bula): "Da vreau! da vreau!..."

Tocmai se intampla ca cea mai mare nemultumire a mea referitoare propria-mi creatura este..inconsistenta pe Z.
O fi din cauza ca mi se misca suportul cu magnetul, o fi din cauza ca misc putin patul atunci cand scot piesele...sau o fi din cauza ca zeama mea de ABS (pusa pe oglina necuratata) tot creste...nu conteaza cauza.
Cert e ca de multe ori am oprit print-ul pentru ca primele linii sunt fie prea sus si tzopaie fie sunt prea jos si...nu iese nimic pe stutz.

Gata, intai dau copy-paste (sa nu carecumva sa te apuci sa stergi :-) ) si ma apuc de citit !!!

Cred ca Z se modifica atunci cand se incalzeste patul si se dilata/deformeaza putin. La fel si extruderul se incalzeste si se dilata spre pat, pt ca in partea cealalta e prins.

De probat pinii cu scurt la gnd, se poate face proba sau cu un fir, sau cu un resistor de 1k, asta ca sa evitam scurturi facute din greseala in alta parte. Pinul in sine are un resistor pullup mult mai mare decat 1k, asa in utilizare practica e suficient doar un buton de la pinul respectiv la ground.

Acum in afara de modificarea asta, miscarea pe Z la mine era prea rapida pt ca aveam half stepping pe Z. Poate ca pentru cine foloseste microstep 16x pe axa Z s-ar putea sa fie ok asa cum e. Dar oricum, pentru a tuna viteza pe Z se poate modifica in stepper.cpp partea care face pasii pt Z, si se poate introduce intarzieri cu functia delayMicroseconds(). Daca incerci, zi-mi si mie daca viteza pe Z e ok asa cum (default) si ce microstep folosesti, de curiozitate. Altii care au incercat au zis tot asa ca viteza e cam mare.

In caz extrem, cum zicea unul pe github, da impulsurile de step mai repede decat le detecteaza driverul, si pare ca se "balbaie" axa z, sau poate nici nu mai reactioneaza deloc. Atunci e musai de introdus delay, pt a intarzia semnalul pe linia de step.

Edited 2 time(s). Last edit at 04/24/2014 08:48PM by NoobMan.

Pentru a schimba viteza cu care trimite pasii, adaugam o variabila in config_adv in cardrul babystepping pe care o folosim ca valoare pentru delay(): #define BABYSTP_DLYU_FCT 1000 . Am editat postul original si am inclus si linia asta.

Apoi in stepper.cpp exista functia void babystep(const uint8_t axis,const bool direction) care are case X, case Y, si case Z, avem nevoie sa modificam doar case Z, si asta are doua situatii, pentru cartezian sau pentru delta. Exista un mic delay introdus printr-un calcul inutil, si acesta se poate inlocui cu functia delayMicroseconds() care in paranteze sa contina valoarea din config pentru a putea fi modificata usor.

Pentru o schimbare mica, in stepper.cpp, in cadrul functiei babystep, pentru cazul Z (cartesian/delta dupa caz) se poate inlocui linia cu

    //wait a tiny bit
(-)      {
(-)        float x=1./float(axis+1); //absolutely useless
(-)      }

cu

    //wait a tiny bit
      //  {
      //    float x=1./float(axis+1); //absolutely useless
      //  }
    delayMicroseconds(BABYSTP_DLYU_FCT);

sau eventual se poate pastra si calculatia veche si doar adauga delayM...(...) dupa calculul cu float;

La mine merge acceptabil de incet de pe la BABYSTP_DLYU_FCT 1000 si mai sus, inclusiv 10 000. Trebuie testate diverse valori, in functie de regimul de microstep, si de distanta care trebuie sa o parcurga intre pozitia de endstop si bed, si in functie de cat de repede se vrea reglajul pentru primul strat in timp ce face skirt. Viteza la skirt e preferabil sa fie si ea mica.

Edited 1 time(s). Last edit at 04/25/2014 09:13AM by NoobMan.

Alexella, ai incercat, merge?

La naiba, inca n-am incercat nimic.
Si acum incep cu scuzele :-)


1. Printez ( cu dalta, cu ciocanu, cu...multe "curled ends" parti din structura exterioara.
Vreau sa termin o data cu casetatul imprimantei.
Mai am putin si gat.
Mai am...niste suporti-distantieri ai peretilor de policarbonat.
O parte sunt fixati, o parte...sunt la versiunea 3 (tot mai invat cate ceva despre fizica FDM-ului raportata la fortele de solicitare ale pieselor. Este...enervant si frumos in acelasi timp.
Si-mi tot propun sa scriu multe articole si...tot nu mai apuc.
Am mai salvat cate o poza pe ici pe colo..

2. Am schimbat multe cabluri torsadate cu panglici si...am reusit sa inghesui montajul in "interiorul" imprimantei si....mi-a mai luat si asta cateva ore bune.

3. Hm... oare-am dat de dracu?
Am Megatronics si...parca n-as mai reveni la RAMPS.
La Megatronics asta tre' sa ma lamuresc ce "pini" de la ArduinoMEGA am liberi si pe unde.
Pretzu lu' "plug and play" la Megatronics asta e ca n-a lasat prea multi pini afara "for future applications".
Ma gandeam sa-i montez LCD-ul si-un buton ca sa accesez babystepu' din meniu.
Da...n-am cand sa-i montez LCD-ul ca .. mai mereu printez/ sau stric cate ceva :-)


Acu ca am terminat cu scuzele....

Pe Z am un M8 rectificat pe filiera si pus pe o piulita de polietilena.
Unde n-am "backlash" pentru ca forta de frecare intre piulite (si un arc prost pe care l-am gasit) era prea mare pentru motoare :-(
Asa ca am ramas la o piulita...
Si uite asa, a bug become a feature: la mine, daca dau prea jos cu extrudoru-n sticla, nu sparg sticla pentru ca iese piulita din carucior si se invarte in gol :-)
E drept ca tre' sa aliniez din nou axele dar...paguba-i mica.

Am niste...aaa..DRV8852 cu 32microsteps pe motor de 200 asa ca...chiar sper sa am rezolutie suficienta.

Luni poate termin de printat suportii si poate ma indur sa desfac Megatronicsu'
Multzam mult de vorbe si.... Z-ul asta e urmatoarea prioritate.

Arata bine cu policarbonatul, felicitari.
Pe z e ok cu o piulitza normala, nu e nici o chestie pentru ca fortza de gravitatie contracareaza backlash-ul pe z.
Pinii liberi tre sa ii urmaresti din fisierele sursa de la megatronics, pornind de la microcontrollerul atmel, si pana la ce iesiri are placa - sigur tre sa fie ceva. Dar daca ai lcd cred ca e preferabil sa folosesti babystep din lcd. Bafta si spor la treaba!

hello-hello.

Pana sa fac picioare din butoane, am facut "controller"ul extern.
So far so good, tocmai am printat prima saiba direct din imprimanta si controller, dar m-am proptit la babysteps.
Pe scurt, imi apare in meniu (atunci cand printeaza) dar...nu pot sa setez nimic.
N-are cifra care s-o modific si degeaba dau "enter" si invart de buton ca nimica....

Imi arata ca-n poza de mai jos.
Ai idee de ce?

gata, l-am rezolvat si pe asta.
Chiar ca... 1 Mai muncitoresc.
Se fac aproape 12 ore de cand n-am plecat de la clape si letcoane.
Dar.... fost fain :-)


Anyway, rezolvarea aici a fost data de link-ul de mai jos. Se pare ca impulsurile date spre Driver pentru BabySteps erau prea scurte.

https://github.com/ErikZalm/Marlin/issues/861

Inteleg ca ai folosit varianta lui paulsbrand cu tmp-=(PORTB<<1)+PORTB; // useless operation to create tiny delay

Dar de curiozitate, simplu cu delayMicroseconds(1000) nu a mers?

If it's not broken, I...try not to fix it.
N-am incercat da...daca esti tu curios, o sa incerc.

Acu ca l-am imbracat pe Frankie...poate-mi mai fac timp,sa-mi bag nasu in soft.
Plus ca...inca nu mi-am "tunat" stepperele, si se incing motoareleeeee...



Si asta e Frankie


.

Ideea cu delayM..(variabila) este ca schimband variabila poti modifica viteza cu care merge axa, la mine de exemplu pt ca era cu half step imi mergea prea repede, si riscam sa lovesc extruderul de bed, asa ca am preferat sa caut o modalitate sa pot regla viteza, pentru ca variantele de delay cu operatii scurte/inutile nu fac asta. Dar asta e o situatie mai rara, eventual doar pt varianta cu butoane, si deci mai putin utila. Pentru ca daca se foloseste babystep cu encoder nu mai e nevoie de viteza ca variabila, pentru ca deja foloseste o variabila pentru distanta, adica face pasi pe o distanta proportionala cu unghiul la care e pozitia encoderului.

Auzi?
Io...tre sa trag de timp acuma pentru ca a trebui sa desfac Y-ul si sa-l .... refac/ reajustez.
Printa cercurile cam "geoid" si am vazut ca Y e cam slaba si cam....naspa.
Initial, am avut niste motoare cu ax scurt si pentru ca nu ajungea sa montez roata dintata GT2 invers, a trebuit sa inalt rulmentii de intindere pe "picioroange".
Din pacate, toata constructia mi-a great un "backlash" cica se zice...

Asa ca trag de timp cu intrebari:

ce zici tu cu delayM (variabila) are sens si e cu cap. Ce nu inteleg de ce programatorul a preferat (initial) sa bage niste functii care sa frece menta ca sa cauzeze intarzieri? A gandit complicat sau...a avut altceva in cap???

La mine, mi-am calibrat setarile ca trebuie sa dau...aaa...vre-o 3 ture de switch-encoder ca sa miste Z-ul cu 0.1mm. Asa ca m-am declarat multumit. Probabil e din cauza microstepping-ului de 32 pe care il au 8852-urile mele.

Pe de alta parte, am mai tunat ceva ieri: am scazut tensiuile/ curentul la drivere la ... jumatate daca nu mai mult.
Am facut-o dupa ureche pentru ca nu am reusit sa nimeresc punctul de pe PCB cu Vref asa ca le-am acordat ca pe pian si am notat tensiunile masurate pe potentiometru.
Deja...motoarele merg muuult mai rece si mai silentioase.

Axa - Vpot
X - 0,17V
Y - 0,17V
Z - 0,45V
E - 0,27V


Asa ca de-asta trag de timp si-mi cer iertare dar... nici in seara asta nu testez functiile.
Ca nu mai am cand :-(

Pai sunt drivere care au diverse conditii pentru a recunoaste semnalul STEP. Ca semnal digital step este o functie care sare de la 0 la 1 - si atat, nu mai conteaza nimic altceva. Sunt cateva functii fundamentale cu care se poate construi orice alt semnal, functia step e una dintre astea, de exemplu ca un fel de primitiva. Functia care coboara de la 1 la 0 e inversul functiei step, iar daca se inmulteste cu diverse valori se obtine orice amplitudine, etc. Acuma driverul cauta sa filtreze semnalul astfel incat sa se fereasca de paraziti si semnale aiurea, asa ca are conditii, de exemplu la chipurile allegro in general functia step ca sa fie recunoscuta, dupa step trebuie ca semnalul sa mai ramana high inca 1.0 usecunda. La tb6560 la fel tre sa ramana high (adica 1) cam 30uSec - dar se poate modifica la 17uSec, etc. La drv8825 trebuie sa fie 1.9uSec low, si apoi inca alte 1.9uSec high, adica asta are logica de a verifica si ce a fost inainte. Exista alte drivere care in loc sa citeasca step cand creste 0-1 citesc step cand coboara 1-0 (falling edge) adica citesc inversul functiei step. Cred cam fiecare producator are diverse idei, in functie de cum e facut chipul, si in general conditiile astea sunt si in datasheet. Cred ca cel care a introdus delay-urile alea mici avea simplu un chip mai bun, care avea conditii mai mici pentru ca astfel permitea o frecventa de step mai mare, si deci fie o viteza mai mare fie microstepping mai mare. Cred ca a introdus un calcul pentru un delay foarte mic pentru ca asta permite frecventa cat mai mare. La el a mers, asa ca nu si-a batut capul ca sa citeasca ce si cum trebuie la toate chipurile de pe piata, si nu era preocuparea lui asta. Fiecare isi rezolva doar problema lui, si tot asa pe rand pana cand se acopera toate cazurile. Asta ca proces de colaborare pe open source.

Daca vrei sa modifici cat creste sau scade axa in functie de pot, ai doua variante, sau faci pe Z microstep mai mic, gen 16x sau 8x, si asta ar fi chiar bine pt ca pe Z nu e nevoie de microstep semnificativ, asa ca daca iti merge ok pune pe microstep 8x, ca sa miste mai mult mai repede. La mine axa z mereu a avut cel mai mic microstep, din logica asta.

Alta varianta e sa te uiti in ultralcd.cpp sa cauti o functie care se cheama static void lcd_babystep_z() si are in interior babystepsTodo[Z_AXIS]+=BABYSTEP_Z_MULTIPLICATOR*(int)encoderPosition si doar observi ca pozitia encoderului e citita si apoi multiplicata cu variabila _multiplicator. Si atunci faci BABYSTEP_Z_MULTIPLICATOR de 3 ori mai mare (tre sa fie prin config_adv.h), atunci o sa miste 0.1mm doar la o tura de encoder in loc de trei. Adica de aia e acel multiplicator.

Pentru Vref, tre sa citesti datasheetul de la drv8825 daca asta e chipul de stepper pe care il folosesti, si in datasheet gasesti o formula cu Vref, Rsense, si I_limit, iar ce ne intereseaza e ultima, adica valoarea curentului. Ca sa stii ce curent ai tre sa verifici ce rsense e pe placa ta, si apoi completezi formula. Daca intri pe pagina de drivere de la pololu ai sa vezi ca pentru un driver relatia e Current Limit = VREF × 0.61 si pentru alt driver e Current Limit = VREF × 2 Eu nu stiu ce ai, asa ce tre sa verifici tu. Pentru ca ai valori asa de mici probabil ai varianta care zice x2, dar nu situ sigur. Un curent cat de cat ar porni de la 0.4-0.5a pana pe la 0.8-1.0a, cam asta ar fi o zona larga, dar ce si cum tre sa hotarasti tu. Eu in general cand reglez tot asa am in vedere sa fie ceva mai reci motoarele.

Edited 1 time(s). Last edit at 05/07/2014 05:50PM by NoobMan.

mosuleeeee.. I'm back.
Tot n-am implementat faza cu butoanele, ma multumesc sa trag de babystepping din menu.
Dar, vreau mai mult.

In sensul ca implementarea mea (adaptata pe genunchi acum doi ani) e mai "urata" ca cea de pe ultima versiune de Marlin, 1.1.0 si... vreau si eu.
Adica, vreau sa-mi si afiseze pe display cati pasi/ mm se deplaseaza, daca in sus sau in jos.

Deocamdata am facut documentul din attach, comparand cele doua versiuni, incerc sa vad ce mai trebuie sa modific.
De asemenea, vad ca-n Marlin a folosit o functie mai desteapta sa frece menta decat ce comenzi am pus eu..


m-am gandit sa va informez :-)