search

Traumflug / Teacup_Firmware

Firmware for RepRap and other 3D printers
http://forums.reprap.org/read.php?147
GNU General Public License v2.0
310 stars 198 forks source link

Using Teacup Firmware on Arduino Uno and Delta Printer ? #63

Open polskiziom opened 10 years ago

polskiziom commented 10 years ago

Hi, I have recently configured Teacup Firmware to work on Arduino Uno with 4 Pololu stepper drivers, but how to set Teacup to be used on Delta Printer? Is there any implementation of Delta Kinematics in code or I have to fork it on my own?

Traumflug commented 10 years ago

You're right, there's no implementation for deltas in Teacup, yet. You can work on this right here, I've just added you as a collaborator. The only wish I have to you is to use a branch (or multiple branches) for your work and to not touch the other branches for now. Using a branch makes it easier for us to integrate your work and easier for you to follow other developments.

Welcome to Teacup development, @polskiziom!

Traumflug commented 10 years ago

Doesn't look like there's something happening. Please open a new issue on demand.

darconeous commented 10 years ago

Is anyone working on adding Delta support yet, or is this something worth looking into writing myself?

Traumflug commented 10 years ago

Is anyone working on adding Delta support yet

As you see above, apparently not.

is this something worth looking into writing myself?

Yes, please go ahead! There's a branch "dda-split" which roughly shows how it can be done. This branch meant to split all moves into chunks small enough to fit into 16 bit integers for better performance. An abandoned approach, but doing coordinate transformations should fit pretty well into the same place.

darconeous commented 10 years ago

Thanks, I'll have a look. I'm not committing to anything just yet, but the more I use the marlin firmware on my delta the more it grates at me as being quite inefficient.

I'd also like to add commands for switching the linear delta transform on and off, as well as better handling of things like acceleration and jerk.

Traumflug commented 10 years ago

I'll happily add you as a collaborator, just say so. Then you can commit to a branch early and everybody sees where the travel goes, perhaps even join the efforts. We have plenty of disk space.

Delta support should be wither on or off, as I'm not aware of a printer which can do both.

Improving acceleration and jerk? We're much better than others, already. Where do you see room for further enhancements? :-)

darconeous commented 10 years ago

well, maybe just adding delta support will put me ahead of marlin, then. :)

ridders commented 9 years ago

Is there any update on the above? I would like to use Teacup with a delta printer.

TTN- commented 8 years ago

Looks like it has been implemented!

https://github.com/Traumflug/Teacup_Firmware/tree/delta

https://www.youtube.com/watch?v=CT11gdPuA5c

darconeous commented 8 years ago

Time to close?

Traumflug commented 8 years ago

So far we have close to zero feedback on how well this delta support works. One video of a working printer and the maker of that video abandoning Teacup a few days later. That's modern RepRap, people are so used to get everything for free that they don't even care to say wether it works or what doesn't work.

To answer the question: no, not time to close. No evidence of the problem being solved, related code not on experimental/master, no support in Configtool.

dcousens commented 8 years ago

@Traumflug I'd test, but I don't have a Delta.

Traumflug commented 8 years ago

I don't have a delta either, so we have to wait for a kind soul running that code :-)

darconeous commented 8 years ago

Good point. I'll see if I can find some time to test it out over the next week. Would love to eventually switch entirely to teacup, once the majority of the features I depend on from Marlin are added.

I hate Marlin's codebase, but it's all of the features and hardware support that keep me stuck.

Who knows, maybe testing this will finally make me start writing up those features so that I won't have to switch back...

dcousens commented 8 years ago

@darconeous what list of features are you particular about? OOI, if you've written it up before, I apologize, just not sure where to look :+1:

TTN- commented 8 years ago

Are tower position adjusts included in the firmware feature set? I'm running ramps1.4 on a larger delta with the calibration set by: M666 D422.0 X-4.70 Y-2.96 Z-4.17 A0.07 B0.01 C-0.08 R197.0 H439.3 where D = diagonal. XYZ = endstop adjust. ABC = tower position adjust. R = radius. H = height from z home to glass.

So I can run the firmware. Will I have to reassign pins to make it work with the arduino mega?

Traumflug commented 8 years ago

Who knows, maybe testing this will finally make me start writing up those features so that I won't have to switch back...

Excellent idea! Make sure you look through the branches, there's a lot of stuff half done which just waits for being completed. For example that delta branch, which still uses a pre-configtool config.h file. Not too complicated to get this right, still it has to be done.

If you want write access to the repo for rebasing or adding your branches, just drop me a line.

Traumflug commented 8 years ago

Are tower position adjusts included in the firmware feature set?

Tower positions should be part of the configuration, because they don't change during runtime. Looking at branch delta it introduces M666, which is, uhm, the wrong way. Earlier in the same branch, here: https://github.com/Traumflug/Teacup_Firmware/commit/947a01c06b587340b2776debcfe2ac93dc6cff71, it's done better.

That said, first and most important step would likely be to verify the code works, no matter wether with M666, config.h entries or whatever. Making it configurable by Configtool can be done later.

TTN- commented 8 years ago

Awesome. I have my last exam tomorrow. I'm going to be busy catching up with life in general for a bit but I'll have a day free to test it for sure over the next week somewhere.

EDIT: Is the ramps 1.3 pin config compatible with ramps 1.4?

Traumflug commented 8 years ago

is there a pin config that exists already for ramps1.4 with an arduino mega?

RAMPS 1.3 and RAMPS 1.4 use the same pinout, so the one for 1.3 should work.

As I received this question more than once over the recent weeks I try to think about a solution. Taking versions into account we face easily 50 to 100 distinct controllers, how could we make the right choice intuitive without producing a huge mess ( = having a board.xxx.h for each of them)? Same for printers, 'mendel' is a good choice for about any carthesian printer, but people search for their specific model.

Good luck with your exams, Teacup will happily wait.

TTN- commented 8 years ago

Understandable. Marlin has a giant mess that does it, it works but its a nightmare to tweak if you need to customize.

Thanks. I'll do my best :-)

darconeous commented 8 years ago

@dcousens: I don't think I've actually written up a list. This is kinda off topic, but here is a quick list of features off the top of my head that weren't supported by TeaCup last time I checked:

The following features are those I REALLY want in my firmware but I haven't gotten them to work in Marlin and would love to get them to work with TeaCup:

phord commented 8 years ago

I also have a RepRapDiscount FGD LCD but I have not tried to integrated it with Teacup yet. I got it because it was cheap while I was ordering some other parts. I'm primarily interested in getting the display to work, but Teacup has little to display currently. I'd also like to get the SDCard to work, thought it's somewhat unrelated to the display.

I found shockingly little documentation on this card and the RAMPS pins which connect to it. So it has not risen to my level of interest yet beyond some simple SDcard tests (which failed).

If you start to make any progress on this thing let me know and I'll (probably) be happy to jump in and help.

Firmware retraction seems simple enough, though there seems to be some disagreement between Marlin and Repetier.

I thought Rumba was based on RAMPS and therefore had similar pinouts. Have you tried the RAMPS config?

GCode "includes" should be simple enough, I would think, since SDcards are already supported. But nested includes would have to be limited to some acceptable stack depth.

fwiw - I prefer to move the SDcard and controller functions to an OctoPi.

TTN- commented 8 years ago

How should I go about building the firmware? Should I go in an manually edit everything or use the config too. Atm I've gone in and manually set configs, I'm getting an error in the make process: config/board.ramps-v1.3.h:152:79: error: ‘AIO14_ADC’ undeclared here (not in a function) DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO14, THERMISTOR_BED)

I've been following the instructions for the developer install: http://reprap.org/wiki/Teacup_Firmware#Developer_Installation

Traumflug commented 8 years ago

You should use Configtool unless you're a developer trying #defines not yet exposed there.

TTN- commented 8 years ago

Ok, awesome. So I have things setup how I like them, it builds (no fails, looks good). Build log paste: http://pastebin.com/xAVdiX6f

On uploading I'm failing on this: avrdude: stk500v2_command(): command failed Full paste: http://pastebin.com/9wecNdPE I've googled the issue, but not learning an awful lot. I've also tried a different usb cord, and arduino-1.0.5 and arduino-1.5.8 with both giving the same upload error. With arduino-1.0.5 there is an error when building: avr-gcc: unrecognized option '-save-temps=obj' so I've just stuck with version 1.5.8 which looks fine to me and is the version used in both pastes as above ^.

Sorry for the trouble, I'd like it to just work so I can test this delta support for all of us here.

Wurstnase commented 8 years ago

In configtool you could change the programmer from stk500v2 to wiring and test it. Maybe it's something like this?

TTN- commented 8 years ago

Hasn't changed anything. I've double checked compiler is set to wiring but it still says avrdude: stk500v2_command(): command failed That is just bizarre.

phord commented 8 years ago

"Wiring" uses the stk500v2 protocol. But it also tries to reset the board first.

Your pastebin shows it is still using stk500v2 on the command line though. Is that current?

I think you need to add -D to your avrdude command options. This is something the mega2560 needs now. There should be a place in config tool to add this manually. I think we should add it as default now.

Phil

On Sat, Jul 2, 2016, 2:23 AM TTN notifications@github.com wrote:

Hasn't changed anything. I've double checked compiler is set to wiring but it still says avrdude: stk500v2_command(): command failed That is just bizarre.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/63#issuecomment-230086655, or mute the thread https://github.com/notifications/unsubscribe/AAHkBCvw0SK4ZWHkZT8_YrU1g4DqcMuVks5qRgPrgaJpZM4BQTcr .

TTN- commented 8 years ago

Using wiring -D has done the trick.It has flashed and verified the write so that is fine and well now. Thanks for the suggestion! Now I have to make sure I have the delta kinematics in my configuration and then I can test.

TTN- commented 8 years ago

Homing results in no motors moving when the max endstop pins are set and the minimum pins are not defined. So I've left the min endstop pins defined (not sure if thats intended behaviour).

At the moment I do not have the delta kinematics in the firmware being uploaded yet. The settings for it appear to be in ./config.ramps-v1.3.h and it isn't being used because changes made in it do not have any affect. How do I make it so the config tool uses it?

I'm a bit confused about what to do with the file Its not a board.*.h so it doesn't belong in the boards folder. The contents do not look like config.h at all. Replacing config.h with config.ramps-v1.3.h doesn't work.

Traumflug commented 8 years ago

I see, you want to try on a delta. Fine.

First obvious step is to switch to branch delta. Doing so will make most of Configtool going away, because that branch was created when Configtool was in its very early stages. Also, the code writer decided to stick with the former build method, Makefile and a single config.h. It goes like this:

cp Makefile-AVR Makefile
cp config.ramps-1.3.h config.h

Then edit Makefile (explaining comments inside) until you can build and upload with this:

make
make program

Replacing config.h with config.ramps-1.3.h should work. Before config.h was split into board and printer part, config.h contained both, so you find mostly the same #defines in there, just all in one file. An obvious next step for delta support development would be to get the additional #defines required for deltas into Configtool. That's mostly Python code.

P.S.: when using am old fashioned config.h using a text editor to tweak it is a good idea. The above advice to always use Configtool doesn't apply on this branch (you're using additional #defines).

TTN- commented 8 years ago

Sorry for the hassle. I'm doing my best.

I'm now running on the delta branch

Sidenote: I've had to define the heatbed in the config.h to be able to compile it.

I've done my best to figure how to fix it. I'm familiar with python but clueless with C. If its just too much hassle to walk me through the process thats ok I'm keen to try it, but its ok otherwise.

Running make I get:

username@PC:~/Physibles - 3D printing/Firmware/Teacup_Firmware-delta$ make
  CC        build/analog.o
  CC        build/clock.o
clock.c: In function ‘clock_250ms’:
clock.c:89:24: warning: implicit declaration of function ‘lcdGoToAddr’ [-Wimplicit-function-declaration]
                        lcdGoToAddr(0x00);
                        ^
  CC        build/dda.o
dda.c:43:60: error: ‘TOWER_X_ANGLE_DEG’ undeclared here (not in a function)
 const int32_t delta_tower1_x       = (int32_t)(COS(DegToRad(TOWER_X_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
                                                            ^
dda.c:45:60: error: ‘TOWER_Y_ANGLE_DEG’ undeclared here (not in a function)
 const int32_t delta_tower2_x       = (int32_t)(COS(DegToRad(TOWER_Y_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
                                                            ^
dda.c:47:60: error: ‘TOWER_Z_ANGLE_DEG’ undeclared here (not in a function)
 const int32_t delta_tower3_x       = (int32_t)(COS(DegToRad(TOWER_Z_ANGLE_DEG)) * DEFAULT_DELTA_RADIUS) >> 4;
                                                            ^
dda.c:50:24: error: ‘Z_MAX’ undeclared here (not in a function)
 int32_t delta_height = Z_MAX * 1000;
                        ^
make: *** [build/dda.o] Error 1
Wurstnase commented 8 years ago

implicit declaration of function is normally a function you want to call, but it doesn't exsist. This warning happens (clock.c:89:24:) in clock.c line 89.

Variables is caps are #define XYZ. When they are missing, they are undeclared.

TTN- commented 8 years ago

I've just gone ahead and put: `#define TOWER_X_ANGLE_DEG 60

define TOWER_Y_ANGLE_DEG 180

define TOWER_Z_ANGLE_DEG 300`

in dda.h which seems to fix this. Next Z_MAX undefined, so I've just gone ahead and uncommented them in config.h The thermistor table is in folder ./extruder, so temp.c can't find it. Fixed that as well.

Ok this one: not sure what to do about this.

~/Physibles - 3D printing/Firmware/Teacup_Firmware-delta/sersendf.c:244: undefined reference to `lcdWriteChar'
collect2: error: ld returned 1 exit status
make: *** [build/teacup.elf] Error 1
Traumflug commented 8 years ago

I've just gone ahead and put:

define TOWER_X_ANGLE_DEG 60 [...] in dda.h

Well done. Eventually they should go into config/printer.xxx.h and be adjustable by Configtool, but for now this doesn't matter much. Moving them later is easy.

sersendf.c:244: undefined reference to `lcdWriteChar'

This means some code tries to call this function, but the function isn't there. The name of this missing function suggests it's a non-critical one, so simply commenting out the call would be an option.

TTN- commented 8 years ago

Awesome. There was an if define for LCD so I disabled the LCD. It compiles now.

Now onto the last step to start testing this: make program is throwing:

/home/username/Scripts/arduino-1.5.8/ -c wiring -D -b 115200 -p atmega2560 -P /dev/ttyACM0 -U flash:w:teacup.hex
make: execvp: /home/username/Scripts/arduino-1.5.8/: Permission denied
make: *** [program] Error 127

I'm very sure this is not a permissions issue. Previously it all worked well with the config tool. Any ideas?

EDIT: using stk500v2 instead of wiring -D is giving the same result.

TTN- commented 8 years ago

In the Makefile setting: UPLOADER =~/Scripts/arduino-1.5.8/ instead of UPLOADER =/home/username/Scripts/arduino-1.5.8/ results in error 126. Permission denied:

/bin/sh: 1: /home/jotham/Scripts/arduino-1.5.8/: Permission denied
make: *** [program] Error 126

Where previously it was error 127 when using UPLOADER =/home/username/Scripts/arduino-1.5.8/ if that is of any use.

Traumflug commented 8 years ago

/home/jotham/Scripts/arduino-1.5.8/: Permission denied

You can't execute a directory. Configtool adds the remaining part on its own, it should be something like

/home/jotham/Scripts/arduino-1.5.8/hardware/tools/avrdude

And don't forget to enable the -C flag in the Makefile to point to the file avrdude.conf next to the avrdude executable.

If you're on Debian or Ubuntu it's easier to install the avrdude package:

sudo apt-get install avrdude

then, UPLOADER is just avrdude, no -C neccessary.

TTN- commented 8 years ago

Awesome. Its uploaded now. Its homing, pushes the endstops then backs away from the endstop, goes back up and rams it. Trying to figure out why atm..

Edit: M119 shows endstops functioning correctly. Homing is supposed to be happening at 50mm/s but it is more like 5mm/s. Steps per mm are supposed to be set to 200, and I have it set to #define STEPS_PER_M_X 200000 Odd.

TTN- commented 8 years ago

The best and most important part is that delta kinematics appear to be working!! I've just been jogging the effector around at a snails pace because thats as fast as it will go, but it keeps level and appears to be at a constant speed.

Traumflug commented 8 years ago

Homing is supposed to be happening at 50mm/s but it is more like 5mm/s.

Teacup features adaptive homing feedrates. The faster the axis can decelerate after the endstop trigger (it does decelerate properly!) and the more overshoot the endstop allows, the faster it'll home, up do maximum feedrate. SEARCHFEEDRATE{XYZ} is for the short movement back out of the endstop, where the precision measurement happens.

The best and most important part is that delta kinematics appear to be working!!

That's awesome. One common reason for unexpected slow movements is that Teacup pre-sets MAXIMUMFEEDRATE{XYZE} pretty conservative and respects that even on G0 movements. Raising this limit up to where mechanics and CPU processing power can still follow is possible, of course.

TTN- commented 8 years ago

Mmm. I see. That doesn't explain why it goes up towards an endstop and continues to run into it. The endstops are configured correctly (I checked using M119). Also all moves are extremely slow. They won't go any faster even after playing with the acceleration and speed settings. Increasing segment length and decreasing segments/s hasn't helped either.

It'd be great if I could replace marlin on my printer with teacup. The only features I need are autostarting prints from the sdcard, thermal runaway protection and support for the M666 with tower position correct.

phord commented 8 years ago

Is it possible your endstop is inverted? Try setting the INVERT flag for it.

On Sun, Jul 3, 2016, 4:32 PM TTN notifications@github.com wrote:

Mmm. I see. That doesn't explain why it goes up towards an endstop and continues to run into it. The endstops are configured correctly (I checked using M119). Also all moves are extremely slow. They won't go any faster even after playing with the acceleration and speed settings. Increasing segment length and decreasing segments/s hasn't helped either.

It'd be great if I could replace marlin on my printer with teacup. The only features I need are autostarting prints from the sdcard, thermal runaway protection and support for the M666 with tower position correct.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/63#issuecomment-230176673, or mute the thread https://github.com/notifications/unsubscribe/AAHkBLCO54n8NNP0iGbonuS8q0HkHF7uks5qSCpwgaJpZM4BQTcr .

TTN- commented 8 years ago

I should have said, the carriages hit the endstops, then go down away from them, then move up, run into the endstops and keep going up ramming them.

dyumanaditya commented 7 years ago

what is feedrate on teacup? Also enable? Do I have to have a pin reserved for enabling a motor? What does enabling do?