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

[Traumflug]

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.

[nikkiverre]

Sorry, my mouse went crazy on me for a second...

I used the config.teensy3.h file

[Traumflug]

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.

[nikkiverre]

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?

[Traumflug]

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.

[Traumflug]

Other than that, please keep reporting. Sooner or later this branch should go onto master anyways, so it's better to fix it sooner.

[nikkiverre]

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?

[nikkiverre]

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.

[Traumflug]

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).

[drf5n]

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:

 make -f Makefile-teensy3  teacup.hex 

I just pushed a couple changes to the teensy3 branch to make it compile, using some of the AVR guard logic from https://github.com/Traumflug/Teacup_Firmware/issues/42#issuecomment-45040091 . The following produces some warnings, but compiles:

 make -f Makefile-teensy3 clean all

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

[nikkiverre]

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.

[drf5n]

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.

[nikkiverre]

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?

[Traumflug]

I was manually able to get the motor spinning!

Excellent!

Should I write this to the repo? I can create a separate branch for teensy3.1?

Yes, please, to both.

have either of you or anyone tried the Teacup or Teacup teensy code on a 3D printer?

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.

[drf5n]

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!

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

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?

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.

[nikkiverre]

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"?

[Traumflug]

is the endstop handling active high or low?

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.

I am testing out the thermistor and I am reading really high values (196 C)

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.

if I change topics... do I need to post a "new issue"?

Act the way you feel comfortable :-)

[nikkiverre]

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.

[Traumflug]

The x, y, z are moving in the opposite direction

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.

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 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.

[nikkiverre]

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:

define X_MIN_PIN DIO1

define Y_MIN_PIN DIO2

define Z_MIN_PIN DIO3

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!

[Traumflug]

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.

define X_MIN_PIN DIO1

Is it possible DIO1 resolves to nothing, like #ifdef X_MIN_PIN resulting in false?

I actually used Tera Term as well but I don't think I saw anything about endstops in there either.

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:

cat part.gcode   > /dev/ACM0

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!

[drf5n]

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.

[drf5n]

I changed the name and reopened this issue, since the discussion is still open.

[nikkiverre]

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.

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: ok x_min:triggered y_min:triggered z_min:triggered

in the command line (I sent the Gcodes G1 X10, G1 Z10, and M119): ok ok ok ok ok x_min:triggered y_min:triggered z_min:triggered ok ?O??K?ok ok ?O??K?ok ok ?O??K?ok ok ?O??K?ok ok ?O??K?????O????????K?????O??K?ok ok ?O??K?ok ok

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.

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...

@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.

BTW., thanks for all this great work so far!

You are welcome, trying my best :) Again, I appreciate all the help!!

[drf5n]

Does M119 report different results when you change the physical state of an endstop manually, or do they always report 'triggered' by the software no matter whether they are physically triggered or not. Electrically, does the voltage on the signal pin change as expected when you toggle the endstop?

@drf5n, I am not sure what you mean by this. Also, yeah I was a little confused on the pullups myself. I have them enabled right now.

I mean I think I have appropriate code defining the individual pins properly in lines 105-409 and 447-598 with each pin following a template that matches the rest of the pins. What I'm unsure of is whether this scheme used for the AVRs:

 SET_INPUT(pin) ; WRITE(pin,(internal_pullup_flag?1:0));

... produces the expected result. Based on line 59 at https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h#L59 , it looks like SET_INPUT() clears the DSE (Drive Strength Enable) bit and the Slew Rate Enable bit that the SET_OUTPUT(pin) enables.

Perhaps if it is only pulling up weakly (DSE=0), it isn't pulling up enough to change the state.

dig dig.... on an old K20 datasheet "Document Number: K20P64M50SF0 Rev. 4 5/2012" page 13, it says the K20s can output 9mA in high drive strength mode, and 2mA in low drive strength mode.

If the signal pin voltage changes reasonably when physically toggles, I'd guess the internal (or external) pull-up is working properly. If so, and the m119 doesn't change in step with the electrical, I'd try blame my SET_INPUT()\ and try writing SET_INPUT_PULLUP() and _SET_INPUT_PULLUP() with the proper set of flags and comment out the WRITE(pin,?) bits.

\ Or maybe blame READ(pin)? I didn't re-implement READ(), and the default behavior looks different than https://github.com/PaulStoffregen/cores/blob/master/teensy3/pins_teensy.c#L592

[nikkiverre]

Does M119 report different results when you change the physical state of an endstop manually, or do they always report 'triggered' by the software no matter whether they are physically triggered or not. Electrically, does the voltage on the signal pin change as expected when you toggle the endstop?

They are always reporting 'triggered' whether I physically trigger them or not. Electrically, I measured the voltage on the signal pin when the switch is not triggered and it was reading 5 volts and when I pressed the trigger, it went down to 0.01 - 0.03 volts.

[drf5n]

5V? Is it externally supplied? From https://www.pjrc.com/teensy/teensy31.html it looks like Teensy 3.1 tolerates 5V inputs, but I'd guess it only drives at 3.3v. You shouldn't need USE_INTERNAL_PULLUPS if it is externally supplied by 5V.

I'd blame my non-reimplementation of the _READ() macro.

[nikkiverre]

So I commented out enable pullups and uncommented the axis limits:

define X_MIN 0.0

define X_MAX 180.0

define Y_MIN 0.0

define Y_MAX 180.0

define Z_MIN 0.0

define Z_MAX 140.0

Now M119 returns ok x_min:open y_min:open z_min:open but when I manually trigger the endstop, it doesn't say trigger it still says open.

But then I made X go home and it moved in the correct direction!!! I need to test the other axes, I'll update once I do. But the only thing now is that once it hits the endstop, everything stops working. Teensy doesn't get enumerated as a COM port when I connect it now... It seems to be stuck or hung up because it hit an endstop? I am not sure...

[Traumflug]

Wait @Traumflug, I am confused... because I thought tera term was a serial terminal....

You're entirely right. Perhaps I'm a bit haunted by the german RepRap forum where everything gets discussed and tried as long as its based on misunderstandings. They talk like "Careful investigation? Reliable tools? No way, you jerk, the other stuff looks much nicer!" Ha ha

ok x_min:triggered y_min:triggered z_min:triggered

You see? There's your M119 response. :-)

Now, with all of them triggered, having axes moving (slowly) backwards is expected. To search the endstop, an axis moves quickly positive until it hits the endstop, then pulls back slowly until it's released. The latter is for more precision. You saw the pulling backwards part only.

BTW, the Teensy 3(.1) branch doesn't have adaptive homing speed, yet, so endstops are searched at maximum speed and might crash into these mechanically. Rebasing these branches to current master would fix this.

When you get stuck with endtop searching somewhere, hitting the reset button should reset endstop searches, too. At least on non-USB chips, serial stuff is entirely independent, in its own interrupt.

[nikkiverre]

Now, with all of them triggered, having axes moving (slowly) backwards is expected. To search the endstop, an axis moves quickly positive until it hits the endstop, then pulls back slowly until it's released...

So, that's the behavior I was expecting but that didn't happen. Once an axis hits the endstop it just stays there and everything gets stuck. Especially when I try to home Z, it's like a woodpecker. The switch never seems to get released after it hits it. Is it because of what you mentioned about "Teensy 3(.1) branch not having adaptive homing speed, yet, so endstops are searched at maximum speed and might crash into these mechanically?"

Earlier I had pullups enabled so when I did M119 in the terminal I was getting that they were all triggered whether they were triggered or not. Now, I disabled the pullups and when I do M119, they all show as open even when they are triggered. So, I think the issue is when a switch does get triggered, it's not being registered as triggered. But atleast the axes move towards the endstops now :)

[Traumflug]

Is it because of what you mentioned about "Teensy 3(.1) branch not having adaptive homing speed, yet, so endstops are searched at maximum speed and might crash into these mechanically?"

Unlikely. The previous behaviour worked the same, it just moved too fast. It tried to decelerate, but didn't take the distance to do so into account.

To me it looks much like you have an electrical or pin configuration problem. When a pin always reads the same, one can't expect a software to recognize a mechanical status change. I'd start with replacing these endstops with mechanical ones (plain switches) or putting a voltage divider (two resistors) in between to get the signal down to 3.3V.

[nikkiverre]

The weird thing though is when I measure the voltage across the pin it's 5 V when it is not triggered and then goes down 0.1 volts when the endstop is triggered... so it seems like they are working fine, but then I don't understand why the software can't pick up that mechanical change. But perhaps I should trying adding a voltage divider in between like you said.

[triffid]

On 25 July 2014 03:07, nikkiverre notifications@github.com wrote:

in Tera Term:

ok x_min:triggered y_min:triggered z_min:triggered

in the command line (I sent the Gcodes G1 X10, G1 Z10, and M119): ok ok ok ok ok x_min:triggered y_min:triggered z_min:triggered ok ?O??K?ok ok ?O??K?ok ok ?O??K?ok ok ?O??K?ok ok ?O??K?????O????????K?????O??K?ok ok ?O??K?ok ok

fwiw, that looks like you have echo turned on. you definitely want to turn that off, or it'll just bounce OKs back and forth indefinitely and interfere with other communications!

you might also like to enable XON/XOFF flow control which teacup uses in addition to reprap-style gcode flow control :)

[nikkiverre]

@triffid, thanks for the tip!

I didn't re-implement READ(), and the default behavior looks different

@drf5n, I'm gonna try and reimplement the READ macro in https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h#L59 and see if that fixes it. Maybe it's just not even reading the pin in the first place.

[drf5n]

Before I'd re-implement it, I'd try expanding the components of _READ() explicitly in the M119 code with some sersendf_P() of DIO1_RPORT DIO1_PIN, CORE_PIN1_PORTREG, CORE_PIN1_BIT...

it looks like Pauls' digitalRead() code is using the bit-band registers where there are a set of control bytes for set aside in the larger address space for each pin, while the bit-banging register stuff used by _READ() like it is defined around https://github.com/PaulStoffregen/cores/blob/master/teensy3/core_pins.h#L108 and https://github.com/PaulStoffregen/cores/blob/master/teensy3/core_pins.h#L178

[nikkiverre]

Okay yeah, I am glad you mentioned that! That's exactly what I was trying to do. I think to read an input pin, you first need to set it as GPIO, set the direction of the pin in the DDR register (in our case 0 which it defaults to I think), and then we can read from the Data Input Register (PDIR). But I am getting confused by all the abstraction, it's hard for me to tell where this is all happening.

Please correct me if I am mistaken. Since our X_min pin is an input, we wanna read from the PDIR register: (https://github.com/PaulStoffregen/cores/blob/master/teensy3/core_pins.h#L318). GPIOB_PDIR is defined as CORE_PIN1_PINREG. But in (https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h#L59), DIO1_RPORT is defined as CORE_PIN1_PORTREG. Shouldn't it be defined as CORE_PIN1_PINREG instead?

[Traumflug]

I am getting confused by all the abstraction, it's hard for me to tell where this is all happening.

In the "build" directory you should find .i files (generated at build time), which is C code after preprocessing, before compilation. Not that this is always easier to understand, but it sometimes helps. :-)

[drf5n]

I think you might have it right.

Maybe https://github.com/Traumflug/Teacup_Firmware/blob/teensy3.1/arduino_teensy3.h#L94 should be:

define DIO{x}_RPORT CORE_PIN{x}_PINREG

define DIO{x}_WPORT CORE_PIN{x}_PORTREG

...and then do the python to regenerate the defines.

Sorry about that.

[nikkiverre]

Okay cool. Oops, I didn't realize there was a python code to generate the defines. I just manually changed them all haha.

So, I added sersendf_P({DIO...REG...}) in the gcode_process.c under M119 to print out all the registers... But nothing is printing out anymore, everything is blank when I type M119. Did I miss something?

[drf5n]

I did it manually a few times, then decided to write a program to make my mistakes much more quickly.

What syntax? I'd pick the particular pin for your xmin, and write something like:

sersendf_P(PSTR("DIO1 registers: %lu, %lu ...\n"),DIO1_RPORT, CORE_PIN1_PINREG);

[nikkiverre]

sersendf_P(PSTR("DIO1 registers: %lu, %lu ...\n"),DIO1_RPORT, CORE_PIN1_PINREG);

Cool thanks!

OMG, finally after redefining the DIO{x}_RPORT to CORE_PIN{x}_PINREG, it's working!! When one of the endstop is not triggered, M119 status shows as triggered and when I press the trigger, M119 shows the status as open. Yay!!

I'm gonna home and see what happens. ETA: Now, they are moving the opposite direction of the Endstops again so I think I would need to invert the logic.

Thanks for helping me along the way everyone :)

If the endstops work, next piece of puzzle is the thermistors. Then I can start 3D printing!

[nikkiverre]

Hmm okay so now, the software picks up the mechanical change of the endstops and they move in the correct direction. The Z axis endstop works fine. But when the X axis hits the endstop, it just gets stuck there and seems like everything crashes. I can't move any of the other axes and nothing works after X hits an endstop, You guys have any idea what's happening?

[Traumflug]

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

sersendf_P(PSTR("endstop hit\n"));

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.

[nikkiverre]

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.

[nikkiverre]

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?

[Traumflug]

However, when I hook up the heater to AIO0 (Pin 14 on the Teensy), all the sudden it works! [...] 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 ... ?

[nikkiverre]

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?

[Traumflug]

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.

[nikkiverre]

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.

[drf5n]

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?