QuoterollingdiceThere is some "overshoot" when the carriages are moving upward, despite defining endstop clearance variables to a lower value.

This is by design. Teacup doesn't try to break laws of physics and decelerates properly after an endstop hit. After doing so it should move back slowly for high accuracy. This "overshoot" can be controlled by ENDSTOP_CLEARANCE_{XYZ} in the printer configuration. The larger, the better (faster homing movements). Higher acceleration also means higher homing velocities.

Maybe, because on any move it enable and disable the z-motor. Any other motor is on by default.
That is one thing i would change. My z-axis is too heavy for the spindle and will move downwards while motor is disabled.

QuoterollingdiceThere is some "overshoot" when the carriages are moving upward, despite defining endstop clearance variables to a lower value.

This is by design. Teacup doesn't try to break laws of physics and decelerates properly after an endstop hit. After doing so it should move back slowly for high accuracy. This "overshoot" can be controlled by ENDSTOP_CLEARANCE_{XYZ} in the printer configuration. The larger, the better (faster homing movements). Higher acceleration also means higher homing velocities.

Alright, I think I'm gonna lower the clearance more. Current value is 100, going to try 25 or less.
Edit: I also got rippling on my print result, especially on curved surface. There is stuttering when the effector moves with curved path. Any idea on how to solve this?

QuoterollingdiceAlright, I think I'm gonna lower the clearance more. Current value is 100, going to try 25 or less.

That's in micrometers, so 100 is just 0.1 mm. Even to touch-probe metal surfaces with a milling bit I can use 100 without leaving a scratch. Microswitches without lever should allow 500, ones with lever a lot more.

No idea on the stuttering. Tests to find the cause could include to move very slowly to make sure processing speed isn't exhausted.

I got somewhat distracted by real lifetm on my task to fix my cupcake. I fixed the heater initialization bug with the mainboard/extruder, though that code is not in releasable form.

Still, I have some patches that can be used right now:

- negativ floats regex: the regex only allowed for positive floats, which prevents printers with an origin on the center of the build envelope to use the full space
fix: allow negative floats

- EWMA range fix: found while looking for places that use the float regex; the EWMA tooltip says the valid range is 0.001 - 1.0, the code only allows 0.1 - 1.0
fix: allow the full range 0.001 - 1.0

-tx/rx enable: a fix for the fix for issue 179; reading the tx/rx enable pins in for the mainboard/extruder coms was fixed, printing them out uncommented did not work -> saving such aconfig was broken
fix: allow writing tx/rx enable lines out

-psu always on: probably the most useful/interesting patch; I added a checkbox to the board/pinout page to keep the power supply turned on. I therefore added a flag PS_ALWAYS_ON. When checked the power_off() function will not turn off the power supply. It will still disable the stepper motors though. I have therefore not touched the timeout counters and access. My assumption here is that it is ok if the power_on() function rewrites the ps pin value and does not cause a intermediate drop.

Oh, I thought it only applies when ramping acceleration is selected.
Even so, changing that value still did not smooth out manual move (it was still too jerky). The only thing I noticed was slower homing.

I'm building a 3d printer with build platform moving in Z axis and printhead moving in X and Y. Something similar to ultimaker. I'm almost finshed but I have a problem with Z homing. I have single endstop at Z max (build platform at the bottom) but no endstop at Z min. How can I home Z in such setup? I would expect Z homing to move Z to max (down) and then move the platform up by constant hardcoded/configured/sent_by_host so it ends up just below the nozzle. Does Teacup support such setup at all? Thanks in advance for any advice.

QuotewsowaI would expect Z homing to move Z to max (down) and then move the platform up by constant hardcoded/configured/sent_by_host so it ends up just below the nozzle. Does Teacup support such setup at all?

Yes, such a setup is supported. Define a Z Max endstop instead of a Z Min endstop (not both) and set Z_MAX to the height of your build envelope.

i just finished my core xy and tried to use teacup with it.. i got it uploaded and jogged the axis and extruder , everything worked fine. Then i tried a print. the print start at center of the plate , first layer perfect, the next layer is printed shifted both in x and y by 50mm , and the next is also shifted , and finally the head crashed the printer frame...

I just clone the git master branch and am struggling to find out the Display configuration like shown above. Also, I got this error when building with ACCEL REPRAP:

"/Applications/Arduino-1.0.5.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-gcc" -c -DF_CPU=16000000UL -mmcu=atmega2560 -Wall -Wstrict-prototypes -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Winline -fno-move-loop-invariants -fno-tree-scev-cprop -Os -ffunction-sections -finline-functions-called-once -mcall-prologues -Wa,-adhlns="/Developments/Teacup_Firmware/build/dda.al" -save-temps -o "/Developments/Teacup_Firmware/build/dda.o" "/Developments/Teacup_Firmware/dda.c"
/Developments/Teacup_Firmware/dda.c: In function 'dda_create':
/Developments/Teacup_Firmware/dda.c:378: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:384: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:390: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:394: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c: In function 'dda_step':
/Developments/Teacup_Firmware/dda.c:599: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:600: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:603: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:608: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:609: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c:612: error: 'DDA' has no member named 'n'
/Developments/Teacup_Firmware/dda.c: In function 'dda_clock':
/Developments/Teacup_Firmware/dda.c:766: warning: unused variable 'current_id'
RC = 1 - Build terminated
Build terminated abnormally.

I have to modify the dda. add this int32_t n; under #ifdef ACCELERATION_REPRAP on line 122 to make this work. It looks like this dda->n also calculated under ACCELERATION_REPRAP

That said, ACCELERATION_REPRAP is rarely used, because it requires a different slicer, so you might run into additional issues. The only slicers supporting this kind of G-code I'm aware of is RepRap Host [www.reprap.org] of 2009 and maybe Skeinforge of similar vintage. If you get this working, all the better!

Hello ,,i made some tests and i notice that steps per meter for x and y are not right. So i made some tests and found that steps per meter are different for x and y axis. So, when i build i receive the error
#error "Look-ahead requires steps per m to be identical on the X and Y axis (for now)"

i try temporal acceleration but it is like choosing none acceleration ,there is too much stress on the printer. With ramping was working very good, how can i fix it

Search feedrates for the long movement are calculated automatically, no need to set it. The faster acceleration and the larger the endstop clearance is, the faster homing will happen. Still limited to maximum feedrate of each axis, of course.

The search feedrate one can set is for this short movement after the endstop hit, when it moves slowly back out of the endstop to do a precision measurement.

Regarding this refusal to compile with different steps/m for X and Y: if these values are similar, simply remove this test. It's line 21 in dda_lookahead.h. Looks like this other branch needs some additional testing.

Hi,
I have built a 3D printer that is model of PRUSA I3 with RAPMS1.4 and Arduino ATMEGA2560(R3) control driver board. It is workable with Marlin FW perfectly.
Now I want to use TeaCup FW on it. But I got trouble in connection with Pronterface printing control AP. It seems that RS232 connection fail between PC and ATMEGA2560.

I follow the installation guild web page "http://reprap.org/wiki/Teacup_Firmware". Get the TeaCup FW from "https://github.com/Traumflug/Teacup_Firmware".
Now I can compiler and upload FW by configtool.py. If I use configtool.py to upload Marlin FW, printer can get connection with Pronterface, but can't with TeaCup FW.

Thanks for your advise, but I have already tried the baud rate setting before, whatever the setting value connection still fail.
If any possible reason relative to the setting that is not included in config tool?

Baud rate of the firmware and baud rate of the bootloader are two different things. For uploading, bootloader baud rate has to be right. AFAIK, most bootloaders use 115200 baud. Bootloader baud rate is set in Menu -> Edit -> Settings -> Upload speed.

If you get timeout errors, changing "AVR programmer" from 'stk500v2' to 'wiring" should help. This additionally toggles the reset pin. Pressing and releasing the reset button shortly before uploading helps, too.

If all this doesn't fit, please copy the messages from the window popping up into here.