Traumflug / Teacup_Firmware

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

Turn-on motor enable #108

Open whittenjaw85 opened 9 years ago

whittenjaw85 commented 9 years ago

I noticed that there is a configuration void io_init() function in the mendel.c file that could use an update. On startup, I want to disable my stepper motors, in general, because they are not controlled by a PSU interface pin. Whenever, I powered the device, the motors would hum wildly. After digging through mendel.c, I found the io_init() function to be the culprit.

My enable pins for the stepper drivers are enabled low, so I defined #define X_INVERT_ENABLE and in general a STEPPER_INVERT_ENABLE.

Within the io_init() function, the lines checking for invert do something like this:

ifdef X_INVERT_ENABLE

WRITE(X_ENABLE_PIN, 0);

else

WRITE(X_ENABLE_PIN, 1);

endif

SET_OUTPUT(X_ENABLE_PIN);

I changed all the #ifdef to #ifndef and it works fine now on startup to not power the stepper motors.

I encourage your team to disable devices on startup. Everything works well othewise. Thank you for your contribution. You've saved me a ton of time.

I'm using a AT90USB646 and have defined an arduino_usb646.h file if anyone wishes to have it.

Thanks,

Jonathan Whitten

mattgilbertnet commented 7 years ago

Thanks for this. I had this whining at startup issue with an Arduino Uno-based setup. Making these changes to pinio_init() in pinio.c got rid of the startup whine. The motors still whine for a while once it's stopped after a movement. Teacup leaves the enable pins high for about half a minute after it comes to a stop, apparently. I'd like to get rid of that whine too, but I suppose it's only an issue when sending commands one at a time, rather than while printing.

phord commented 7 years ago

Disabling motors on startup might allow some mechanics to slide when disaster strikes. When the controller resets due to brownout or some code error, for example, the motors might suddenly become unpowered and allowed to drift or continue in the direction they were headed. Maybe this is not so bad because a reset during a print might be followed up my more movement commands, causing the motors to be enabled. But maybe the sender will be confused by our new state and will know to stop sending commands.

So, I don't know the right thing to do here, but this seems like the wrong thing in the general case. Maybe there should be a new ENABLE_AT_STARTUP definition added which could control this feature, though. Seems like a reasonable thing to do on normal startup.

phord commented 7 years ago

@mattgilbertnet If your motors are whining you might have too much power going to them. It's a delicate balance to try to achieve. If your motors do not get hot when left powered for 10 minutes or so, you're probably ok. But if they do get warm you might shorten the life of the motors or start to melt your printed components when they get too warm.

mattgilbertnet commented 7 years ago

Good points phord. My current was set way too high, mainly because I started out using some very old firmware (not Teacup) that had no accelleration implementation, and so it needed more current to work at all. Already the switch to Teacup is a huge improvement!