Project: Teacup Firmware

Quote
KevinOConnor
What I've been thinking of trying out in an experimental firmware is
replacing the standard G1 gcode commands with timed stepping
sequences. That is, instead of sending the micro-controller a command
to move the head a number of millimeters at a specific velocity,
commands would be sent to pulse a given stepper pin starting at a
specific time (measured in clock ticks) and for a given duration
(measured in clock ticks) with a given time between pulses (measured
in clock ticks).

Nice idea, but are you aware you have to achieve something like 40'000 steps in a single second? That's at least 100 times more than what you can send over a serial line.

Quote
KevinOConnor
I think one could, in theory, do all the acceleration, lookahead, and
kinematics in the slicer.

Yes, that's doable. Actually, original FiveD firmware did it this way with a simple trick: F doesn't command feedrate of the whole movement, but the feedrate to achieved at the end of the move, accelerating or decelerating along the wholedistance. This strategy is still described in the wiki: [reprap.org]

Teacup supports this strategy, too, when using ACCELERATION_REPRAP in config.h. Likely it's bit-rotten, because nobody used it for years, but the code is still in place and testing/fixing it is welcome.


Getting things faster IMHO means to get rid of the neccessity to split movements into tiny pieces and moving "real" curves instead. Like e.g. LinuxCNC does. You'd save most of these time consuming lookahead calculations. Far too complex for most RepRap heads, though :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
KevinOConnor
What I've been thinking of trying out in an experimental firmware is
replacing the standard G1 gcode commands with timed stepping
sequences. That is, instead of sending the micro-controller a command
to move the head a number of millimeters at a specific velocity,
commands would be sent to pulse a given stepper pin starting at a
specific time (measured in clock ticks) and for a given duration
(measured in clock ticks) with a given time between pulses (measured
in clock ticks). ...

So what would you need a microcontroller for?
Your approach would only replace the CPU-load from calculation to communication. Remember that besides movements the microcontroller has to take care of the heaters and measure the temperatures, check endstops a.s.o. So my idea was, to make life more easy for the mc by preprocessing the scara-maths prior to print - no more and no less.

Quote
Traumflug
Getting things faster IMHO means to get rid of the neccessity to split movements into tiny pieces and moving "real" curves instead. Like e.g. LinuxCNC does. You'd save most of these time consuming lookahead calculations. Far too complex for most RepRap heads, though :-)

Full ack.

Quote
Traumflug
Nice idea, but are you aware you have to achieve something like 40'000 steps in a single second? That's at least 100 times more than what you can send over a serial line.

Thank you for your reply.

At those high step rates the tool head is going to be traveling at a
near constant velocity though. So, in my thinking, that's still just
one command (per axis). So, to move the X at a constant velocity of
40000 steps per second for 3 seconds on a 20Mhz AVR the command would
be (in pseudo-command) something like:
STEP X pulse_time=500 end_time=60000000

40,000 steps per second is definitely a challenge though. That's only
500 ticks per step (on a 20Mhz AVR). I think the irq handler I
outlined in the previous message could use less then 500 cycles per
irq, but it is a challenge.

Quote
Traumflug

Quote
KevinOConnor
I think one could, in theory, do all the acceleration, lookahead, and
kinematics in the slicer.

Yes, that's doable. Actually, original FiveD firmware did it this way with a simple trick: F doesn't command feedrate of the whole movement, but the feedrate to achieved at the end of the move, accelerating or decelerating along the wholedistance. This strategy is still described in the wiki: [reprap.org]

Right, but ACCELERATION_REPRAP still left the kinematics and
acceleration to the micro-controller. That left much of the time
consuming math to be done in the firmware.

Quote
Traumflug
Getting things faster IMHO means to get rid of the neccessity to split movements into tiny pieces and moving "real" curves instead. Like e.g. LinuxCNC does. You'd save most of these time consuming lookahead calculations. Far too complex for most RepRap heads, though :-)

One of the reasons I want to try out per-axis step based timing is
because I'm hopeful curves would not require so many commands. When
moving in a circle, for example, the X steppers and Y steppers never
really need to come to a full stop. Thus, if one can model the X
stepping frequency independently, then I'm hopeful it would be less
commands. (That is, today, if either X or Y changes notably a new
command needs to be generated, but if X and Y are modelled separately
then new X commands are only needed when X timing changes non linearly
and Y commands are only needed when Y timing changes non linearly.)

