Teacup_Firmware
Teacup_Firmware copied to clipboard
Traumflug
Welcome aboard, Daniel!
The rules here are simple: keep fingers off branches master and experimental for now, but create as many own branches you feel need for. In Git parlance they're topic branches, so their commits can be refined in place and follow recent development by rebasing until it's reasonable sure the goal of the change/feature is achieved.
Yes, I'm aware you might be waiting for a Gen7 with 5th extruder, so I'll dedicate today to get this finished. Until then I have only a picture:
The pins available on these two SPI connectors can be used to drive a second extruder. The one pin for SPI1 is the Enable pin, which could be taken from the other Enable pins, too. Freeing SPI1 doesn't free the SPI bus, though, most pins are shared between SPI1 and SPI2.
Thanks @Traumflug, as discussed I'm intending to follow up the above hardware with the appropriate working firmware for a 5th extruder (aka motor + heater + thermistor).
Right now, I'm getting my head around the structure of the project and its inner workings so that I'm context aware before I start the above.
@Traumflug I've noticed in #204 that the major issue with the changes involved was the large amount of unresolved conflicts in rebasing branches other than master.
Is there a list of "officially" supported branches that are to be kept up to date such that they must be rebased?
There are a large number of stale branches and only about ~10 branches that are somewhat up-to-date.
Basically all branches have some justification. Each of them contains an idea, some improvement, some code which should be evaluated and be either discarded after careful consideration or be adjusted to enter mainline. "Stale" branches aren't stale because they contain nonsense, but because nobody reworked them to enter mainline.
A good example is branch scara, which adds support for Scara printers. But nobody tested this, no support in Configtool, it might break other kinematics types, some reverting commits which should be squashed, stuff like this. On how to deal with them see issue #81.
For the second extruder thing, branches lumentino and multi-extruder add some support. Certainly old enough to count as "stale", still valuable code. Task would be now to look what's the distinction between them and how they can be adjusted to fit modern knowledge and user expectations. Most of the commits on these branches should simply go away during step-rebasing, as the urgent parts were picked to experimental/master already.
There is a branch arc-support which claims to support G2/G3. Cleanup opportunities I see at a first glance:
- Should be wrapped into a #define, because it's likely a big chunk of binary size.
- motion_control.c/.h needs cleanup and a proper name.
- There is some "E endstop" ... should go into a separate commit, be allowed to be absent and evaluated for usefulness.
As far as I can see, this implements G2/G3 by segmentation. Not ideal, but certainly better than nothing.
After messing a few days with OpenJDK 9 (can't run Visolate), then OpenJDK 8 (can run Visolate), then building a JAR with a Makefile, then doing a number of non-software duties, something appeared at last:
Two of these four are for you, @dcousens :-)
Received! Thanks @Traumflug!
Will keep this thread up to date with my progress.
Status update
I broke my 3d printer and then became bogged down with several projects for work. I intend to follow through on my intentions above around the Christmas period.
I have not forgotten, I'm currently cleaning out my garage to get back to this!