![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>Project: Teacup Firmware</title> <description>Hi all, over the last few days I've been attempting to re-write the FiveD firmware and wrangle pin allocations enough that I can run my entire wooden mendel from an atmega168-based arduino. At the moment, I've implemented 90% of what I need, it compiles but is otherwise totally untested except for a few personal libraries, and it currently uses [b]40%[/b] of my maximum 16k. I'd prefer it to fit in 14k so I can keep my bootloader. Some of the design limitations I've taken on to do this: * NO floating point- the fp libs alone take [i]over[/i] 2k (12.5%) of the available space. I have implemented my own crude decimal fp, but use it very sparingly* NO C++ - the abstractions are lovely on desktops, but it also creates tons of extras that simply aren't suitable for microcontrollers. A data struct and methods as regular functions provide enough of the same features.* Minimal math in interrupt context - I was horrified to see the FiveD firmware doing significant amounts of floating point math in interrupt context. As a fairly experienced firmware wrangler, I literally cringed. Interrupts should be in and out ASAP, with (relatively) long-running calculations handled in the main loop somewhere. Some features you may want to "borrow" from my code:* I/O pin abstraction: pass eg DIO3 to READ(), WRITE(), SET_INPUT(), SET_OUTPUT() and they'll pull the proper ports and bits from arduino.h* bare beginnings of a similar system for timers* thoroughly tested ringbuffer and serial libraries* 2d and 3d integer distance approximation routines (no fp sqrt!) Notes:* my temp sensor is a MAX6675 on the SPI bus. you'll have to write me a new temp.c for other types ;)* extruder stepper controller is hooked into arduino just like the other axes, so only one serial port needed* I've taken [i]significant[/i] chunks of code from the official FiveD firmware, and totally rewritten equally significant sections. I've attempted to mark things I've copied, but won't guarantee that I got them all [i]Major[/i] reorganisations and horrific bugs are to be expected on a regular basis, but if you want to dive in head-first and see how I'm going, download at http://github.com/triffid/ATmega-Skeleton/tree/master/mendel/ [Edit: Changed name to "Teacup Firmware" for the purposes of not confusing folk, after irc discussion. --Sebastien]</description> <link>https://reprap.org/forum/read.php?147,33082,33082#msg-33082</link> <lastBuildDate>Sat, 11 May 2024 04:29:55 -0400</lastBuildDate> <generator>Phorum 5.2.23</generator> <item> <guid>https://reprap.org/forum/read.php?147,33082,774520#msg-774520</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,774520#msg-774520</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>pamalofeev</strong><br />Are there plans to fix this?</div></blockquote><br />The plan is to accept your contribution fixing this.]]></description> <dc:creator>Traumflug</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Fri, 23 Jun 2017 08:05:48 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,774505#msg-774505</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,774505#msg-774505</link> <description><![CDATA[ Hello!<br />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?]]></description> <dc:creator>pamalofeev</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Fri, 23 Jun 2017 06:24:34 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,771119#msg-771119</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,771119#msg-771119</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Dj EKI</strong><br />Hi, i need the Old Version from Teacup, wehre i can find this?</div></blockquote><br />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 [<a href="https://github.com/Traumflug/Teacup_Firmware/commits/master" target="_blank" rel="nofollow">github.com</a>] , 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.]]></description> <dc:creator>Traumflug</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Wed, 31 May 2017 11:26:42 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,771118#msg-771118</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,771118#msg-771118</link> <description><![CDATA[ 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.]]></description> <dc:creator>Dj EKI</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Wed, 31 May 2017 11:22:34 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,770560#msg-770560</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,770560#msg-770560</link> <description><![CDATA[ i didnt notice this thread before i post a new thread.... <a href="http://forums.reprap.org/read.php?147,770516" target="_blank" rel="nofollow">Teacup Problems-issues</a><br /><br />here is what i have written there (also i attached some pictures from my configurations) <br /><br /><br /><br />Hi<br />i am running as small 3d printer i made with Teacup Firmware Branch-Master<br />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<br /><br /><br />With pronterface <br /><br />i have some issues <br /><br />1) some times for no reason it looses steps <br /><br />Arduino uno R3 Board<br />CNC shield V3<br />A4988 stepper Drivers<br />28BYJ-48 5v stepper motors <br />Baud rate : 115200 <br /><br />my settings are slow enough because of these small motors<br /><br />* Accelaration Type :Ramping<br />* Acceleration : 200<br />without LookAhead as i had to have different stepps for X and Y axes and LookAhead doesnt support that yet <br /><br />* Maximum Jerk : 5<br />* Movebuffer size : 8<br /><br />* Maximum Feedrate x,y : 1000<br />* Absolute E Coordinates <br /><br /><br />2) Heater problem <br /><br />my settings for Hotend Heater (i dont have heated bed) are <br /><br />* Fast pwm<br />* Heater Sanity check<br />* Report target temparatures<br />* Temperature History Size : 8<br />* Pid Scallin Factor : 1024L<br />* Temperature Hysteresis : 10<br />* Temperature Residency time : 60<br />* Temperature EWMA : 1000<br />------------------------------------------------------------<br /><br />Before start printing the gcode file.. and with the printer connected to the pronterface i can read temperatures from thermistor <br /><br />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 <br />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<br /><br />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 <br /><br />notice that i have setup configuration pins of my Arduino that the pin for heater be the DI010 that supports PWM signals <br />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<br /><br /><br />--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br /><br /><br /><br /><br />Ok i find what make freeze the temperature reading<br /><br />is the M116 command in Gcode (M116 ; wait for temperature to be reached )<br /><br />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 )<br /><br /><br />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... <br />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 <br /><br />i am not using an sd card... only from pc (linux - ubuntu 16.04) <br /><br />what settings have i wrong ?]]></description> <dc:creator>caslor</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sat, 27 May 2017 18:43:00 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,756761#msg-756761</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,756761#msg-756761</link> <description><![CDATA[ Hello, and thank you for your answers.<br /><br />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.<br />I burnt one of my A4988 drivers, so I implemented a small code on processing that helps me visualize whats going on.<br />Here is an example of a G1 move with (blue) and without (red) slicing it. So far so good.<br /><br />[attachment 92121 bresenham.PNG]<br /><br />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.]]></description> <dc:creator>Spiritus</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sat, 18 Mar 2017 05:17:06 -0400</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,754584#msg-754584</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,754584#msg-754584</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Spiritus</strong><br />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.</div></blockquote><br />[<a href="https://en.wikipedia.org/wiki/Bresenham's_line_algorithm" target="_blank" rel="nofollow">en.wikipedia.org</a>]<br /><br />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. <br /><br />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.<br /><br />I feel like there is a simplification you could make to do this step-wise, too, but it is only a hunch.]]></description> <dc:creator>phord</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Thu, 09 Mar 2017 13:36:40 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,754547#msg-754547</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,754547#msg-754547</link> <description><![CDATA[ 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.<br /><br />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.<br /><br />The more often used strategy is to split paths into very short segments. Can be done in firmware, see the code coming with branch <i>arc-support</i>. 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.]]></description> <dc:creator>Traumflug</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Thu, 09 Mar 2017 11:40:31 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,754539#msg-754539</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,754539#msg-754539</link> <description><![CDATA[ Hello, I am new on this forum, and also new to the teacup firmware.<br />I am not quite sure of where I should post this, please feel free to redirect me if this is not the right place.<br /><br />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.<br />I don't have that much experience in this domain, but I am motivated enough to not let down the project I have.<br /><br />Thank you for your help,]]></description> <dc:creator>Spiritus</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Thu, 09 Mar 2017 11:04:22 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,749037#msg-749037</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,749037#msg-749037</link> <description><![CDATA[ Thank you very much for clarifications :) Cheers :)]]></description> <dc:creator>NoobMan</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Thu, 16 Feb 2017 00:00:05 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,748962#msg-748962</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,748962#msg-748962</link> <description><![CDATA[ The discussion around the table changes and curve fitting can be found here: [<a href="https://github.com/Traumflug/Teacup_Firmware/pull/208" target="_blank" rel="nofollow">github.com</a>]]]></description> <dc:creator>phord</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Wed, 15 Feb 2017 15:03:00 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,748941#msg-748941</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,748941#msg-748941</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>NoobMan</strong><br />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.</div></blockquote><br />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.<br /><br />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:<br /><br /><pre class="bbcode"> { 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</pre><br /><br />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.<br /><br />The first row has no preceding row, so it's slope is ignored (zero). Let's consider the 2nd row:<br /> R0=22, T0=1995 (498.75*4)<br /> R1=26, T1=1898 (474.5*4)<br /><br />The slope is calculated as follows: (T0-T1)/(R1-R0)/4 = (498.75-474.5)/(26-22) = 6.0625 (close to 6.033)<br /><br />Notice the slope's sign is inverted here. That's an implementation detail that sneaked into the table.<br /><br />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.<br /><br />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. <br /><br /><br /><pre class="bbcode">commit 2291642456ec2c91ca683106e6aeced15f636e0eAuthor: 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.</pre>]]></description> <dc:creator>phord</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Wed, 15 Feb 2017 13:45:38 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,747988#msg-747988</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,747988#msg-747988</link> <description><![CDATA[ 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 :)<br /><br />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.]]></description> <dc:creator>NoobMan</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Mon, 13 Feb 2017 09:53:15 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,747969#msg-747969</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,747969#msg-747969</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>NoobMan</strong><br />I want to modify the thermistortable.h manually with value input from a thermocouple.</div></blockquote><br />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.]]></description> <dc:creator>Traumflug</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Mon, 13 Feb 2017 08:27:41 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,747873#msg-747873</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,747873#msg-747873</link> <description><![CDATA[ It's a precomputed slope. <br /><br />But you can simply make a table only with 2 columns. This will also work. The firmware automatically detect the width.]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Mon, 13 Feb 2017 00:07:28 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,747864#msg-747864</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,747864#msg-747864</link> <description><![CDATA[ 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.]]></description> <dc:creator>NoobMan</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sun, 12 Feb 2017 22:04:07 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,743841#msg-743841</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,743841#msg-743841</link> <description><![CDATA[ Hi Numericas,<br /><br />That is one possibility, yet to be tested and few others I need to test.<br /><br />Regarding your issue, I can only comment on #2 :<br />You need to use M116 after heating the temp with M104.<br />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.<br /><br />Correct, M107 is not recognized, so M106 S0 shall work.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Mon, 30 Jan 2017 21:46:47 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,743085#msg-743085</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,743085#msg-743085</link> <description><![CDATA[ Hello Everyone here :) <br /><br />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 ;) <br />I hope that some passion still left to support amateurs like me to allow us delight a Teacup of speed.<br /><br />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. <br />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).<br />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. <br /><br />There are anyhow several issues in front of me. <br />1. Z axis movement is dramatically slow it's move about 2,15 mm / MINUTE ! <br />- standard impulse rate is 6720 imp/mm (x16 microstep; 200 step engine; gear 2,1:1; treat fi10x2mm)<br />- entered value in Configtool is 6720000, max feedrate 800, search feedrate 100 <br />- movement is very precise G1 Z10 F800, gives me (apart of training of patience) exactly 10 mm move <br /><br />2. Somehow printer is not waiting for extruder temp. and attempting to print on not fully preheated hotend<br /><br />3. PWM for cooler seems not switch of on M107. (M107 is not recognised, so I'm using M106 S0) <br /><br />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. <br />I started to dig deeper in details what would be necessary to start with <br />- Display is ST7920 connected by SPI interface and supported by u8glib library.<br />- Mega2560 is using following pins to communicate pin 23 = CSK ; pin 17 = MOSI; pin 16 = CS<br />- 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" <br />Text menu with temps; homeing commands; g-code select from SD card will cover 90% of things most frequent used on such controllers <br /><br />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.<br /><br />Zungmann, <br /><br />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.]]></description> <dc:creator>Numericas</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sat, 28 Jan 2017 12:29:29 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,737901#msg-737901</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,737901#msg-737901</link> <description><![CDATA[ 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.<br />Picture attached:<br />[attachment 88757 XAxisP4-LS-teacup.jpg]<br /><br />Could be this similar issue or another one in the dda_queue?]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Thu, 12 Jan 2017 01:22:51 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,737563#msg-737563</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,737563#msg-737563</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>zungmann</strong><br /><blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?</div></blockquote><br />No problem, I will be happy to test again. I like Teacup.</div></blockquote><br />I tested the dda_queue_fix branch (https://github.com/Traumflug/Teacup_Firmware/tree/dda_queue_fix) and now give a perfect result.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Wed, 11 Jan 2017 01:34:42 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733275#msg-733275</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733275#msg-733275</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?</div></blockquote><br />No problem, I will be happy to test again. I like Teacup.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 09:55:36 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733237#msg-733237</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733237#msg-733237</link> <description><![CDATA[ Thanks for testing. This is an experimental branch and needs testing. Can I ask you later to test this again?]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 07:47:58 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733211#msg-733211</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733211#msg-733211</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>zungmann</strong><br /><blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />First of all, thanks for helping to improve Teacup.<br /><br />In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.<br /><br />As you are working with git. Can you please create a new local branch with<br /><pre class="bbcode">git checkout -b zungmann_1 experimental~37</pre>and test your code again?</div></blockquote><br />Ah stupid me. Anyway I got decent 150 mm/s since now changed it to 9000.<br />Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.</div></blockquote>Finish. And now printed perfectly. Thank you.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 06:17:07 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733210#msg-733210</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733210#msg-733210</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>zungmann</strong><br />Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.<br /><br />Btw, how do I know what is the diff this experimental~37 from just experimental before?</div></blockquote><br />There are some ways to do it.<br />via command line:<br /><pre class="bbcode">git diff experimental experimental~37</pre>via gitk:<br /><pre class="bbcode">git checkout experimentalgitk &git checkout experimental~37</pre>Hit <b>F5</b>, <u>not</u> shift-F5. Yellow circle is your current position. Everything above is new code, currently not active.]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 05:59:00 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733207#msg-733207</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733207#msg-733207</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />First of all, thanks for helping to improve Teacup.<br /><br />In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.<br /><br />As you are working with git. Can you please create a new local branch with<br /><pre class="bbcode">git checkout -b zungmann_1 experimental~37</pre>and test your code again?</div></blockquote><br />Ah stupid me. Anyway I got decent 150 mm/s since now changed it to 9000.<br />Yes, I am using git. I testing it now, still printing halfway and promising, so far so good.<br /><br />Btw, how do I know what is the diff this experimental~37 from just experimental before?<br />Thanks.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 05:45:26 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733175#msg-733175</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733175#msg-733175</link> <description><![CDATA[ First of all, thanks for helping to improve Teacup.<br /><br />In your config files you set the maximum feedrate to 6000. So your 180mm/s will decrease to 100mm/s any time.<br /><br />As you are working with git. Can you please create a new local branch with<br /><pre class="bbcode">git checkout -b zungmann_1 experimental~37</pre>and test your code again?]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 03:47:15 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,733159#msg-733159</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,733159#msg-733159</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />OK, just checked your config.<br /><br />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. <br /><br />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,</div></blockquote><br />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. <br /><br />On Master branch, I got good result, even travel speed increase to 180 mm/s, my fastest so far :).]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Tue, 27 Dec 2016 02:11:59 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,732953#msg-732953</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,732953#msg-732953</link> <description><![CDATA[ OK, just checked your config.<br /><br />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. <br /><br />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,]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sun, 25 Dec 2016 06:48:48 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,732839#msg-732839</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,732839#msg-732839</link> <description><![CDATA[ Yes, there are some tests for the gcode. So it will impact.]]></description> <dc:creator>Wurstnase</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sat, 24 Dec 2016 06:38:25 -0500</pubDate> </item> <item> <guid>https://reprap.org/forum/read.php?147,33082,732836#msg-732836</guid> <title>Re: Project: Teacup Firmware</title> <link>https://reprap.org/forum/read.php?147,33082,732836#msg-732836</link> <description><![CDATA[ <blockquote class="bbcode"><div><small>Quote<br /></small><strong>Wurstnase</strong><br />Can you send me your config files and gcode. I would like to test it.<br />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.</div></blockquote><br />Yes, debug enabled in the experimental. Does it still have an impact when debug level set to zero (M111 S0) ?<br />The gcode is big, even when compressed still can't be attached here. Let me know your email please.]]></description> <dc:creator>zungmann</dc:creator> <category>Firmware - experimental, borrowed, and future</category> <pubDate>Sat, 24 Dec 2016 06:33:11 -0500</pubDate> </item> </channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
