search

repetier / Repetier-Firmware

Firmware for Arduino based RepRap 3D printer.
812 stars 734 forks source link

Dedicated buttons for Z babystepping? #479

Open frazierjason opened 8 years ago

frazierjason commented 8 years ago

Is it possible to have two dedicated Z babystep buttons on a different pair of inputs besides the UI encoder? This might be a more stable alternative than a seemingly lossy encoder for such a sensitive operation. This solution would also allow me to add Z babystepping to my friend's no-LCD Sanguinololu (that is, if babystepping doesn't require UI to be enabled). How would I accomplish this? I can write C++ and Java no problem, but haven't loaded up the solution in proper IDE or trolled through the code just yet.

I thought I filed a ticket for the babystepping issue written up below, but can't seem to find it. I'm guessing there is no easy fix for mechanical encoder detection limitations on a Mega 2560 pushing five steppers and a full LCD. Hence this ticket for dedicated buttons.

I have frequent problems trying to adjust Z babystepping using a mechanical rotary encoder. On my typical RepRapDiscount full graphics LCD, the encoder steps are misread which causes the extruder to jump up (away from the build plate) rapidly by 0.20 to 0.40mm. This happens whether I rotate the encoder slowly or quickly. Per past suggestions, my encoder is configured to the slowest setting, and the speed dependent encoder options are disabled. It didn't help.

I've seen this problem since early v0.91 through v0.92.8 on two generic Mega 2560 controllers and also a Rumba controller. It seems to happen most intensely when the toolhead is going around an arc or otherwise processing a lot of commands; it seldom happens when the toolhead is stationary or traveling in a straight line. If the Repetier Firmware developers decide to pursue this, I can take a video in a couple weeks of it happening, but it's super easy to repro.

repetier commented 8 years ago

Full graphcis displays have a big disadvantage in that they are incredibly slow to update (0.1s on avr boards). Each encoder change increments and when it gets updated it has accumulated more then one tick so acceleration detection might do a bigger step.

LCD is not needed for buttons to work. Currently babystepping has only encoder events. So you would need to add 2 new actions in ui.h/ui.app for babystep up/down and implement them in okAction. Then you can assign these actions to a separate button.

frazierjason commented 8 years ago

Thanks, I'll look into that in a week or two, and if my changes work out I'll try to submit a pull request. The acceleration detection is not only doing larger steps than actually dialed, is doing impossibly big clockwise steps (on the order of 20 to 40 clicks) when I was actually doing one or two anticlockwise clicks of travel.

-------- Original message --------
From: repetier notifications@github.com
Date: 02/23/2016 16:10 (GMT+08:00)
To: repetier/Repetier-Firmware Repetier-Firmware@noreply.github.com
Cc: frazierjason frazierjason@hotmail.com
Subject: Re: [Repetier-Firmware] Dedicated buttons for Z babystepping? (#479)
Full graphcis displays have a big disadvantage in that they are incredibly slow to update (0.1s on avr boards). Each encoder change increments and when it gets updated it has accumulated more then one tick so acceleration detection might do a bigger step.

LCD is not needed for buttons to work. Currently babystepping has only encoder events. So you would need to add 2 new actions in ui.h/ui.app for babystep up/down and implement them in okAction. Then you can assign these actions to a separate button.

Reply to this email directly or view it on GitHub: https://github.com/repetier/Repetier-Firmware/issues/479#issuecomment-187596042