Compile Issues for Teensy 3.1

[nikkiverre]

Hi,

I am trying to compile Teacup for Teensy3. I am following the Developer's instructions from http://reprap.org/wiki/Teacup_Firmware#Developer_Installation

Here are the errors I am getting

I am not sure if I am missing something...

Thanks for your time!

Nikki

[nikkiverre]

Oh okay, you are so smart, I get it! Sorry, I should have added this above... this is the G code generated by the slicer engine: G21 ; set units to millimeters M106 S0 M104 S205 ; set temperature G1 Z5 F5000 ; lift nozzle M104 S205 ; set temperature M116 ; wait for temperature to be reached G90 ; use absolute coordinates G92 E0 M82 ; use absolute distances for extrusion

The gcode generated by the slicer engine is sending absolute extrusion commands (M82)... and in the RepetierHost settings, there's a checkbox for "use relative E distances" and that was unchecked. So, it seems like both the slicer and Repetier are sending absolute extrusion commands so I I think I just need to uncomment "absolute" in https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/config.teensy3.h#L137. I'll try it out in the morning. Thanks so much!

[nikkiverre]

hmm... I made the change in the config file to use absolute but the extruder still retracts at the beginning of my print and causes the filament to come out. Looking into it some more. I'm gonna change it to use relative commands instead of absolute and see what happens.

[Traumflug]

G1 Z5 F5000 ; lift nozzle

Make sure your max feedrates are set reasonable in config.h. Typical Z axes can do only far less.

I'm gonna change it to use relative commands instead of absolute and see what happens.

The value in config.h is a startup default only. M82/M83 overrides this. G92 E0 shouldn't move the axis. Apparently it happens later in your G-code (the part we can't see). You can copy & paste line by line to the manual input to see where this happens. Except for lookahead, pausing between G-code lines doesn't matter. Movement distances are the same, with or without lookahead.

[nikkiverre]

Oh okay I see. The max feedrate for E is set at 32,400 and Z it's 20,736. This is strange... I typed in part of the commands in Tera Term and it runs just fine... but when I run the print job in Repetier Host... it does it's movements and extracts the filament but then it also pauses and every time it pauses, it retracts the filmament (this is when the filament ends up coming out). I am not sure what G code is causing it to do that because they are all "G1."

UPDATE: I've changed the extruder commands to use relative distances instead of absolute and it doesn't retract anymore... the filament stays put. But now the problem is that it's not extruding enough filament to print when I run the print job.... If I manually extrude the filament, it's fine.

[nikkiverre]

Hey all, I got the filament to extrude as it prints... but it leaves a lot of blobs. Everytime the printer pauses, it keeps extruding filament so it leaves a lot of extra filament. Would I need to look into lookahead? How can make the extruder pause along with it printer so it doesn't squeeze out filament unnecessarily?

[Traumflug]

UPDATE: I've changed the extruder commands to use relative distances instead of absolute and it doesn't retract anymore

You mean you found a bug, like Teacup disrespecting M82/M83? A fix would be welcome, the variable handling this is target->e_relative and is handled in dda.c, line 180..220.

How can make the extruder pause along with it printer so it doesn't squeeze out filament unnecessarily?

You mean the carriage decelerating at each corner, just to accelerate again? You likely want to raise your JERK values in config.h. The higher the jerk, the higher sudden forces due to spontanuous speed changes, though.

Having the extruder extruding just the right amount even when accelerating and decelerating is a science on it's own. No agreement among researchers, much less an implementation in Teacup so far.

[nikkiverre]

You mean you found a bug, like Teacup disrespecting M82/M83?

I am not sure if it's a bug or not... I noticed that when I was using M83 and ran a print job, the axes would move and "pause" and during this pause, the extruder would retract causing the filament to come out completely (perhaps it is meant to do that...) And when I switched to M82 and ran a print job, the extruder wouldn't retract anymore during the "pauses"... it extrudes instead (creating the blobs that I was talking about earlier). Maybe I didn't calibrate it properly...?

You mean the carriage decelerating at each corner, just to accelerate again?

Hmmm I am not sure if this relates to acceleration or not.. I am sorry if I am not explaining this properly or misunderstanding haha but the axes move pretty well using the g code but then they pause frequently but the extruder motor keeps rotating during these pauses thus extruding filament and causing blobs. So I was wonderin why the extruder can't be paused along with the other axes. So image the print is print a square... the axes move in a square but then they pause, the extruder keeps extruding filament, so now there's a blog on one corner and then it continues with the next layer in the same fashion.

I feel like Repetier Host is doing something strange because when I extrude 10mm of the filament manually, it extrudes 10 mm but when I run a print job, I feel like it extrudes a lot more.

[Traumflug]

It's a bit difficult to tell what's wrong if you don't have much of an idea on how the printer should actually move and there's also a host which might inject additional G-code. Is there another printer, by chance? Then you could run the same G-code on both an compare. Not even neccessary to put filament in as long as you can see the extruder retracting without it.

Perhaps switching to Pronterface? Pronterface has a "Debug G-code" in the menu which shows exactly what's sent to the controller and how the controller responds. And AFAIK it doesn't try to enhance G-code other than removing comments, adding a line number and adding a checksum.

[nikkiverre]

Yeah, I see your point :) So I actually bought a fully working printer (arduino based) and I've been slowly porting over from the original brain to a teensy/teacup brain. So, the .stl file I am trying to print and the gcode I am trying to run now with teacup/teensy is the same one I tried with the original "brain" earlier. So, I know how the printer should actually move and the behavior to expect with the given g code... I switch over between the original brain and teensy/teacup brain during testing all the time. But unfortunately, I don't have another printer to compare like you suggested. I can try switching to Pronterface :D That's cool that it has a debug g code option. I'll try that out and see what's going on.

I actually don't have LOOKAHEAD enabled... my hunch is that I need it to have smoother transitions which will probably prevent the blobs. Thanks for all you help again!

[nikkiverre]

Hey guys :D I enabled LOOKAHEAD, messed with a few settings in slic3r, and switched to Pronterface and I have beautiful prints with Teacup/Teensy!!! There were no pauses during the prints and therefore no blobs. Thanks to everyone's suggestions and moral support along the way!

[Traumflug]

Oh, you had LOOKAHEAD turned off? Uhm, yes, then it's no surprise it doesn't work :-)

Anyways, excellent work! Thank you so much for being patient enough to get through with this. I'll make a post in the RepRap forum to celebrate this.

[nikkiverre]

Yeah, at first it was turned off. It's interesting though because when I enabled LOOKAHEAD, it was way better than before but there were still a few pauses and blobs and couldn't finish a print job. But then I switched to Pronterface and then it worked perfectly! Something's up with Repetier Host it seems like, I'm gonna try downloading a newer version and try again. Anyways it's working great, thanks again!

[drf5n]

Great job!

Repetier Host does a lot of filtering of the gcode as it parses and re-writes it, and I'm not sure it respects the dialect.

[Traumflug]

Not so fast, please :-)

While your work is excellent and it's great the Teensy3/3.1 works now, this stuff isn't on experimental, yet. This means, Teensy3 code won't follow future enhancements, e.g. this 4/6/9 axis support @nesqi is currently working on.

Approximately, only half the work is done. Things yet to do:

• Sort out what turned out to be unneccessary, e.g. the older versions of mk20dx128.c/.h. or code changes reverted later in the branch.
• Put CPU-specific code into arch-arm/ and make sure it's picked up by code in the main directory, still maintaining buildability with Arduino AVR and Arduino ARM.
• Split all the remaining code changes into logical, reviewable commits.
• When this is done, cherry-pick them over to experimental.

I think the best way to achieve this is to open yet another branch for this refactoring, this time keeping an eye on compatibility with existing stuff. To my experience, doing rebase -i many times can easily lead to loss of neccessary code, because one can no longer compare to the original, known to work code.

If you want to do this, great! Else this issue likely has to be kept open for a while until I somebody else (me?) finds the time. Seeing this great work falling behind over time would certainly be a loss.

[Traumflug]

To get started, I created the "teensy3.1-refactor" branch, rebased it on experimental and did some refactoring. For example, you have now adaptive homing feedrates.

Please test and enjoy.

[nikkiverre]

Things yet to do...

Sure, I would love to work on this! Just to clarify, do I work on the teensy3.1-refactor branch now?

[michaeljball]

Re-asking Nikki's question... do I work on the teensy3.1-refactor branch now? still get this error on compile: (fresh clean install of Arduino 1.0.6 /Teensyduino) gcode_parse.c:29: error: expected '=', ',', ';', 'asm' or 'attribute' before 'read_digit' gcode_parse.c:32: error: expected '=', ',', ';', 'asm' or 'attribute' before 'next_target' gcode_parse.c: In function 'gcode_parse_char': gcode_parse.c:114: error: 'read_digit' undeclared (first use in this function) gcode_parse.c:114:22: note: each undeclared identifier is reported only once for each function it appears in

[Traumflug]

The refactoring branch is for, well, refactoring. Like aligning Nikki's work in a fashion which doesn't break support for ATmegas. Newer considerations came to the conclusion there is no point in relying on this Teensy support package. There are so many ARMs now, making it impossible to fit them all into this package. Instead, there is the ARM (ARM, the company) supported MBED, which in turn comes with CMSIS. CMSIS is low level enough and supports virtually all ARM chips.

But that's not important now, for your purposes teensy3.1 and teensy3.1-refactor should have the same code.

I see these two lines erroring contain "BSS". It's be interesting to what this macro gets expanded. Arduino IDE compiles into /tmp/build... Can you find a file gcode_parse.i file in there? That's the macro-expanded source code. A bit difficult to read, but you should find "read_digit" in there.

It might work to simply remove this BSS. It's only a binary size optimisation.

[Traumflug]

There's a gen7-arm branch which brings in a proof of concept on how to build with MBED/CMSIS in a fashion which should work for all ARM variants in the retarget-sample-code folder.