Teacup does not seem to notice limit switches

Hello everyone, I'm new here,

I have an issue with using the Teacup firmware for my small cnc mill. I got all the motors working correctly, I can control my machine from ReplicatorG, but unfortunately my machine does not respond to limit switches.

I'm using an Arduino Uno, from which I assign the digital ports to the direction/step/enable pins for the stepper drivers and I use the 6 analogue ports on my Arduino for the six limit switches I have installed. (using pull-down resistors)

Before using teacup I had another firmware that worked properly with limit switches. To be sure, I measured the pins on my Arduino using a multimeter, no problems there.

I played around with the settings but nothing seems to help.

I've attached the config.h file with my settings.

Can someone help me?

To make matters even more complicated, one of the digital pins was not working correctly (the x-axis only moved in one direction which suggested that the direction pin (pin11) was not working, I used another digital pin that happened to be available and it fixed the problem! Maybe this has something to do with my other problem?

Excerpt from the config file:

Quote
config.h:
#define X_STEP_PIN DIO12
#define X_DIR_PIN DIO3
#define X_MIN_PIN AIO5
#define X_MAX_PIN AIO4
#define X_ENABLE_PIN DIO10
//#define X_INVERT_DIR
//#define X_INVERT_MIN
//#define X_INVERT_MAX
//#define X_INVERT_ENABLE

#define Y_STEP_PIN DIO9
#define Y_DIR_PIN DIO8
#define Y_MIN_PIN AIO3
//#define Y_MAX_PIN AIO2
#define Y_ENABLE_PIN DIO7
//#define Y_INVERT_DIR
//#define Y_INVERT_MIN
//#define Y_INVERT_MAX
//#define Y_INVERT_ENABLE

#define Z_STEP_PIN DIO6
//#define Z_DIR_PIN DIO5
#define Z_MIN_PIN AIO1
//#define Z_MAX_PIN AIO0
//#define Z_ENABLE_PIN DIO4
//#define Z_INVERT_DIR
//#define Z_INVERT_MIN
//#define Z_INVERT_MAX
//#define Z_INVERT_ENABLE

I dont know the exact problem so i am fishing here. If you start with sending a "G161 X Y Z" line, does that seem to fix it? Its how it discovers the endstops, then stores the position for followup homing commands. It doesnt actually use the physical endstops outside this command, which is a good thing coz this way endstops cant possibly bring up any trouble during a print e.g. "they arent there". Also no need for uC to "watch out" for them constantly. If the G161 is never used then i guess the position zero is considered wherever the printer is at power up. Movement should work from that position within the boundaries of size defined in config. This way you can offline move it at start place 0,0,0 and as long as you know your limits, you can print without endstops at all. If thats the cause, then you either need to manually send a G161 X Y Z each time you start up printer, or have it in start of the gcode file. Would be pretty simple if its only this.
Another potential issue if the axes are moving only in one direction and perhaps slower than normally, it could be the inverting status of your endstops is the other way around. Something like the endstop is always triggered, and the printer just tries to get away from it. Easy to give it a try the other way around to check if it works out.

Quote

my machine does not respond to limit switches.

It doesn't respond to limit switches when moving with G0/G1? That's expected; endstops are used for homing, only.

Three possible solutions:

- Take it as is, proper G-code won't make the machine hit the limit switches anyways and if you hit the limits, your milling is hosed, anyways. The latter is the reason why endstops are ignored, asking them takes time and reduces the possible maximum speed.

- Use soft limits. Watch out for X_MIN, X_MAX, YMIN, ... in config.h. Defining them will limit any G-code sent to the controller to be within the limits.

- Hack Teacup. Endstop support is there for homing already, just not used. If you do, please wrap the new code in #ifdefs, so this feature is optional.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for your suggestions, it makes sense for the micro controller to ignore limit switches as this requires additional processing time. I will try the homing command, see if it reacts to the switches.

Again thank you, I will try the suggestions on monday and will get back to you with the result.

To just test the switches, there's the M200 command. 0 means untriggered, 1 means triggered. Can be inverted in config.h.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hello, just to get back on you, I tried the M200 command and I got the reading that the switches were all '1' so I inverted them in the firmware. When I try homing the switches work perfectly!

However, when I tried to mill a simple packman-like figure the cnc started acting strange. Turned out that the firmware does not support arcs, which is kind of sad. In the list of firmware (http://reprap.org/wiki/List_of_Firmware) it suggests that it is compatible with cnc-milling, and solidcam does not have a kind of on/off swith for arc g-code so I ended up flashing GRBL to my Arduino and this worked fine.

Anyway, thanks for the help!

Quote

Turned out that the firmware does not support arcs

Implement it! It's open source.

In the list of firmware (http://reprap.org/wiki/List_of_Firmware) it suggests that it is compatible with cnc-milling

It is. If SolidCAM can't produce proper G-code, it's their problem. Teacup doesn't support splines either.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY