Looking for an easily modifiable 'bare-bones' firmware.

Hi everyone.

Modern reprap firmware is great and has definetely come a long way in the last few years. However, its no longer very approachable for casual tinkering.

I understand that this is a necessary evil in order to make it compact and fast enough to handle all of today's requirements on the often limited hardware, but is there anything out there that's a little more basic? I don't mind sacrificing speed and all but the most essential features in return for firmware that is simple enough that people who haven't completed a computer science degree can still play around with it.

Does such a 'bare-bones' firmware exist? Alternatively, is there a repository of the much older and simpler firmware from the early reprap days that I can test out ideas with?

I would like to try different and unconventional x and y-axis movement regimes, multipule extruder hot zones and on-the-fly adjustable extruder nozzle diameters but need an approachable firmware if I'm ever going to make any progress.

Thanks for your help.

Quote
Capo
Modern reprap firmware is great and has definetely come a long way in the last few years. However, its no longer very approachable for casual tinkering.

Maybe this is because moving steppers is actually a matter much more complex than it looks at the first glance. :-) You can move a stepper with a simple delay loop, of course, but that's not more than 1% of what you need to follow coordinates.

That said, I think Teacup firmware is as readable and tinkerable as it can get. For even more simplification you can remove the code wrapped by #ifdefs.

Quote
Capo
I would like to try different and unconventional x and y-axis movement regimes, multipule extruder hot zones and on-the-fly adjustable extruder nozzle diameters but need an approachable firmware if I'm ever going to make any progress.

Oh, you want to make it much more complex :-) Well, look at a thread like this: [github.com] Writing down the required maths was a matter of minutes, getting it working well is still ongoing after a month. If I can help, let me know.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for your reply Traumflug. It sounds like I need to have another serious look at Teacup then.

Cheers.

Quote
Traumflug
Oh, you want to make it much more complex :-) Well, look at a thread like this: [github.com] Writing down the required maths was a matter of minutes, getting it working well is still ongoing after a month. If I can help, let me know.

If you weren't so dedicated to supporting 8-bit processors in Teacup, you could make the code simpler by making use of the processing power of a 32-bit cpu instead, as I did in RepRapFirmware for the Duet. It took me about 2 weeks to add the Delta support

Quote
Capo
Thanks for your reply Traumflug. It sounds like I need to have another serious look at Teacup then.

You could also take a look at RepRapFirmware, in particuklar my fork which has better and more flexible motuion control than the original. It's not as old as Marlin and some of the other older firmwares, so it's a lot less cluttered. It's also written in C++, which makes for better structured and simpler code. Currently, it only supports Duet electronics, but it looks like there will be some ports in the pipeline soon.

I agree with Traumflug: motion control is not simple, which is the reason for at least some fo the complexity of 3D printer control firmware.

---

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
dc42
If you weren't so dedicated to supporting 8-bit processors in Teacup, you could make the code simpler by making use of the processing power of a 32-bit cpu instead

Teacup makes no compromises for being 8-bit compatible. An uint32_t is an uint32_t, no matter wether it's compiled for 8-bit, 32-bit or 64-bit. It simply takes great care of not wasting CPU cycles.

Most code is written and tested on 8-bit, simply because we have the better tools there. There's SimulAVR, but no SimulARM. There's avrdude, on ARM you need a whole bunch of uploading tools. gcc supports -mmcu for AVR, but not for ARM. Also important: if code performs well on 8-bit, it also performs well on 32-bit, but not neccessarily the opposite way.

Quote
dc42
as I did in RepRapFirmware for the Duet. It took me about 2 weeks to add the Delta support

And the result is apparently working well, but also slow enough to bring even a Duet to its knees. Now imagine what you could do when running a firmware performing as well as Teacup on a controller as fast as a Duet. Suddenly you have room for these extra bits Capo wants to implement.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug, my code certainly does not bring a Duet to its knees. I have tested it to 500mm/sec moves, which is way faster than most users need, to ensure it has sufficient headroom. I think I read somewhere that Arduino Mega/RAMPS/Marlin can only manage 150mm/sec on a delta. All this while the Duet is serving the web interface and PanelDue as well.