I need to complete more work first to see what the impact of this
would be though.

Well, go ahead! Adding G- and M-codes is pretty straightforward in gcode_process.c, per-movement data is stored in dda, movement preparation (back end of the movement queue) is done in dda_create(), movement start (front end of the movement queue) in dda_start(), per-step calculations are done in dda_step() and movement maintenance is done in dda_clock(). The latter is executed every 2 milliseconds and works well for e.g. acceleration calculations.

If you want write access to the repo, please tell me your Github name. Adding such stuff in a branch is probably better than doing so in a fork.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Not related to host-side calculations, Teacup supports now canned G-code cycles. That's for exhibitions or when you want to exercise your steppers or whatever. Thanks to @ColinPoly for these good descriptions and @Triffid_Hunter for his implementation.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I was kind of happy to see mention of support for canned cycles since I use teacup to run a small cnc mill, but after taking a look at the source code I don't see any new gcode handling implemented in the gcode_process.c file. Am I just looking in the wrong place or misunderstanding what you mean by canned cycle?

As you mention production I guess you search for stuff like drill cycles or similar. These new canned cycles, or better: this (one) new canned cycle is a canned cycle which runs all the time, without additional G-code. So no cycles which can be called from other G-code. It's on the experimantal branch and described in the config.h templates, e.g. config.default.h, near the bottom.

That said, callable canned cycles would be a welcome contribution.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks to @thejollygrimreaper, Teacup supports CoreXY gantries now. Thanks a lot!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

If you pull regularly, you might have noticed a new sdcard2 branch. This is for implementing handling an SD card. I reviewed and wrote the code carefully, but I have no such hardware, so I rely on your testing.

Other than the 3.5 years old(!) sdcard branch it uses not FatFs, but Petit FatFs. This didn't exist back in 2011 and is a slimmed down version of FatFs. Slimmed down, like it can't handle file metadata and can handle one file at a time only, which is entirely sufficient for our needs.

Current status is, M21 - M25 implemented, so you should be able to open an existing file and print from it. To enable this stuff, define something like this in your config.h:

#define SD_CARD_SELECT_PIN DIO15
#define SD_CARD_DETECT_PIN DIO16

The latter only if you actually have a SD card detect pin. Pin names have to match your actual hardware, of course.

The only supported filesystem is currently FAT16. Expanding to also FAT12 and FAT32 shouldn't be difficult, there are flags in pff_conf.h. Implementing file writing will be a bit more difficult, but I guess I'll do that as soon as reading is known to work.

The nice thing is, all this stuff currently chimes in at only 3156 bytes, so Teacup still easily fits into ATmega 328's. Not defining a select pin entirely removes all the SD card support, not a single extra byte if you don't need such stuff.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Traumflug I can't find the line #define KINEMATICS KINEMATICS_COREXY in any of the config.h files and I need to enable it. Please link me to the source code which has CoreXY implemented even if only experimental.

You have to check out (or download) the experimental branch. Simply clicking "Download ZIP" on the Github web page gives you not that, but the master branch. A menu closer to the left side lets you change between branches, then you also get a Zip of that branch.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Traumflug thank you for pointing that out and a big thank you for the great effort in making Teacup.

Make sure to file a bug report in case you find something not working. Teacup developers can fix only bugs they're aware of.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sure

@Traumflug (bug report) It homes all the axes simultaneously correctly with the "G28" command. It fails to home the Z Axis separately with the "G28 Z0" (I'm using pronterface).

Thanks for the report, copied this to Github (where all developers are notified): [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

As I've been writing the configuration tool for this firmware, I decided I should go ahead and give it a try

I've actually been meaning to for some time now and I finally got around to it this past friday and have been tinkering with it since. I finally got everything operating OK at reasonable speeds. They were a bit slow out of the box, and probably still need a bit of adjusting, but I'm making progress. There are a few issues I am having, though, so I thought I'd bring them up. Some of them might be implementation choices that you have made, and I see them as issues because of the amount of time I've been using Marlin.

1) There is no way to query for the current temperature targets. M105 returns the current temps, but no indication of what the targets are. I'm pretty sure Marlin returned the targets from this command ("ok T:xxx.xx/xxx.xx B<xxx.xx/xxx.xx")
2) There is no interacting with the printer during an M116 wait. Under Marlin while waiting with M109 or M190 you couldn't interact with the firmware, but at least it would periodically produce a temperature report (M105) so that you could have some idea of how much longer you'll need to wait.
3) The hot-end temperature zig-zags up and down around the target temperature. From 3 or 4 degrees above to 3 or 4 degrees below. It never zeros in on the target. This is probably just a matter of tuning my thermistor table; I just used the stock one to get started.
4) this last one is really puzzling me, but I suspect it's a problem with my host software rather than the firmware. If I issue a manual command - such as M105 - while the printer is printing. I occasionally get a checksum error on some command that's in the buffer. It doesn't happen every time, so it appears to be some kind of race condition. The interesting thing is that my host software sends an M105 every few seconds in order to update its display and I never get this issue with those commands.

All in all, though, I'm very happy with the firmware. I have an LCD on my printer that worked with Marlin, but of course not with Teacup. The only thing I EVER used it for was to check the Z height periodically. I'm just fine abandoning it - although I'd like to retain the SD Card functionality. I know there are a couple of branches where this is being worked on.

Quote
jbernardis
1) There is no way to query for the current temperature targets. M105 returns the current temps, but no indication of what the targets are. I'm pretty sure Marlin returned the targets from this command ("ok T:xxx.xx/xxx.xx Bxxx.xx/xxx.xx")

So far nobody requested this and when this temp printing code was written, also printing target temperatures wasn't yet in fashion.

This printing code is in temp.c, temp_print(). Target temperatures are in temp_sensors_runtime, see temp_set() in the same file.

Quote
jbernardis
2) There is no interacting with the printer during an M116 wait. Under Marlin while waiting with M109 or M190 you couldn't interact with the firmware, but at least it would periodically produce a temperature report (M105) so that you could have some idea of how much longer you'll need to wait.

Code for such a regular report is already in clock.c, line 92/93, just commented out. I don't know what hosts currently expect, though.

Quote
jbernardis
3) The hot-end temperature zig-zags up and down around the target temperature. From 3 or 4 degrees above to 3 or 4 degrees below. It never zeros in on the target. This is probably just a matter of tuning my thermistor table; I just used the stock one to get started.

I think it's a matter of PID values, which can be set by M130..M134 with EECONFIG enabled. There are quite some topic branches which try to enhance the algorithm, I'd be glad if this stuff could be sorted.

Quote
jbernardis
4) this last one is really puzzling me, but I suspect it's a problem with my host software rather than the firmware. If I issue a manual command - such as M105 - while the printer is printing. I occasionally get a checksum error on some command that's in the buffer. It doesn't happen every time, so it appears to be some kind of race condition. The interesting thing is that my host software sends an M105 every few seconds in order to update its display and I never get this issue with those commands.

I'd guess your host doesn't send the M105 between two lines coming from the G-code file, but right when you send it.

Quote
jbernardis
I'd like to retain the SD Card functionality. I know there are a couple of branches where this is being worked on.

SD card code should be ready for at least reading the card (branch sdcard2). Have no such hardware, though, so I couldn't test. As soon as somebody can confirm it works I'll happily forward this to the experimental branch. Adding writing shouldn't be too much work, just the hardware layer in pff_diskio.c is missing.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
So far nobody requested this and when this temp printing code was written, also printing target temperatures wasn't yet in fashion.

This printing code is in temp.c, temp_print(). Target temperatures are in temp_sensors_runtime, see temp_set() in the same file.

I've already added the functionality on my system. I can include it in my branch (or a separate branch if you prefer) for consideration for the master/experimental branch. I'll put ifdef's around it so it's optional.

Quote
Traumflug
Code for such a regular report is already in clock.c, line 92/93, just commented out. I don't know what hosts currently expect, though.

Thanks - I'll check it out.

Quote
Traumflug
I think it's a matter of PID values, which can be set by M130..M134 with EECONFIG enabled. There are quite some topic branches which try to enhance the algorithm, I'd be glad if this stuff could be sorted.

Yeah - I figured it was just some tuning that needed to be done. Lower priority right now.

Quote
Traumflug
I'd guess your host doesn't send the M105 between two lines coming from the G-code file, but right when you send it.

My host sends an entire command - be it a Gcode command from the printed file or an interactive command - as a unit. I have the ability in my host to turn on low level tracing. I will try that soon to see if it gives me any information.

Quote
Traumflug
SD card code should be ready for at least reading the card (branch sdcard2). Have no such hardware, though, so I couldn't test. As soon as somebody can confirm it works I'll happily forward this to the experimental branch. Adding writing shouldn't be too much work, just the hardware layer in pff_diskio.c is missing.

I can give that a shot. My SD Card reader is a bit home-grown. It's not a standard SDRamps card, but it adheres to the same pin configuration so it should work. Ill check out that branch and give it a try.

Quote
jbernardis
I can include it in my branch

Yes, please :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I sat down tonight to tune the PID parameters for my hot end. First, I built teacup with debugging so I could use the M136 command. Before I did anything, I entered M136 only to have it report that the PID values were all 0. Undaunted, I proceeded to use M130, M131, and M132 to set my values. None of the commands offered any response other than the standard OK. When I then entered M136 again, I again got all zeroes back, so I started digging through the code.

First of all, I have EEPROM config enabled, so it initializes these values from EEPROM instead of from the default values. Since I had never stored anything in EEPROM, I thought this was my answer, so I entered all of the values again, entered M134 to store in EEPROM, and then entered M136 again only to get, yet again, 0's for the values. So this took me to the pid_set_x routines. These are very simple routines:

void pid_set_p(heater_t index, int32_t p) {
#ifndef BANG_BANG
if (index >= NUM_HEATERS)
return;

heaters_pid[index].p_factor = p;
#endif /* BANG_BANG */
}

What I see makes me think I'm non totally understanding how to set up my heaters. If I have BANG_BANG enabled - which I do because I run my bed with BANG_BANG - then the routine just becomes a null routine, and the value I entered is not saved.

So unless this is a logic error, what I think I have to do is disable BANG BANG. Then I can enter my PID values and save them in EEPROM. Does this then mean that I cannot operate my BED with BANG BANG and have to use PID? I guess it's not the end of the world, but I think it's a fairly common practice to use BANG BANG with the bed, and PID with the extruders.

That's right, bang-bang and PID are two different ways of controlling a heater. Bang-bang is generally adequate for the bed. The exception is when the heater power is high in relation to the thermal mass, resulting in significant temperature overshoot. In such cases, PID will give better results.

However, using bang-bang for the bed should not prevent you from tuning the hot end PID parameters.

Edited 1 time(s). Last edit at 01/24/2015 03:27AM by dc42.

---

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].

Maybe it's unfortunate, but currently Bang Bang vs. PID is all-or-nothing in Teacup. Same strategy for all heaters. Worse, all heaters share the same PID or Bang Bang values. Nice thing is, one can define a unlimited number of heaters already and the DEFINE_HEATER() macro can be extended to allow different values for each heater.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Disabling bang bang is fairly simple, and I can operate my bed with PID. This means I need to make a minor change to the configuration script. Right now on the miscellaneous page, one of the labels says "BANG BANG bed control". The word bed should be changed to heater.

Edited 1 time(s). Last edit at 01/24/2015 10:16AM by jbernardis.

So I disabled BANG BANG and now I can see that the PID parameters are being changed by M130, M131, and M132. I can also store them in EEPROM and see that they are retrieved on init.

The problem is that no matter what I set them to, I get the same temperature profile. I overshoot my target, but then it comes back down and oscillates from above 5 or 6 degrees above my target to about 2 degrees below my target, and the period of this oscillation is about 30 seconds. I had to change my hysteresis and residency time to a wide range over a short period in order to satisfy M116. I'd like to figure out what I'm doing wrong.

My starting point was to re-flash marlin and run the autotune. I then took those values and verified that they were sane with respect to the default values in Marlin (taking into account the scaling factor). I loaded those numbers and saw the oscillation pattern I described earlier. I read something somewhere that said to drop my P by 20% and my I by 50%, but that had no change. I even tried to get ridiculous and set my P value down to about 10% of its original value - no change. The only thing that made any difference was reducing the D factor, but all that did was move the entire curve down 2 or 3 degrees - still the same pattern.

