Quote
MattMoses

Quote
Traumflug

Quote
thejollygrimreaper

Quote
thetazzbot

Quote
Traumflug

Quote
thetazzbot
How about the ultralcd support?

I see no reason why this should happen. Plenty of [censored] yelling wishlists, zero people actually writing such code. For me, there are more interesting things to hack, e.g. jerk-less look-ahead, which is something I'd have actual use for.

For the record, I'm not an [censored], actually I'm quite a nice guy And a developer, so if you don't have any objections I wouldn't mind forking Teacup to see if I can add in the lcd support. I would love to see Teacup with LCD and SD card and that's just about all I'd add to it Because then it will be perfect (for my selfish needs) .

have you done anything with this? i'm curious as i'm also looking at the possibility of lcd support now that the sdcard stuff is working

Maybe he did, but certainly nothing publicly visible. That much to "I'm a nice guy" and "I'm not an [censored]".

Would you guys consider trying out bounties? It seems like bounties could make this a win-win situation for everyone. People yelling wishlists could put up a little cash if they were really serious, and the developer(s) could get incentives for things they are not immediately interested in working on. In addition, developer(s) might be able to drum up a little funding to work on things they are immediately interested in.

(Tangent: I am trying to revitalize interest in the bounty system so I am going around finding places where it might be useful.)

I must admit I've been thinking of using the bounty system to try and encourage working lcd support but i wanted to attempt it myself first.

i would make the bounty simple though, bare minimum lcd requirements, file listing , ability to select a file to execute and maybe a very basic temperature and Z position readout, i would throw $50Aud on that now

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

Quote
MattMoses
Would you guys consider trying out bounties? It seems like bounties could make this a win-win situation for everyone. People yelling wishlists could put up a little cash if they were really serious, and the developer(s) could get incentives for things they are not immediately interested in working on. In addition, developer(s) might be able to drum up a little funding to work on things they are immediately interested in.

(Tangent: I am trying to revitalize interest in the bounty system so I am going around finding places where it might be useful.)

Hi Matt, nice you chime in. Read this late yesterday and thought a bit about how this could work. Because, surprise, surprise, working LCD code was contributed to Teacup already. Still it's not available for consumption. Why?

- It comes as part of a patch series to add support for Deltas and has to be separated from this.

- It's unknown how much it breaks for those without a display.

- It doesn't align with Teacups usual formatting, function naming and similar minor stuff.

- It's undocumented.

- It's unknown for which kind of displays it works and for which not.

- It's not available in Configtool.

Such a situation is typical for contributions. Teacup currently has some 40 feature branches, all packed with enhancements, from attempts to make the binary smaller to complex things like Delta support. And I'm working every day to align one such topic branch or another with the main branch, making these enhancements available for everybody.

Currently I'm porting Teacup to ARM for the fourth time. Each of the other three ports broke compatibility with ATmegas, something which is not accpetable for "mainstream" for obvious reasons. Considering this, it starts to clear up why dealing with contributions is such a tricky business:

- People do enjoy contributing code. No doubt about this. Especially when code is well readable and with a reasonable overall design.

- However, in 99% of all cases, contributions stop at the "it works for me" stage. Apparently that's the ultimate achievement people can think of.

- No point is seen in making it working for thousands of others. Most don't even care wether their contribution breaks things for these others.

- No point is seen in getting it to the experimental / master branch, which makes it subject to all future updates. Typical example is the Lumentino branch, which brought in support for a second extruder. It was written some 2 years ago and if you want to use it, you get Teacups' feature set of that vincinity, of two years ago. Because it was never joined to the experimental branch and also never rebased (updated) to newer versions of it.

- As a result of this, the maintainer (me) has to rework almost every single line of code contributed. This takes time, of course. If possible at all, because testing such new features also needs the hardware for it.

- That said, Configtool is an outstanding exemption from this. Jeff continued to work on it, got rid of the quirks, and as a result it's available for everybody now. Excellent!

Teacup somehow managed to keep most of these contributions in branches, but still in the main repository, so they're visible. No major forks known. Very good. Next task should be to encourage people working beyond this "it works for me" stage. Having it working in a single setup is perhaps 30% of completion, the other 70% are not as much fun, but even more crucial for success.

That much from my experience over the last few years. :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
- That said, Configtool is an outstanding exemption from this. Jeff continued to work on it, got rid of the quirks, and as a result it's available for everybody now. Excellent!

Thanks for the kind words.

I'm a software developer by profession, an electronics tinkerer as a hobby. The thing I like about the 3D printing hobby is it gives creative outlets for both. When I decided to to work on configtool, it wasn't because I needed it for my printer - at the time I was using marlin - it was because it was (and continues to be) a fun challenge. Also, to be able to give something back to this community is rewarding. So I'm actually hoping we get more users; I'm hoping we add more features - to both teacup and, therefore, to configtool.

Regarding the bounty being offered for a configtool, this is the first I'm hearing of it. If it is eligible, I'd be happy to contribute whatever might be my "share" back into the teacup effort.

Been a while since I had a bit of time for this, but I got Teacup configured with the config tool for the CNC Shield V3 & a UNO. The config tool compiled the hex just fine, but the upload timed out. I just used Xloader to upload the hex. Connected to Ponterface just fine! I don't have the seven switch soldered up yet, but I will get it connected to some steppers soon.

Thanks for the help!

Edit: Updated Board File. I had to manually enable the internal pull up resistors to get the endstops to work. I've tested everything but the hotend. Well, I kinda tested the thermistor by placing different value resistors to the pins to confirm it registered a temp change. I will build the correct voltage divider circuit to connect the thermistor soon.

board.CNC_Shield_V3_UNO.h

Edited 1 time(s). Last edit at 07/24/2015 10:17PM by madmike8.

Quote
madmike8
Been a while since I had a bit of time for this, but I got Teacup configured with the config tool for the CNC Shield V3 & a UNO. The config tool compiled the hex just fine, but the upload timed out. I just used Xloader to upload the hex. Connected to Ponterface just fine! I don't have the seven switch soldered up yet, but I will get it connected to some steppers soon.

Thanks for the help!

i find with the configtool when i upload to the rumba board i have to press it's reset button and then click on the upload bit, then it works quite reliably

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

As with most things... It was User error... LOL

I switched Edit>Settings>AVR Programmer from stk500v2 to arduino, and it worked like a charm!

Quote
madmike8
I switched Edit>Settings>AVR Programmer from stk500v2 to arduino, and it worked like a charm!

Unfortunately such settings are almost impossible to auto-detect. Still glad you got it working :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
madmike8
Updated Board File. I had to manually enable the internal pull up resistors to get the endstops to work.

Thanks, added this to the experimental branch. Removed this pullup thing, because it's a property of the printer (printer tab -> Miscellaneous -> second in the left column). Also added the used heater pin to the list of available heaters heater pins. Other than that: Thank you very much!

Edited 1 time(s). Last edit at 07/25/2015 06:00AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Just did the first stepper motor movements with the generic ARM port. Works nicely, Teacup is really portable. Almost no code changes neccessary, except for splitting files into platform variants and writing the ARM part.

Step rate currently maxes out somewhere at 128 kHz:



Nice, isn't it? 25% faster than Smoothie, 32% faster than Marlin, despite a 35% lower CPU frequency.

To be honest, it's partially disappointing. Despite all the math done at step interrupt time is all 32 bit, these chips take almost as many clock cycles as 8 bit AVRs, also doing 32 bit math. On AVR the step interrupt takes 304 clocks, on ARM it's still 288. That much to the myth of 32 bit being faster by register size.

That said, the $2 LPC1114 runs at 48 MHz, the $4 ATmega1284 at 20 MHz. More clocks per second for free :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for your work!

Generic ARM port is done :-)

*gen7-arm* is 88 commits now and every single one of these passes the regression test. My local TODO list is empty regarding this port. Configtool changes are still outstanding, so far one has to use Makefile-ARM and edit the board file (*config/board.gen7-arm.h*) manually.

I'll let it on this branch for another few days for you to play with. Some AVR code had to be changed, too, e.g. heater/pwm setup code.

If you want to do your own port, simply repeat the same steps as the ones on this branch. It changes things in fairly easily understandable chunks, many many comments on what's done each time and how to test the new achievements.

Enjoy!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Well done! As usual, thanks for your hard work!

Thanks for this great firmware

I got it running on gen 3 electronics (cupcake) with a few small and one bigger issue:

- The SD card is connected to the switched portion of the powersupply, and is therefore not detected if Teacup decides to switch off the power due to inactivity. Right now I just have it power on when calling M21, but that gives only a short window to use the card.

- The extruder controller is (partially) power switched, so if the heater is turned of for too long Teacup will switch off the power supply. At that point the temperature readings will stop working, and Teacup will keep repeating the last temperature. After discovering this I disabled the countdown for inactivity... solving the SD card going missing as well.

- The biggest Problem though is the temperature control... I have an MK5 Plastruder, now upgraded with a stepper motor, which still relies on power resistors bolted to a steel block for heating. It therefore has quite some delay in responding to changes to the heating power. Setting the temperature to 220°C I get an oscillation of around +-8°C and a period of ~2min. This is large enough that Teacup switches of the extruder during the low temperature phases (as in not extruding filament, at this stage I already had disabled the power off).

I have migrated the non-pwm heater settings from the main heater.c to the one in the extruder directory. Therefore right now I use PID control with on/off switching, though it works mostly like the bang-bang setting and just about switches the heater on/off at target temperature crossings... How can I tune the temperature controls in Teacup?

Quote
benj919
- The SD card is connected to the switched portion of the powersupply, and is therefore not detected if Teacup decides to switch off the power due to inactivity. Right now I just have it power on when calling M21, but that gives only a short window to use the card.

You mean the SD cards works at all? That's the first time I hear this from a Gen3 user. Apparently no other firmware managed to do this.

Quote
benj919
I disabled the countdown for inactivity...

At some point we probably should have a compile time flag for this. A secret: currently I hack on gEDA/pcb and it's lots of fun, because people collaborate. Still 3 times more wishlisters than hackers, but at least one doesn't have to push, push, push everybody else all the time.

Quote
benj919
- The biggest Problem though is the temperature control... I have an MK5 Plastruder, now upgraded with a stepper motor, which still relies on power resistors bolted to a steel block for heating. It therefore has quite some delay in responding to changes to the heating power. Setting the temperature to 220°C I get an oscillation of around +-8°C and a period of ~2min. This is large enough that Teacup switches of the extruder during the low temperature phases (as in not extruding filament, at this stage I already had disabled the power off).

I have migrated the non-pwm heater settings from the main heater.c to the one in the extruder directory. Therefore right now I use PID control with on/off switching, though it works mostly like the bang-bang setting and just about switches the heater on/off at target temperature crossings... How can I tune the temperature controls in Teacup?

Maybe this issue explains it: [github.com] "Bonus points for a calibration utility in Configtool to set these values automatically ..." ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
benj919
- The SD card is connected to the switched portion of the powersupply, and is therefore not detected if Teacup decides to switch off the power due to inactivity. Right now I just have it power on when calling M21, but that gives only a short window to use the card.

You mean the SD cards works at all? That's the first time I hear this from a Gen3 user. Apparently no other firmware managed to do this.

Send: M21
Recv: ok
Send: M20
Recv: Z_FLOA~1.S3G
Recv: XY_TEST.S3G
Recv: ok

I have not yet printed from the sd-card, so I'll give a tentative "yes?" to does it work at all.

Quote

Quote
benj919
I disabled the countdown for inactivity...

At some point we probably should have a compile time flag for this. A secret: currently I hack on gEDA/pcb and it's lots of fun, because people collaborate. Still 3 times more wishlisters than hackers, but at least one doesn't have to push, push, push everybody else all the time.

Quote
benj919
- The biggest Problem though is the temperature control... I have an MK5 Plastruder, now upgraded with a stepper motor, which still relies on power resistors bolted to a steel block for heating. It therefore has quite some delay in responding to changes to the heating power. Setting the temperature to 220°C I get an oscillation of around +-8°C and a period of ~2min. This is large enough that Teacup switches of the extruder during the low temperature phases (as in not extruding filament, at this stage I already had disabled the power off).

I have migrated the non-pwm heater settings from the main heater.c to the one in the extruder directory. Therefore right now I use PID control with on/off switching, though it works mostly like the bang-bang setting and just about switches the heater on/off at target temperature crossings... How can I tune the temperature controls in Teacup?

Maybe this issue explains it: [github.com] "Bonus points for a calibration utility in Configtool to set these values automatically ..." ...

I found the pid parameters in heater.c and will compare those to the ones in the original firmware and play around with them.

Right now I have most of my fixes on a github fork and will be looking to contribute them back. (I think I asked about how to provide them in the configtool thread...). The thing is currently I'm on my last two months of my master thesis so I do not have the time to properly test them (e.g keeping the power on will keep the steppers enabled at all times) or soon to work on this at all until the end of the thesis. After that I'd be interested in continuing to work on this. Though I'm afraid until then this will stay the (usual) vague promise for future contributions in return for immediate hints.

Sounds very good, benj919!

Now I'm crossing my fingers for your thesis.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

i am trying to use teacup with a polar bot. For that i need to add new kinematics. Is the file dda.kinematics.c the place to do it?

Robert Kuhlmann added the kinematics already, it's on the branch scara.

That said, this part is probably untested. Also no integration into Configtool. Needs rebasing to recent experimental. But it's a start.

For places to add additional kinematics, look ad how it's done for CoreXY. A KINEMATICS_SCARA is already present, but commented. And yes, dda_kinematics.c/.h plays a big role.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

thanks , i have already seen the scara and delta branch. My bot is not based on scara but more polar and i am not using it for 3d printing but rather for plotting. Of all the firmware s i think teacup is the easiest to modify . I will look at corexy to see how the kinematics are implemented..

You should take a look more into the delta-kinematics. A CoreXY has a linear combination to move straight. Polar-Bot has some sin/cos-functions. So you need in this case segmentation for your move. This can't be done only with a kinematic/inv-kinematic.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

my plotter is a rotary x axis and a sliding y axis .. so y do i need segmentation ? why can t i use straight forward inverse kinematic equations to move it?





thanks

Edited 1 time(s). Last edit at 11/11/2015 03:55AM by ekaggrat.

Quote
ekaggrat
my plotter is a rotary x axis and a sliding y axis .. so y do i need segmentation ? why can t i use straight forward inverse kinematic equations to move it?

It's a matter of having enough processor power to calculate the timing for each microstep using the inverse kinematics, or to calculate it at least every few microsteps and interpolate the ones in between. On a Cartesian or CoreXY printer this is straightforward. On a delta it is possible on 32-bit electronics, because the most complex computation is a square root, and this can be done quite quickly using integer maths. However, if your inverse kinematics involves trig functions, then I suspect that even if you use a processor with built-in floating point such as ARM Cortex M4, the calculation time would be too long. So I think you are forced to use segmentation because of your rotary X axis.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
Wurstnase
So you need in this case segmentation for your move. This can't be done only with a kinematic/inv-kinematic.

Segmentation is kind of a kludge and mathematically it's always possible to go without. Doing without, or segmenting in time intervals, is more work, of course. Teacups currently prefered way is to segment in time intervals, which means to adjust movement direction every 2 milliseconds.

That said, segmenting by distance is entirely independent from the kinematics function.

Quote
dc42
However, if your inverse kinematics involves trig functions, then I suspect that even if you use a processor with built-in floating point such as ARM Cortex M4, the calculation time would be too long.

A sine can be calculated in just 560 clock ticks, even on a integer-only 8-bit CPU: [www.mikrocontroller.net] That's just 0.028 milliseconds or 35 sines per millisecond. Adding another 400 clocks for other calculations that'd mean no less than 20'000 steps/second.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@ekaggrat:

If you decide to work on Teacup, I'll happily give you write access to the Github Repo. Uploading your work there, even if it's only partial work, is important. It also allows to discuss and review the implementation. Much of what you see now got into Teacup the same way.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

yes sure .. my first target is to get the plotter working using the default teacup Cartesian co ordinates . I am using a script to modify the Cartesian gcode to polar . Once i get it running properly i will then try modifying teacup kinematics. I am still waiting on some parts so it will be some time.

thanks

i started testing the bot and hit a snag. teacup wont compile with different steps per mm for x and y .. Is that right ?

It certainly should compile with any combination of steps/mm. What is the error message?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

D'oh. It was just pointed out to me that there is indeed a test for equality of steps/mm on X and Y ... if lookahead is turned on.

Well, then there's something which needs work :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

does that mean i cannot use teacup for now. or should i use it without lookahead? i tried temporal acceleration but with that the motor just dont move. Can it be used with a normal cartasian setup or is it meant only for a delta?

My thesis is done and I'm back to get my cupcake running.

I have "fixed" the heater problems by introducing an additional 500 ms tick for calling the heater step. I am running the PID loop with the original parameters retrieved from the makerbot firmware and a 8s history window, resulting in a +-1C oscillation; about the same I had with the original firmware.

The (probably/hopefully) last step before I start printing is to modify the power on/off routine to disable the steppers directly instead of turning off the power supply to keep the sd card working.