Project: Teacup Firmware

I print another object and got another issue: layer shift on X. I thought it was due to insufficient motor current, so adjusted the driver trimpot a bit higher. But my second print also got the same shift at the same layer. I printed with klipper and successful.
Picture attached:


Could be this similar issue or another one in the dda_queue?

Hello Everyone here

I'm from Poland and... just finished reading of 61 pages Teacup history (took me 3 weeks). Long project, enough long to influence not only reprap history but as well those who engage their lives and passion
I hope that some passion still left to support amateurs like me to allow us delight a Teacup of speed.

One reason which pushed me here is new design of printer I managed to finish last Christmas, which is from very beginning optimised to allow high speed moves and survive rapid direction change without loosing steps.
After several attempts to apply Teacup to my Core XY concept, I'm in the state when axis can travel as fast as 250mm/s (real measurement on distance 4x300mm is 6,34s with is equal to average ~189 mm/s).
It's looks like I can go from current feedrate 15k to 16k but need to increase voltage. Anyway above 16k there is a limit of processing power of my Mega 2560, since about second after aggressive start printer is starting to move very slowly and producing repeatable noise from motors. So I stay with secure 15k.

There are anyhow several issues in front of me.
1. Z axis movement is dramatically slow it's move about 2,15 mm / MINUTE !
- standard impulse rate is 6720 imp/mm (x16 microstep; 200 step engine; gear 2,1:1; treat fi10x2mm)
- entered value in Configtool is 6720000, max feedrate 800, search feedrate 100
- movement is very precise G1 Z10 F800, gives me (apart of training of patience) exactly 10 mm move

2. Somehow printer is not waiting for extruder temp. and attempting to print on not fully preheated hotend

3. PWM for cooler seems not switch of on M107. (M107 is not recognised, so I'm using M106 S0)

4. I used to use Full Graphic Smart Controller to run prints directly from SD card and at the same time made printer independent from computer, having in mind number of sales of such devices in recent two years (mainly produced in China) we can assume it's starting to be cheap standard as for 40 EUR You get full set Mega2560+Ramps1.4+FullGraphicContoller+5xStepper+6xEndStop and sometimes even heatbed.
I started to dig deeper in details what would be necessary to start with
- Display is ST7920 connected by SPI interface and supported by u8glib library.
- Mega2560 is using following pins to communicate pin 23 = CSK ; pin 17 = MOSI; pin 16 = CS
- Line in u8glib.h to be uncommented is "U8GLIB_ST7920_128X64_1X u8g(23, 17, 16); // SPI Com: SCK = en = 23, MOSI = rw = 17, CS = di = 16"
Text menu with temps; homeing commands; g-code select from SD card will cover 90% of things most frequent used on such controllers

After this findings I realised that many of this things is/was already under development by You. Anyhow I was unable to make it run.

Zungmann,

Would be good to check temperatures of steppers and motors, since they can get overheated after longer print run and not exactly stop printing but get lost some steps, especially during fast infill moves or collisions with warped material. At least I had such similar issues some half year ago, using Slic3r and honey-cumb infill.

Hi Numericas,

That is one possibility, yet to be tested and few others I need to test.

Regarding your issue, I can only comment on #2 :
You need to use M116 after heating the temp with M104.
That will wait for temp to achieve. But It does not work when coming move is homing. Not sure if that is by designed or a problem.

Correct, M107 is not recognized, so M106 S0 shall work.

Quick questions. I want to modify the thermistortable.h manually with value input from a thermocouple. I expected the table to have only 2 columns, meaning the adc value and related temperature. However it seems it has adc value, temperature*4, and another 3rd column. What is the 3rd column about? What for? And how do i compute its values. Cheers.

It's a precomputed slope.

But you can simply make a table only with 2 columns. This will also work. The firmware automatically detect the width.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
NoobMan
I want to modify the thermistortable.h manually with value input from a thermocouple.

Why manually? One can calibrate sensors using the Steinhart-Hart algorithm, which basically means to give three temperature/reading pairs. Certainly easier than calculating 20 such pairs. And also adds the third value, which speeds up temperature calculation at runtime.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I am aware its just about a repetitive measurement point and not about an accurate one. But still i like to do things manually and get them as accurate as possible. I find it easier to just do this manually and imo this gives best results. Everybody has their ways, and this is my way

What i do, is for a certain table row, lets say it has a temp of 143 degrees, i give the order to heat at that 143 temperature only as a trick for the system to reach that row's adc value point. Then change value to the real thermocouple reading at next update. It is enough to do it for 4-5-6 values in intervals of interest 160-250 degrees, but can be done for more. This way the system will have the most accuracy because it was calibrated against a termocouple, and it will show what the termocouple used to show. For this method, the system could be a black box, does not matter what thermistor type which pullup value, etc, it is fairly trouble free, so i like this manual method for its accuracy and simplicity.

Quote
NoobMan
Quick questions. I want to modify the thermistortable.h manually with value input from a thermocouple. I expected the table to have only 2 columns, meaning the adc value and related temperature. However it seems it has adc value, temperature*4, and another 3rd column. What is the 3rd column about? What for? And how do i compute its values. Cheers.

The third column was added a year ago. Originally the code retained support for either 2-column or 3-column thermistor tables, but this was later removed to reduce complexity, iirc.

The third column represents the slope between the current row and the previous row. Having the slope pre-calculated saves us from performing a division during temperature sampling. The slope is calculated between the ADC and the temperature values and then it is shifted 10 bits left to represent fractional values as a fixed-point 6.10 value. For example, the samples in testcases/thermistortable.regtest.h have these values at the start of the range:

    {  22,  1995,     0}, //  498 C,     22 ohms, 0.107 V, 0.53 mW, m =  0.000
    {  26,  1898,  6177}, //  474 C,     26 ohms, 0.127 V, 0.62 mW, m =  6.033
    {  30,  1820,  5012}, //  455 C,     30 ohms, 0.146 V, 0.71 mW, m =  4.895
    {  35,  1740,  4109}, //  435 C,     35 ohms, 0.171 V, 0.83 mW, m =  4.013
    {  40,  1673,  3397}, //  418 C,     41 ohms, 0.195 V, 0.94 mW, m =  3.318

The comments in each row decode the source values used to calculate the row to help keep developers sane. The first column is ohms, second column is temperature * 4 in Celcius, and the third column is the slope of DEGREES/OHM (C/R) from the previous row.

The first row has no preceding row, so it's slope is ignored (zero). Let's consider the 2nd row:
R0=22, T0=1995 (498.75*4)
R1=26, T1=1898 (474.5*4)

The slope is calculated as follows: (T0-T1)/(R1-R0)/4 = (498.75-474.5)/(26-22) = 6.0625 (close to 6.033)

Notice the slope's sign is inverted here. That's an implementation detail that sneaked into the table.

There is some precision loss in the numbers shown in the comments because of floating point not represented there, or I may be misrepresenting the math somehow. But this is close enough for this discussion.

There is another advantage to the algorithm used in ConfigTool, and that is that it uses iterative curve-fitting to find the best sample points to fit the curve best.

commit 2291642456ec2c91ca683106e6aeced15f636e0e
Author: Phil Hord 
Date:   Thu Apr 14 15:20:41 2016

    Expand thermistortable to include precomputed slope
    
    Save a division at runtime by pre-calculating the slope between each
    pair of adjacent thermistortable values.  Since we use the larger value
    each time, save the slope between two values A and B in the table
    with the B data.  Therefore the slope is that between each value and
    its predecessor in the list.
    
    Store this new value in the third element of the now 3-integers-wide
    array which makes up the table. Use fixed-point 6.10 format to store
    the slope.  This is almost too narrow for some slopes and maybe it
    should be changed to 8.8 fixed-point. In practice this presents a
    loss in accuracy, but it is still significantly better than the
    previous fixed-sample-size table production method. In particular no
    provision is made to handle values which scale over 65535, and it
    seems we should at least warn about this if not simply fail before
    letting the user go off compiling his code.
    
    Add a new flag TEMPTABLE_FORMAT and define it as 1 to tell the code
    that we are using this new and incompatible format.  This lets us
    tolerate old hand-crafted thermistor tables by keeping the slower
    algorithm in case one is still used.  New thermistor tables should be
    defined with this new format and with the FORMAT define set accordingly.
    
    With the default 25 samples this adds 100 bytes to the flash image for
    the thermistortable storage for two different thermistors.  But the
    code is simplified and saves me 134 bytes in the bargain for a net
    decrease in flash size of 34 bytes.

The discussion around the table changes and curve fitting can be found here: [github.com]

Thank you very much for clarifications Cheers

Hello, I am new on this forum, and also new to the teacup firmware.
I am not quite sure of where I should post this, please feel free to redirect me if this is not the right place.

I am currently adapting the teacup firmware for it to work on a custom polar 3D printer (not yet built, there is only a very crude prototype so far). I have implemented fix point algorithm for angle computation, so that so far, the printhead moves where it should, only not in straight lines. Would there be by any chance some documentation on the bresenham algorithm implemented in the dda.c ? I have read it over and over, but I am not sure of how it perform.
I don't have that much experience in this domain, but I am motivated enough to not let down the project I have.

Thank you for your help,

To change direction using Bresenham simply change the number of steps each axis should do. In the middle of a movement this number doesn't have to match the number of steps actually required for the complete movement. A larger number of steps speeds up this axis, reducing the number reduces velocity. Maximum speed is achieved with steps per axis matching the total number of steps.

That said, forget about doing this in dda_step(), which means for every single step. Sine/cosine are simply too slow to allow this. Unless you have some speedy ARM Cortex-M3, perhaps. The right place is to do this in dda_clock(), which is executed every 2 milliseconds.

The more often used strategy is to split paths into very short segments. Can be done in firmware, see the code coming with branch arc-support. Looking at the commits shows where to tweak the firmware. Another approach is to make the slicer to output short segments only, removing this task from the firmware, raising achievable speeds.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Spiritus
I am currently adapting the teacup firmware for it to work on a custom polar 3D printer (not yet built, there is only a very crude prototype so far). I have implemented fix point algorithm for angle computation, so that so far, the printhead moves where it should, only not in straight lines. Would there be by any chance some documentation on the bresenham algorithm implemented in the dda.c ? I have read it over and over, but I am not sure of how it perform.

[en.wikipedia.org]

This is an interesting problem. Traumflug is right about needing to perform any transcendental functions (csc, etc) in the clock function. But you may be able to use a lookup table with linear approximations of the intermediate values if this turns out to be too slow.

Bresenham is not the right algorithm to use here if you are considering your two motion/stepped axes to be {θ} and {Radius}; to draw a straight line in polar coordinates requires a nonlinear relationship between θ and Radius and this is unsupported in Bresenham.

I feel like there is a simplification you could make to do this step-wise, too, but it is only a hunch.

Hello, and thank you for your answers.

Here is a lookup on what I have been doing recently. I have taken into account what you both said and I chose to go for the "slicing" option, with the help of the arc support code, because my level at this point does not allow me to dig too far into the code, so the step-wise approach is a bit too difficult for me now. Each move is sliced so that each sub-move has its length under a certain value.
I burnt one of my A4988 drivers, so I implemented a small code on processing that helps me visualize whats going on.
Here is an example of a G1 move with (blue) and without (red) slicing it. So far so good.



Doing this does a lot of small moves, and I don't really know the influence it will have in a real situation. For now, I will try to adapt the look-ahead functionality, which is mandatory if each G1 is sliced in multiples smalls moves.

i didnt notice this thread before i post a new thread.... Teacup Problems-issues

here is what i have written there (also i attached some pictures from my configurations)



Hi
i am running as small 3d printer i made with Teacup Firmware Branch-Master
I tried to use my 3d printer with Repetier-Host but had a lot of issues so i am testing it with Pronterface that works ok


With pronterface

i have some issues

1) some times for no reason it looses steps

Arduino uno R3 Board
CNC shield V3
A4988 stepper Drivers
28BYJ-48 5v stepper motors
Baud rate : 115200

my settings are slow enough because of these small motors

* Accelaration Type :Ramping
* Acceleration : 200
without LookAhead as i had to have different stepps for X and Y axes and LookAhead doesnt support that yet

* Maximum Jerk : 5
* Movebuffer size : 8

* Maximum Feedrate x,y : 1000
* Absolute E Coordinates


2) Heater problem

my settings for Hotend Heater (i dont have heated bed) are

* Fast pwm
* Heater Sanity check
* Report target temparatures
* Temperature History Size : 8
* Pid Scallin Factor : 1024L
* Temperature Hysteresis : 10
* Temperature Residency time : 60
* Temperature EWMA : 1000
------------------------------------------------------------

Before start printing the gcode file.. and with the printer connected to the pronterface i can read temperatures from thermistor

when i press to print and the Gcode sends commant to start heating element.... it start heating but the temperature reading freeze.. so i am reaching higher temperatures than the target temp
That only if i select to print. If i just set a temperature manualy from pronterface control panel and select to heat.. then everything work fine.. the element start heating and receiving all the time the temperature from thermistor.. and when it reach target temp switch off mosfet that controls the heater

also i notice that if i havent select the '' Heater Sanity check'' then the heater overcomes the target temp as it is switched on all the time but with '' Heater Sanity check'' the mosfet witching on and off and so heating is more controlled

notice that i have setup configuration pins of my Arduino that the pin for heater be the DI010 that supports PWM signals
I have tried and the default Analog pin for controling the mosfet for the heater but didnt have good results in controling the temperature ... the mosfet was staying on longer


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




Ok i find what make freeze the temperature reading

is the M116 command in Gcode (M116 ; wait for temperature to be reached )

But why and what can be done to fix that ? for now i have disable this command just to make printer continue printing for test proposes (without filament.. just to watch stepper movements )


Also i noticed that i am loosing stepps in motors when in the pronterface preview window of ''current layer movement'' freeze for a while before loads the next layer...
when doing that the printer stops until has the new layer on but then it prints out of the original coordinates that the previous layers were

i am not using an sd card... only from pc (linux - ubuntu 16.04)

what settings have i wrong ?

Hi, i need the Old Version from Teacup, wehre i can find this? The new Version dont work with Home X and Y. The Old Version has a non-Python config.

Quote
Dj EKI
Hi, i need the Old Version from Teacup, wehre i can find this?

It's a Git repository, so you can get every version which ever existed. In case you're not comfortable with cloning the repo, go here [github.com] , there you can walk back commit by commit. The rightmost button gives you a view of the repo at that time and also a download button.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hello!
Why in a teacup can not include the lookahead and use different steps/mm for the X and Y axes? Are there plans to fix this?

Quote
pamalofeev
Are there plans to fix this?

The plan is to accept your contribution fixing this.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY