Compile Issues for Teensy 3.1 #93
Comments
|
Wow, Teacup usability contest today. Excellent! Just to save you some work: the first error is usually sufficient. Copy&pasting the first few lines might be even easier. Which config.h template did you use? I'd like to reproduce ... ... did it work now? As I write the issue got closed. |
|
Sorry, my mouse went crazy on me for a second... I used the config.teensy3.h file |
|
I'm not entirely sure wether Teensy3 currently works. If at all, please checkout the teensy3 branch. Teensy3 did work a while ago, but with just one user so far it might got broken without being noticed. Github link: https://github.com/Traumflug/Teacup_Firmware/tree/teensy3 , also in your local Git clone, of course. |
|
Hmm... yeah, it seems to be broken now. There was an error with "ATOMIC END" not being declared and I managed to track it down and declare it. But after that, the errors I got were too many and I figured something else might be wrong. Is there a way to go back to the version that was working? |
|
The teensy3 branch is currently all we have. ATOMIC_END should be defined in memory_barrier.h ... and as it's easy to spot, there's a typo. ATOMIC_START in line 62 should be ATOMIC_END. Just fixed, please "git pull". One bug less, thanks for reporting. Are you aware this port also needs the Teensyduino package installed? README comes with additional installation instructions on this branch. |
|
Other than that, please keep reporting. Sooner or later this branch should go onto master anyways, so it's better to fix it sooner. |
|
Yes exactly, thanks for fixing it! In the future, should I submit a pull request? Maybe, I can continue looking into the errors and try to get it compiled. I have the Teensyduino software add-on for the Arduino IDE but I am not using the Arduino IDE to compile... is there a separate package I need to install if I am compiling in the terminal? |
|
Oh interesting... I just noticed there's a usb_serial.c and usb_serial_t3.c. I am assuming t3 stands for teensy3 but usb_serial.c is getting compiled instead of usb_serial_t3.c and that's probably why there are so many errors. |
|
Welcome to Teacup development, @nikkiverre! I just added you as a collaborator. Now you can write right to the repo, no need for pull requests. Just one thing to keep in mind: please don't touch master or experimental branch for now. Instead, open as many topic branches as you feel appropriate. Me or someone else will review and pick them over, then. I'm not aware of an additional package required. Perhaps @drf5n knows more? He's the hero who did this port. There's also issue #42 keeping track of this effort (and showing how the branch shrunk quite a bit already). |
|
I haven't used the teensy3 branch in a while, so I'm not sure of its state. Try moving usb_serial.c and analog.c out of the directory, and then something like this seems to compile: I just pushed a couple changes to the teensy3 branch to make it compile, using some of the AVR guard logic from #42 (comment) . The following produces some warnings, but compiles: I think I was using the usb_serial.c and analog.c files as templates for the usb_serial_t3.c and analog_ARM.c file. I'm not sure how I compiled it before, but since the Arduino and makefile process compiles everything and expects to filter it out in the linking, the alternate code in the directory causes issues. The current Makefile-teensy3 is pointing at my Mac install of Arduino1.0.5 with the teensyduino extensions from https://www.pjrc.com/teensy/td_download.html |
|
Oh okay, thanks for the help! Once I removed usb_serial.c and analog.c, the code compiles. I have a teensy 3.1 and 3D printer hardware... so I'll test it out and see what happens. |
|
The teensy3.1 has a mk20dx256 processor, so you likely need to make adjustments for anything mk20dx128 specific. Maybe look to https://github.com/PaulStoffregen/cores/tree/master/teensy3 for code that works with both chips. Good luck--looks like a nice chip. eta: Earlier, I copied the mk20dx128, teensy3 usb and analog stuff from the teensyduino addons, then tried to make minimal adjustments in the filenames and headers (usb_serial.c->usb_serial_t3.c, etc.. ) to not clash with the existing files. I'd suggest updating the files to follow Paul Stoffregen's modifications to support teensy 3.1. |
|
Awesome @drf5n, thanks for the great tips! I modified the code from mk20dx128 to mk20dx256 using the link you provided https://github.com/PaulStoffregen/cores/tree/master/teensy3. I have the Teensy 3.1 hooked up to a stepper motor (I am also using the RAMPS board with a stepper driver) and using Repetier Host, I was manually able to get the motor spinning! I have 3D printer hardware, tomorrow I plan on hooking it up and see if it can 3D print using Teensy3.1 with Teacup Teensy3.1 firmware. @Traumflug, thanks for your help too! Should I write this to the repo? I can create a separate branch for teensy3.1? Also, sorry if I am asking a question that's already been asked. But have either of you or anyone tried the Teacup or Teacup teensy code on a 3D printer? |
Excellent!
Yes, please, to both.
Good question :-) Not me, because I don't own a Teensy. Can't imagine this isn't doable, though. So far I'm not aware of a feature an ATmega has but is lacking on the low end ARMs. |
Cool, so USB communications and digital IO work. How about the ADC? I think I had it working before a kid pulled the usb connector off the board, and I switched to a teensy++2.0
@Traumflug, thanks for your help too!
Sure, write it to the repo. I think Paul Stoffregen's code generalizes the teensy3 & teensy3.1 pretty well. When I did the earlier porting, only the teensy3 existed, so if you've updated the code using the Paul's recent, more general stuff, that's probably the best upgrade for the 3.0 hardware as well. I'm currently running Teacup on a Teensy++2.0--I wanted to play with more IO, and also wanted to be able to try Marlin as well. |
|
Quick question.... is the endstop handling active high or low? I looked through the code and it seems active high but just wanted to make sure... I looked in dda.c and dda.h but I can't seem to find where endstop_stop_cond and endstop_check are initialized. Also, I am testing out the thermistor and I am reading really high values (196 C) at room temperature and I read somewhere someone else had the same issue and they fixed it by reversing the table values in thermistortable.h. What do you guys think? also if I change topics... do I need to post a "new issue"? |
Both, depending on (endstop) hardware and a flag in config.h. See pinio.h for the macros. And yes, this stuff in pinio.h as well as arduino.h & co. is kind of a toll-free hardware abstraction layer.
If you have a thermistor substantially different from the one mentioned in ThermistorTable.h, then, yes, you have to make a different table. A long comment in ThermistorTable-double.h explains how to do it.
Act the way you feel comfortable :-) |
|
The x, y, z are moving in the opposite direction of the the endstops so I inverted the x, y, and z mins but then the X axis was just getting stuck in the middle and wouldn't move past it ( I assume it thinks the middle is the endstop...) I just realized I can set the X_MIN limits in the config file so maybe I need to change that. What I can't seem to figure out is the endstops are not being registered in Repetier Host. I tried using M119 but I get no output.... It should atleast say "x_min: y_min: z_min", right? but it returns nothing. |
This isn't the endstops' fault. You should reverse axis movement direction using {XYZ}_INVERT_DIR in config.h. For testing you can send other commands like G1 without homing. Homing is optional.
This likely means you have no endstop pins defined. Teacup reports only the defined ones (which can be up to six). And the host software has zero business in this stuff. For debugging I actually recommend to use a serial terminal (PuTTY/GtkTerm/CoolTerm) instead of a host to make sure people are concious of what G-code they send and to make sure the host doesn't sent commands on his own. |
|
So when I just move the X, Y, Z manually in Repetier Host, they move in the correct direction -- Right arrow makes X move right, Z up arrow makes Z go up and so on... It's only when I try to test the endstops, they move away from it. So I figured {XYZ}_INVERT_DIR doesn't really fix that problem, right? In the config file, I have: is there another way to define them that I am missing? Great tip, I actually used Tera Term as well but I don't think I saw anything about endstops in there either. But I'll use a serial terminal for debugging from now on. Thanks so much for your help! |
|
That's right, if G0/G1 moves these axes correctly, they should move into endstops correctly, too. A homing movement is an ordinary movement, after all, just with endstop detection turned on.
Is it possible DIO1 resolves to nothing, like #ifdef X_MIN_PIN resulting in false?
No, no, no! Whatever sends G-code doesn't even touch how a firmware works. A host doesn't know and shouldn't care what an endstop even is. Please get rid of the idea these hosts have anything to do with how a firmware moves motors or handles devices. A shell command like this should print a part just fine, including homing, heating and everything involved: Fine :-) My current guess is, the problem is in these macro flags somewhere. Related code is pretty straightforward. M119 is handled in gcode_process.c, about line 600 (search for "119"). Homing code is in home.c and, well, it just sends a number of ordinary movements (enqueue_home(), which is used by enqueue(), as well). However, macro flags and macro functions like X_MIN_PIN and x_min() play a big role and as you don't use arduino.h, it's well possible these resolve other than expected. For debugging I usually insert sersendf_P()'s to figure what's going on. Unless you exhaust the serial line you can send as many messages from firmware as you want. BTW., thanks for all this great work so far! |
|
The pin defining code in https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h should be defining the DIO1* the same as the rest of the pins, and it seems to be working for you for the output side of things. On the input side, I didn't have any endstops while working on the teensy3, so I think the input code may not be well tested. I seem to remember being confused about setting up for internal pullups. ETA: From https://github.com/PaulStoffregen/cores/blob/master/teensy3/pins_teensy.c#L597 it appears that setting an input with pullups is different from SET_INPUT(pin) plus WRITE(pin,1) per https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/mendel.c#L94 and https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/pinio.h#L230 . See also https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h#L57 I don't know if this is causing the issues, but I'm not confident about the translations of the pin input code. |
|
I changed the name and reopened this issue, since the discussion is still open. |
Wait @Traumflug, I am confused... because I thought tera term was a serial terminal.... I mean it can be a host too but I was using it as a serial terminal. Am I mistaken?? But good suggestion :D Using a serial terminal is better for debugging! Well anyway, I used both Tera Term and a shell command like you suggested (cat part.gcode...) and sent M119 and I got the following: in Tera Term: in the command line (I sent the Gcodes G1 X10, G1 Z10, and M119): So, atleast now we know the endstops are being triggered. I also tested all the axes movement using the terminal this time using G1 and they all move in the correct direction (G1 X10 makes it move right, G1 Z10 makes it go up, G1 Y10 makes it move forward and so on...) But it's strange because when the endstops are triggered, it seems that it thinks that the middle of the printer is an endstop... What I mean by that is when the endstops are enabled, X axis won't move past the middle to the left, it just gets stuck in the middle but it freely moves all the way to the right so it seems to me like it thinks it already hit the endstop in the middle.
@drf5n, I am not sure what you mean by this. Also, yeah I was a little confused on the pullups myself. I have a feeling the issue might have something to do with the pullups also. I am gonna dig into the code a bit more and check the macros and see what's going on.
You are welcome, trying my best :) Again, I appreciate all the help!! |
|
After moving into the endstops fast, it should back off slowly, then stop. Apparently, movement code doesn't recognize the endstop was hit and accordingly doesn't complete the endstop search. Odd, because in this area there's no ARM-specific code. Anyways, if one movement doesn't complete, other ones can't be started, so the controller appears to be dead. Endstop detection is done in the first half of dda_clock(). To start searching where things don't complete, I'd add a in dda.c https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/dda.c#L800 to get feedback on wether this detection code is actually reached, wether the endstop is detected and so on. |
|
Hmmm... okay. I've added a couple of print statements in dda_clock and here's what I've noticed. When Z hits the Z endstop, it doesn't back off slowly and then stop, it just stops after it hits it. But I can see that after it hits an endstop, endstop_trigger gets set and goes through the rest of the function just fine. However, when X hits the endstop, I can't see endstop_trigger getting set because the instant X hits the endstop, everything stops. Also, x,y,z started doing that thing again where they don't move past the middle towards the endstops when I try to move them manually. But when I tell them to home, then they all move all the way towards the endstop. I'll try debugging some more in other functions as well. |
|
Hello! I moved on to the extruder heater and thermistor today... In config.h I defined: DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, AIO1, THERMISTOR_EXTRUDER) When I hook up the heater to AIO1 (Pin 15 on the Teensy), I don't see anything when I type M105 in a serial terminal -- it says T: 0... However, when I hook up the heater to AIO0 (Pin 14 on the Teensy), all the sudden it works! I get ~22.75 C which makes sense and when I use the extruder heater and heat it up by using M104, I can see the temperature rising accurately. So why is this? Is it because of this redefinition of TEMP_SENSOR in https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/analog_ARM.c#L28? |
Quite possible. Subtracting one less, like ... - AIO01_PIN ... ? |
|
That's what I was thinking too.... I am very close to getting ready to print for the first time!!!! Hmm.. I am trying to extrude the filament... but it's going the opposite way haha The temperatures aren't showing up in Repetier Host though? It shows as 0 C... but it shows up in a serial terminal. How come? |
Apparently, Repetier can't parse Teacups' response. Perhaps it expects a heated bed temperature, too. Just guessing. Teacups' response format didn't change since Repetier was born, so it's unlikely Teacups' fault. |
|
Oh okay thanks! I finally started to 3d print using Teacup... But for some reason when I print, the extruder retracts the filament so much that the filament comes out. I've tested it without running a print job and it extrudes fine... but when I run a print job, it extracts and retracts filament and that's causing the filament to come out and there's no filament during the print job. Have you heard of this before? I can't figure out if this is a Teacup or a Repeteir Host settings issue. |
|
I think it might be both--sounds like your G-code is sending relative extrusion commands, but the printer is behaving as absolute. I'd check is relative versus absolute extrusion. See https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/config.teensy3.h#L132 and http://reprap.org/wiki/G-code#M82:_set_extruder_to_absolute_mode Maybe your slicer is writing relative, but repetier is initializing with a M82? |
|
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: 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! |
|
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. |
Make sure your max feedrates are set reasonable in config.h. Typical Z axes can do only far less.
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. |
|
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. |
|
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? |
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.
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. |
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...?
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. |
|
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. |
|
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! |
|
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!
|
|
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. |
|
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! |
|
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. |
|
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:
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. |
|
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. |
Sure, I would love to work on this! Just to clarify, do I work on the teensy3.1-refactor branch now? |
|
Re-asking Nikki's question... do I work on the teensy3.1-refactor branch now? |
|
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. |
|
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. |
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
The text was updated successfully, but these errors were encountered: