Project: Teacup Firmware

HI

COM port is ok. Actually RS232 connection is ok with marlin FW when using same COM port setting.
So I am confused about why RS232 connection fail with TeaCup FW. Marlin FW uses USART0 that is connected to PC by a "USB to RS232" bridge builded in Arduino ATMEGA 2560 board.
Is it possible that TeaCup FW's RS232 setting is different from Marlin used?

Edited 1 time(s). Last edit at 08/16/2016 06:51AM by HugoYu33.

For firmware upload that shouldn't matter. One can upload anything, even a broken firmware. But we do need the messages in this window ... :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi Traumflug

I attach the message of building FW and uploading FW.
I guess that these two messages are what you want to know?

Edited 1 time(s). Last edit at 08/18/2016 05:50AM by HugoYu33.

Quote
HugoYu33
I attach the message of building FW and uploading FW.
I guess that these two messages are what you want to know?

Yepp, that's it. Good news: your upload works perfectly fine.

Pronterface should be able to connect on COM16 at 115200 baud. If it doesn't, turn on Menu -> Settings -> Debug communications. If this still doesn't give hints (ignored or garbled text coming back), I'd try with a generic serial monitor like PuTTY. Simply pressing and releasing Reset on the controller should at least send a 'start' over the serial line.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Windows and pronterface could have problems with COM-port > 10.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

HI All

Many days ago, I have got a trouble of RS232 communication with Pronterface when I use TeaCup FW on PRUSA I3 with RAPMS1.4 and Arduino ATMEGA2560(R3) control driver board. Now printer is workable with TeaCup FW and can use Pronterface to do print action. The fail reason is that RAM of code used is out of size. Just like the compiler message shows below:

ATmega... '168 '328(P) '644(P) '1280
FLASH: 32068 bytes 223.69% 104.39% 50.51% 24.85%
RAM: 10779 bytes 1052.64% 526.32% 263.16% 131.58%
EEPROM: 48 bytes 4.69% 2.34% 2.34% 1.17%

I modify MOVEBUFFER_SIZE from 96 to 64, the RAM size used is changed to 89.78% from 131.58%. Then issue is gone. Compiler message is below:

ATmega... '168 '328(P) '644(P) '1280
FLASH: 32060 bytes 223.63% 104.36% 50.50% 24.85%
RAM: 7355 bytes 718.26% 359.13% 179.57% 89.78%
EEPROM: 48 bytes 4.69% 2.34% 2.34% 1.17%

Why I find the reason? I found that value of global variable is always be kept in a fixed value but not it's initial vale even if no one change it. So I doubt that maybe RAM memory is overlapped by other code. And then I note that the RAM size used value is over 100% in compiler message.

But I found a strange phenomenon. When I power on the printer and connect to Pronterface, stepper motor(X,Y,E axis, not include Z axis) will keep a force, even no print action is applied, just idle. After a while (about 10 Mins) temperature of motor will increase quickly and temperature of A4988 heat sink also become very hot. This situation let me to afraid that A4988 or motor will be burned or damaged.
If I use Off button of Pronterface, printer can quit this situation. So I want to ask why this situation happen. Dose the TeaCup FW not disable the step motor driver when no motor action is applied?
Any suggestion is welcome to me. Thanks!

Edited 1 time(s). Last edit at 09/05/2016 02:54AM by HugoYu33.

Quote
HugoYu33
I modify MOVEBUFFER_SIZE from 96 to 64, the RAM size used is changed to 89.78% from 131.58%. Then issue is gone.

Surprise, surprise, one can't use more than 100% of available RAM.

No, not really a surprise. Unlike desktop PCs, ATmegas can't swap memory out to the hard disk (there is no hard disk), so 100% is the absolute limit. One can't fill 1.5 liters of water into a 1.0 liter bottle either.

One additional thing: these number given by the compiler don't take stack memory into account, so one can't even use 100%. The amount of RAM needed for stacks isn't clearly defined, it depends on the program flow. Sticking below 90% RAM with that compiler number should be safe.

That said, increasing the movement buffer size doesn't make the printer any faster. That's why this is set to just 16 by default. Long movement buffers help only with long series' of extremely short movements (like 0.1mm).

Quote
HugoYu33
When I power on the printer and connect to Pronterface, stepper motor(X,Y,E axis, not include Z axis) will keep a force, even no print action is applied, just idle.

Is it possible these motors go off as soon as you try to move them? Then the Enable signal needs to be inverted.

Quote
HugoYu33
After a while (about 10 Mins) temperature of motor will increase quickly and temperature of A4988 heat sink also become very hot.

Reduce current for your motors. During printing, motors are turned on for several hours, so they have to survive this anyways.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

HI Traumflug

Thanks for your suggestion!
The control signal polarity of step_motor_driver_enable is correct. And the driving current of motor is also just about 1A, that should be not too large. I guess that this hot condition is caused by disable action of step_motor_driver_enable that is not applied in some situations. So I make reference to code of "Z_AUTODISABLE" and add code of step_motor_driver_enable control for X,Y,E axis. Then the hot condition is gone.

I forgot to mention that the hot condition happen when using Repetier_Host to control the printer with TeaCup FW. It has no hot condition when using Pronterface. The reason is that printer will get abnormal action when using Repetier_Host but not when usng Pronterface with TeaCup FW. Beside, printer has no problem when using Repetier_Host with Marlin FW. The setting of Slic3r is the same between Repetier_Host and Pronterface . The abnormal action is :
1. Move to plate edge randomly.
2. Moving speed become very slow and then stop, just seems that printer hang up. Repetier_Host also doesn't send next command in this moment. After a while, communication timeout will happen.

So I have a question that why printer can't work normally when using Repetier_Host to print a object, Printer action is normal when using manual control mode of Repetier_Host to do basic operation.

Edited 1 time(s). Last edit at 09/07/2016 10:53PM by HugoYu33.

Quote
HugoYu33
So I have a question that why printer can't work normally when using Repetier_Host to print a object

Because Repetier behaves weird. If it doesn't work, don't use it.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

repetier doesnt work with teacup... i tried a lot for my core xy but it never worked.. pronterface is perfect .

I changed long time ago from Repetier to Pronterface/Octoprint. I had also some crashes with Marlin. The only thing I'm missing is the temperature record.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Traumflug
One additional thing: these number given by the compiler don't take stack memory into account, so one can't even use 100%. The amount of RAM needed for stacks isn't clearly defined, it depends on the program flow. Sticking below 90% RAM with that compiler number should be safe.

FYI, as part of developing Klipper, I wrote a script to analyze the stack usage of the AVR assembler that gcc produces. It's in the Klipper source code repository (https://github.com/KevinOConnor/klipper) in scripts/checkstack.py .

It can be run on Teacup with: avr-objdump -ldr build/teacup.elf | /path/to/klipper/scripts/checkstack.py | less

Basically, it prints each function along with its minimum stack usage and maximum stack usage after accounting for all functions it calls.

Because Teacup enables interrupts in some irq handlers, it did seem the worst case stack usage could be pretty high (~180 bytes).

-Kevin

Thanks for doing the analysis! Looks like this estimated 10% figure is pretty close to reality. For me, using stack memory isn't a thing to avoid, more a strategy to achieve proper encapsulation.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sorry if this is answered elsewhere, I've been trying to configure my RAMPS board with a RRD smart controller and I don't see where/how I can configure this in either the source or configtool. Can anyone provide me a little help?

Hello, RRD Smart Controller support is still under development in teacup. There is a branch I created a while ago and I'm working on it a bit at a time, I'm sorry I'm slow at it, college takes my time away.

Quote
youssefaly97
Hello, RRD Smart Controller support is still under development in teacup. There is a branch I created a while ago and I'm working on it a bit at a time, I'm sorry I'm slow at it, college takes my time away.

Good to hear that support is a work in progress, I hope you manage to complete your work some time soon, or perhaps someone more experienced than I is able to help you finish.

Hello,

since 3 days im trying to compile the Firmware for the Gen7-ARM Board. But I have the same issue on 3 different Systems (Ubuntu Mate on BananaPi, Debian on VM, Ubuntu on VM).

Every make command on those Machines gives me this Error:

rootbox@BananaPi:~/Desktop/Teacup_Firmware-master$ make
CC build/mendel.o
/home/rootbox/Desktop/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: 1: /home/rootbox/Desktop/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
Makefile-common:88: recipe for target 'build/mendel.o' failed
make: *** [build/mendel.o] Error 2
I've tried several ways of putting folders somewhere, change access policies, ande some else. No luck since now.

Its a bit frustrating.

Also Configtool gives me errors on Mate and Debian when trying to save the config.h. Is it right that there are just the includes of the board.h and printer.h inside the config.h? Maybe thats the Problem?

Another Problem on Debian: There's an error when starting configtool.py, but it starts. But when opening the calculators for the steppers, there's no close button for them. Not a problem for me, since it works on Ubuntu.

Can someone PLEASE help me to get this working? It would be better to have the ability to compile it by myself due to testing adjustments and making addons for SPI things.

Here's the Github issue Thread: [github.com]


PLEASE HELP ME

Hi All,

I just tried Teacup's experimental branch. Particularly wanted to try the LOOKAHEAD where STEPS_PER_M of X different dan that of Y because my printer has slight different steps/mm for X and Y (X>Y). The result is:


The print is 'beautifully' skewed left-right along X axis.
I am not sure what had happened. My observations during printing:
- occasionally head slowing down/crawling during infill print of a segment
- momentarily pause between later change, not always
- got message: 'notice: lookahead not fast enough' (something like that)

My printer is P3Steel with RAMPS-1.4, setup with this:
- step/mm: X: 168000, Y: 161370
- accel: 1000
- XY Jerk: 200

The object printed in PLA at 45 mm/s. Travel 150 mm/s

For comparison, I also printed the same gcode usiing Teacup's master branch and come up nicely. I particularly love the 150 mm/s travel, overall the motors sound smooth and quiet. On Marlin I occasionally missed steps at 150 mm/s.

Nothing changed in the config except X & Y step/mm the same: 161370

Can you send me your config files and gcode. I would like to test it.
First thing I've seen. You enabled debug. This could slow down the code. For normal use, you should disable debug in debug.h. Just comment out #define DEBUG.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Can you send me your config files and gcode. I would like to test it.
First thing I've seen. You enabled debug. This could slow down the code. For normal use, you should disable debug in debug.h. Just comment out #define DEBUG.

Yes, debug enabled in the experimental. Does it still have an impact when debug level set to zero (M111 S0) ?
The gcode is big, even when compressed still can't be attached here. Let me know your email please.

Yes, there are some tests for the gcode. So it will impact.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

OK, just checked your config.

An Atmega can handle up to approx. 35k to 40k steps/s. Your E-Axis has 1,1540,000 steps/m. Your setup in S3D is 1,800 mm/min. This are 34,620 steps/s. Maybe too close on the limit. Also you could reduce max feedrate for E from 6000, which is too high, to a save 1500.

The old code uses the X-axis for a lot of calculations. This changed in the experiemental, and this could be the reason for your problem,

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
OK, just checked your config.

An Atmega can handle up to approx. 35k to 40k steps/s. Your E-Axis has 1,1540,000 steps/m. Your setup in S3D is 1,800 mm/min. This are 34,620 steps/s. Maybe too close on the limit. Also you could reduce max feedrate for E from 6000, which is too high, to a save 1500.

The old code uses the X-axis for a lot of calculations. This changed in the experiemental, and this could be the reason for your problem,

I tried again. Now changed the E steps to be 577000 (half of before). Also removed debug, Good thing is no more crawling nor notice of lookahead not fast enough. But still, the print skewed along X. I then flipped the STEPS/MM for X to be Y and the other way, expecting the skew would be along Y Axis. But turnout still it skewed toward X.

On Master branch, I got good result, even travel speed increase to 180 mm/s, my fastest so far .

First of all, thanks for helping to improve Teacup.

In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.

As you are working with git. Can you please create a new local branch with

git checkout -b zungmann_1 experimental~37

and test your code again?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
First of all, thanks for helping to improve Teacup.

In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.

As you are working with git. Can you please create a new local branch with

git checkout -b zungmann_1 experimental~37

and test your code again?

Ah stupid me. Anyway I got decent 150 mm/s since now changed it to 9000.
Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.

Btw, how do I know what is the diff this experimental~37 from just experimental before?
Thanks.

Quote
zungmann
Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.

Btw, how do I know what is the diff this experimental~37 from just experimental before?

There are some ways to do it.
via command line:

git diff experimental experimental~37

via gitk:

git checkout experimental
gitk &
git checkout experimental~37

Hit F5, not shift-F5. Yellow circle is your current position. Everything above is new code, currently not active.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
zungmann

Quote
Wurstnase
First of all, thanks for helping to improve Teacup.

In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.

As you are working with git. Can you please create a new local branch with

git checkout -b zungmann_1 experimental~37

and test your code again?

Ah stupid me. Anyway I got decent 150 mm/s since now changed it to 9000.
Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.

Finish. And now printed perfectly. Thank you.

Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?

No problem, I will be happy to test again. I like Teacup.

Quote
zungmann

Quote
Wurstnase
Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?

No problem, I will be happy to test again. I like Teacup.

I tested the dda_queue_fix branch (https://github.com/Traumflug/Teacup_Firmware/tree/dda_queue_fix) and now give a perfect result.