extruder::set_speed() crashes with DC motor.

I've been having trouble with the Arduino crashing (fails to respond to commands) after I send an extruder on or off command. It doesn't happen every time, I'd estimate about 50% of the time. So, if I try to cycle the extruder on and off twice from the extruder exerciser in the host software it will usually stop responding to commands.

I've turned on comm debugging. When I get a crash I no longer receive "GCode acknowledged". Also after the crash, anytime I try to send a command I don't get the Tx/Rx LED flashes I normally get.

I also can't turn the extruder on even if I get lucky and the board responds with "GCode acknowledged".

I'm not sure how to debug the Arduino, but by adding return statements in strategic spots I was able to narrow it down to the extruder::set_speed() function. When I put a return after the "if (step_en_pin < 0)" block I no longer get crashes, but the extruder still doesn't turn on. Removing the if statement altogether (leaving the block after it) gets everything working correctly. For some reason the execution is taking a wrong turn here.

Near the end of pins.h I have

#define EXTRUDER_0_STEP_ENABLE_PIN  -1

I am worried there is something improperly overwriting memory. Any idea how this happens?

I have an Arduino Duemilanove with an Atmega 328. I program it with Arduino - 0014 on a Windows XP system. I run the host software on Ubuntu installed from the LiveCD.

the problem is that step_en_pin is set to (byte)-1, which by the time it reaches the if() is actually calculated as 255, si changing the 'if' statement to this works:
if( step_en_pin < 0 || step_en_pin == 255 ) { ...}

I figured this out yesterday.

I also discovered that there are a bunch of sanguino-only interrupts in extruder.pde that should not be running, but are. :-(
These can be fixed by un-commenting a couple of commented lines:

change
//#ifdef SANGUINO
to
#ifdef SANGUINO

Buzz.

Edited 1 time(s). Last edit at 03/22/2009 09:20PM by buzz.

Just to check, theres 2 instances of a check on step_en_pin in the extruder sketch:
if( step_en_pin < 0)
and
if(step_en_pin >= 0)

so
if( step_en_pin < 0)
becomes
if( step_en_pin < 0 || step_en_pin == 255 )

and
if( step_en_pin >= 0)
becomes
if( step_en_pin >= 0 && step_en_pin != 255)

correct?
Good spot with the commented out sanguino lines btw :-)
Ralph

Has anyone managed to get a dc motor-driven extruder working with the newer firmwares? Without the fixes listed above, I can see an led on the motor speed pin flash very quickly, so it thinks its driving a stepper. With the fixes, nothing happens on the motor speed pin. If anyone had any ideas they would be very much appreciated.

James

Firstly, you need to define "newer firmwares"? ( do you mean the FiveD_* firmware? )

If you are Still refering to the pre-FourD/FiveD "standard" GCode based formware, then my answer is Yes and No....

I do have a DC-motor driven extruder, but not the original "threaded rod" extruder. I'm using a DC-motor + encoder-wheel + pinch-wheel, and my system is working just fine..... but my firmware is increasingly further from "standard", as I've hacked it around a lot now ( in the last couple of months). :-) I'll happily share, if you are interested.

eg: my encoder is connected to an interrupt line, I've added a simple one-line interrupt handler for this ( I'm not doing full quadrature anymore, as it's overkill for a motor that always goes one way), and my DC motor is over-powered/over-speed for it's current usage, so I have to artificially slow it beyond normal PWM capabilities by using longer self-generated PWM-like pulses of 100% power to overcome the motor stall inertia. it sounds harder than it really is.
Oh, and my stepper drivers are non-standard too, but that's not so relevant here.

Buzz.

I'm trying to use the non-5D latest gcode firmware from svn. I'd be interested in your current firmware, because adding an encoder is on my todo list.

James

When I last updated the host software my extruder motor stopped working. I tracked it down to a variable in the configuration file (something like ~/.reprap/reprap.preferences) I added the following line:

FourD = true


There is some encoder code here: [forums.reprap.org]

It might also be EMI. DC motors are known for their interference on other equipment. I placed ferrite beads on the leads that go to the motor. Now I switched to a stepper motor extruder, however. It reduces the need for an encoder (simple open loop).

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]