There is no point adding extra complexity to the code in order to save CPU cycles if you don't need to save CPU cycles. I don't, because I only target fast 32-bit processors. You do, because you target slow 8-bit processors. If I ever need more CPU cycles for something else, only then will I consider making the code more complicated to save CPU cycles.

Simplicity of code is a virtue. Efficiency of code in an embedded system is not of itself a virtue, the code just needs to be efficient enough for the purpose it is used for.

Edited 7 time(s). Last edit at 03/05/2015 07:12AM 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].

Bringing the conversation back to the OP, the kinematics I would like to implement are described here (TandemB/TandemC). I have been looking over NickE27's delta-temporal branch of Teacup to get a feel for what sort of changes would be required. Some of the changes put in place by Nick I can follow, others not so much. Other than the wiki page and commenting itself, are there any other sources of documentation that I have overlooked?

Traumflug, in your opinion, am I being unrealistic in thinking that a programing novice such as myself with no formal training can make these changes? I am happy to spend some time reading up on the topic but without first knowing how deep the rabbit hole goes this initially small part of a bigger overall project can quickly end up consuming all my free time. If thats going to be the case then I might look into getting some help from Nick since he has already done something so similar recently.

Thanks.

The equations of motion for the Tandem variants look to me very much like the equations of motion of a delta, but with 2 motors instead of 3. In which case, I think you have two solutions that are not too difficult:

1. Use the segmentation approach adopted by Marlin and similar firmware. The principle is to chop long linear moves up into shorter moves and transform the start and end XYZ coordinates to motor coordinates. Then assume that a short linear segment can be approximated by moving the motors linearly between their start and end points. So you should be able to take firmware such as Marlin and change little more than the delta transform and delta inverse transform functions.

2. Start with my fork of RepRapFirmware, which calculates delta movement precisely. For every move, it fills in a DriveMovement structure for each motor. There are two ways of filling in a DriveMovement, one for delta motors (used for the XYZ motors on a delta machine) and one for linear-motion motors (used for XYZ axes on a Cartesian printer, and for extruders). For Tandem you need to use the delta version for X and Y, and the linear version for Z and the extruders. You also need to change the delta transform and inverse delta transform functions, and change the delta version of CalcNextStepTime and the constants calculated by Prepare to account for the equations of motion of Tandem being slightly different from Delta.

(1) will be less work for you to do, but (2) will give more precision. Either way, you will also need to change the homing code (how do you home a Tandem?). In RepRapFirmware, all you need in the firmware is homing primitives. The homing functions themselves are defined in gcode macro files, which makes it very easy to change them.

I don't think the programming is difficult, but even so it may be challenging for a novice. But you do need a good grasp of maths to implement this stuff.

The solution that Traumflug and his colleagues are implementing in Teacup is more complicated than either of these approaches. But I am sure they will get it working well on delta printers eventually,

Edited 4 time(s). Last edit at 03/05/2015 09:55AM 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].

Quote
dc42
If I ever need more CPU cycles for something else, only then will I consider making the code more complicated to save CPU cycles.

In other words: Teacup already did what dc42 still has to achieve.

Quote
dc42
The solution that Traumflug and his colleagues are implementing in Teacup is more complicated than either of these approaches.

It's not. It just does the right things at the right time. There's no point in recalculating things 10'000 times a second if 500 times a second is entirely sufficient to comply with geometry and physics. Maths is the same, code is the same. In fact, increasing performance by a factor of 2.5 was a simple copy&paste operation from dda_step() to dda_clock().

If you want to see tries to increase performance by adding complexity, look at Marlin. They struggle to perform better on a Due than Teacup does on a traditional Arduino. The secret is to remove code or to execute it less often.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
dc42
(1) will be less work for you to do, but (2) will give more precision. Either way, you will also need to change the homing code (how do you home a Tandem?). In RepRapFirmware, all you need in the firmware is homing primitives. The homing functions themselves are defined in gcode macro files, which makes it very easy to change them.

I don't think the programming is difficult, but even so it may be challenging for a novice. But you do need a good grasp of maths to implement this stuff.

Thanks for your suggestion dc42. I am in the process of looking over Merlin at the moment and I might be able to make the needed changes. I also now have a working mockup to test firmware with so maybe progress will be a bit faster now.