I'm hoping someone has a suggestion for me. I'll keep trying, and I seem to remember seeing something in the code about debugging PID. I'm also trying to understand this 4th parameter - I limit - that I have not seen elsewhere. Is there something I can set there?

Thanks

Hi everyone,

I am really sorry if I'm doing something wrong by posting this, I already feel a bit uncomfortable since it seems like I'm intruding a well defined discussion between people who know what they are talking about, but this seemed like the most appropriate place to ask some things concerning Teacup. Didn't really find another topics concerning individual Teacup projects so...anyway, this is the thing:

I am working on a project that is a bit particular, let's just say I would like to have 6 axes in a specific configuration that are numerically controlled by reading a .txt file with G-code in it.

While I worked on the prototype, I wanted to check some basic concepts, mobility and so on, so I decided to make sort of a prototype test-bench that would be run by an Arduino UNO and DRV8825 drivers. I though: I got my processing unit (UNO) with 14 I/O, I could theoretically put 6 stepper motors (no end-stops obviously) driven by 6 DRV8825s and have 2 pins left, maybe use one of em to disable all of the axes with some emergency stop button.

The idea was that I generate my own gcode file using Matlab, then use a specific firmware that would interpret and interpolate the motion and pass it on to the DRVs.

Looking into several firmware options that would be easy to understand, modify and operate, I finished using Teacup for first tests since it seemed clean, big community around it, good reviews on the interpreter, lookahead and so on, so I wen't for it. Also I had mechanically only the first three axes and I was required to move them in short amount of time, so I said ok: lets use this Teacup, I won't use the extruder, heater and heated bed controls, Im just gonna upload my own generated gcode with trajectories done in Matlab, imma put the gcode file in the canned cycle and I'll succeed in demonstrating some basic concepts of the prototype.

And it worked. Very nicely. For three axes that is.

NOW, I would like to pass to a stage where I do the same thing but with 6 axes. Aaaaand this is where I decided to look for help from you guys, I don't know how to do it. I did not look inside Teacup, how it is written so I wouldn't know how to extend it to 6 axes. And I also looked for maybe other firmwares, but I only found this one:

[github.com]

But...looks like I need to have this RUMBA board or some adafruit shields or smth..yeah, it's not like I'm well experienced in all of these environments, but I am an engineer, so on the other hand it's not like I am incapable of understanding mechanics, electronics, mathematics or programming, even if it takes me a bit of time.

So, again, just to summarize...basically what I need help with is: how to take a 6 axes gcode (don't worry on how its made, I will generate it on my own...lines would look like "G1 Xbla Ybla Zbla Abla Bbla Cbla Fblabla") and pass it on to 6 DRV8825 that drive 6 NEMA 14 or 17. So, I just need an engine that will interpolate 6 axes, you know...take the slowest one (draw a straight line in 6 dimensional space with other words) and configure velocity, acceleration, lookahead and so on..

Any help would be much appreciated. And again, I apologize if I am being intrusive by posting my own problems with Teacup. If there is another place for this, would kindly ask you to point me to it, in which case, whoever is admin here can go ahead and delete this post.

Thanks a lot guys. I'm here for some additional clarifications.
Also, amazing work by developing Teacup, impressive.
SL

Edited 3 time(s). Last edit at 01/28/2015 10:48AM by StickyLube.

Hi @StickyLube, you're welcome, of course. This is the exactly right place to ask. Bugs or new code goes to the Github issue tracker.

The nice thing is, over the last year we looped up much of the code, so supporting more axes often just means to extend the array these loops read from.

Next nice thing is, there was already another guy, who had a similar plan, he wanted to drive a four axis wirecutter. This guy didn't complete, but already left some code behind, you can find that on the uvxy branch. These about 10 commits show a good way to implement a (more or less) arbitrary number of axes. LinuxCNC supports 9 axes, so let's Teacup do this, too: X, Y, Z, A, B, C, U, V, W.

Third nice thing is, there's the lumentino branch, which adds support for a second extruder. Unfortunately in a not very scaleable way, but it should give hints on which areas of the code need tackling.

Yes, quite a number of loose ends. Somehow typical RepRap, people often walk away as soon as they can say "it works for me". But these ends can be picked up, that's why they're there.

If you feel like moving towards 6- or 9-axis support, let me know. I'll give you repository write access, so you can upload your efforts, too. No obligations, of course, by creating your own branches you can't break anything.

If you have further questions, just ask. I'll happily share my knowledge.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi Traumflug,

Thank you for your recap on the state in which Teacup is currently at on this topic.
I saw the uvxy branch, honestly I have no idea where to start from at this point >_> seemed a bit chaotic, but I think that's just me and my lack of experience in github environment and teacup organization of things.

I don't want to commit to something if I can't deliver and at this point it really depends on how much time I will have to work on my prototype, cos it is something I do not have complete control over.
If I do have the time, this looks like a perfect chance to get into firmware programming a bit and leave something that others will find useful, but if I am pressured to get movements soon, I don't think I will go down this road.

You are still welcome to suggest other solutions that might be feasible with this hardware (UNO plus DRVs), you might know of...I took a look into LinuxCNC, btw. There are some obstacles with it that need thinking through.
At this point I thought of one that might sound crazy..(or stupid depends how u look at it)...which is synchronizing 2 arduinos to start executing 2 different gcode files? (imagine both of the arduinos with SD card shields, and each would be in charge of 3 motors) Is that possible? They can communicate through the series port, right?

Anyway, thanks for your fast reply and for being responsive and informative. I know I might seem a bit "light" when I ask or talk about some stuff, but I need to deal with different subsystems of this prototype first on high level approach before diving vertically into some problem. In any case, if I decide to go into expanding Teacup for >= 6 axes, I will let you know for organization, logistics and so on. I should know in the next 2 months.

Cheers

Edited 1 time(s). Last edit at 01/30/2015 05:51AM by StickyLube.

First steps to start with development would be to get git, gitk and a reasonable code editor, like Geany. gitk --all shows you how all these branches depend on each other. Github is nice for publishing, but not much more.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Got a PM and as I prefer to discuss in a community-visible manner ...

Quote

Teacup is intriguing to me for a couple of different reasons. (1) It uses a different design philosophy that would probably give better performance on the Mega/Ramps platform and (2) I am a Teensy 3.1 hacker and followed Nikki.V's work porting Teacup to the Teensy closely. I would like to extend that excellent work.

Thanks, and yes, Nikki's work is great. The problem with ARM is, we have no less than 3 ARM ports now, but each of them breaks ATmega support. That's why all of them tend to bit-rot.

If you want to enhance in this area, I didn't find much time to write code, yet, nevertheless an idea formed how 32-bit and ATmegas can be joined:

- Official support by ARM is a project they call "mbed". It's likely a good idea to take this as a foundation, it supports virtually all low end ARM chips existing. mbed it's self is perhaps already a bit a too high level, but it also comes with CMSIS, which does the real bare-metal stuff, like defining interrupt vectors.

- I've whipped up a "Hello World" app here: [github.com] to investigate/demonstrate how to build in a Teacup-compatible manner. Especially the Makefile there is interesting.

- As whole mbed is quite a blob, it might be a good idea to copy only the few neccessary files from there instead of integrating their whole repo. Also because then users get these files when downloading a ZIP from Github.

- Once this stuff is sorted it shouldn't be too difficult to pick Nikkis code to get the thing actually doing useful stuff.

Quote

I would like to add delta support to Teacup (if no one else is going to).

The most difficult thing is to find a person who actually has such a printer, is willing to run Teacup there, is willing to report the results and to iterate. Are you? :-)

Well then, there's dda_kinematics.c/.h and looking into these two files should explain how to get the transformation of coordinates done.

Quote

In a very simplistic sense, it seems that dda-split is the place to have the simultaneous ABC tower carriages moves inserted into the queue

dda-split is for splitting paths into small segments, only.

Quote

Would it be better to have constant velocity for the ABC tower moves or constant velocity at the effector (Cartesian XYZ)? Marlin does it one way, Repetier does the other.

For good printing results, acceleration/speed of the extruder matters. That said, all this approxximation with short segments is a bit a kludge, of course. I fear we can't avoid this kludge for now, making step-accurate movements curved and also properly accelerating and also constant velocity is pretty tricky.

If you want to discuss actual code, I'll happily give you write access to the repository. Much easier than wrestling with pull requests and Git also serves nicely as code discussion platform; just push to a topic branch and everybody else can pull and see it.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY