darwin dc motor won't turn

hey guys!
I have almost succeeded building a fully functioning Darwin printer,but I have a problem.

the dc motor i use for the extruder won't turn when i try to print,although the 240 target temperature is achieved.

I've already tried testing it with the sample code given in this wiki page:
(dc motor test wiki)
for the arduino 0015 I'm using.
I'm using Gen 2 electronics, a dc motor driver v1.1 board and reprap host.

I'v tried using the test mode in the arduino and get nothing.

my Gcode_Interpreter has been downloaded from Gcode interpreter

can anyone help?I'm so eager to start printing!

Edited 5 time(s). Last edit at 06/22/2010 03:07PM by asaf.

Got a green light on your motor board? How about voltage on the arduino pin? Check your pin defines too, maybe it's set up to use a different pin.

Wade

I do get a green light on the dc motor board,but no voltage in the the pin on the main board for the motor speed though.
pins are correct,triple checked them.

Clarification: The green light is for the power. the green LED for the output does not light up.

I think something in the firmware is stopping it from running (no voltage on PWM pin, both with normal and test modes) but I can't think what it could be. does anyone have any ideas?

Edited 1 time(s). Last edit at 06/21/2010 11:43AM by asaf.

If there's no voltage at the pin on the Arduino, it must be a programming error. Try changing the pin to a different pin in the test code, and see if you can get a different pin to work.
Could be that pin was damaged somehow.

Wade

i've tried using all avalible pins and got nothing.

pretty sure it's something in the Gcode but i cant find out what it is.

the thing is the board and motor works great when simply tested using the wiki code but doesn't work using the arduino test or with reprap host.

i hope someone here can help my figure it out.

The firmware won't move if it thinks the endstops are triggered. Have you got anything connected to the endstop inputs?

---

[www.hydraraptor.blogspot.com]

Hi Everyone,

I'm working with Asaf on this printer.

Following nophead's comment, I have a question and an idea which I would like to bounce off you guys:

The question:
Do the endstops indeed control the bahviour of the extruder motor? (We'll verify this tommorow by reading the code)

If this is indeed the case:

The endstops we got from the RRRF for this printer WERE INVERTING.

The MIN endstops work fine, and the MAX endstops are not installed

Could it be that the extruder motor won't turn because it thinks the the MAX endstops are triggering? Could the safty check on the MAX endstop perhaps not take into account the "INVERTING_ENDSTOPS" flag?

Again we will look into this tommorow.

BTW:
What is the correct way to simulate a triggered inverting endstop? currently the MAX endstops pins are open, so I should think I need to short them, but should I use a ressistor?

Sorry I forgot you were talking about the extruder. The usual reason for that not working is the heater has not reached the target temperature because it would break the extruder if it ran before the plastic melted.

---

[www.hydraraptor.blogspot.com]

Right now we hit ramp on rxtruder tab, and we can see the temperature rising slowly (according to the ramp rate) to the target temperature, which we set in extruder tab (not the preferences page). The temperature then holds at that temperature +-8 degrees.

Is it possible that the arduino either has a different extruding temperature set, or that it is seeing a different temperature?

-Leav

It sounds like an issue similar to one I had a little while back. It boils down to an issue with the step_en_pin setting.

There's a bit of an explanation about it here: [dev.forums.reprap.org]

i've been exploring in that direction and that thread is really helpful.

i tried commenting the if statement and it didn't work.

i will try the if statement they suggested.

i have another question:

in this line

#define EXTRUDER_0_STEP_ENABLE_PIN -1 (in the pin.h tab)

does the -1 need to be assigned as a byte?

in my gcode interperter it doesn't and i dont know if that's a problem.

i've made these changes

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)

in order to try and solve my problem

Here's what I've got in my code, as taken from a modified version of GCode_Interpreter Stephen George posted on another thread that I can't seem to find.

// DC motor?

/*
Notes

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 ) { ...}
(source [dev.forums.reprap.org])
*/


/* original code

if(step_en_pin < 0)
{
e_speed = (byte)sp;
if(e_speed > 0)
wait_for_temperature();
analogWrite(motor_speed_pin, e_speed);
return;
}

*/

/* Just removed the if completely */



As for the (byte) designation, it seems to work (to an extent) without it. I say to an extent because I've got mine where it works fine in the Arduino testmachine and responds to codes in a debug screen, but the extruder fails to twitch in the RepRap host. I'm fairly convinced though that if the (byte) were necessary, it wouldn't work at all in the testmachine.

Still working on it...

tried removing the if and changing into when i wrote above,
and got nothing.

the next step is tracking the code step by step following the step_en_pin path,see what i yield there.

any other suggestions regarding the code are welcomed

Edited 1 time(s). Last edit at 06/26/2010 04:55PM by asaf.

As I said, I am working with Asaf on this. here is where we are now:

changed the set_speed function in the following way:

• Removed (commented out) portions regarding stepper motor. (for clarity)
• Commented out wait_for_temperature() (for testing).

Here is the code now:

void extruder::set_speed(float sp)
{
      e_speed = (byte)sp;
      if(e_speed > 0)
          //wait_for_temperature();
      analogWrite(motor_speed_pin, e_speed); //analogWrite(motor_speed_pin, e_speed);
      return;
}

Now testing with #define TEST_MACHINE produces the following results:

• The motor works! YAY!
• The motor does not not stop when the command set_speed(0) is issued. yay? :-\

if anyone has any idea why this is I would like to know.
I don't think wait_for_temperature(); has a problem, but bypassing it allows me to make sure it is not causing any.

now that the safety has been bypassed I rushed over to the Darwin host, ramped the temperature up to 220c, changed the speed to 220, and clicked the extrude button (on the extruder tab), and got...... Nada, Nothing, Zip and also Zilch.

In my desperation I turned to FreeSerialPortMonitor to spy on the communication between the arduino and the Host software and noted that a command was indeed being issued when I hit "Extrude", but it wasn't the one I was expecting.
the command was:

Request: 27/06/2010 18:22:12.26364 (+0.0000 seconds)

 47 31 20 46 33 30 30 30 2E 30 0A                  G1 F3000.0.     

Answer: 27/06/2010 18:22:12.26364 (+0.0000 seconds)

 0A 6F 6B 0D                                       .ok.            

Request: 27/06/2010 18:22:12.29564 (+0.0000 seconds)

 47 31 20 45 31 38 2E 33 0A                        G1 E18.3.       

Answer: 27/06/2010 18:22:12.29564 (+0.0000 seconds)

 0A 6F 6B 0D                                       .ok.            

Request: 27/06/2010 18:22:12.32664 (+0.0000 seconds)

 47 31 20 46 31 35 30 30 2E 30 0A                  G1 F1500.0.     

Answer: 27/06/2010 18:22:12.32664 (+0.0000 seconds)

 0A 6F 6B 0D                                       .ok.

And cleaned up:

Request: G1 F3000.0.     

Answer: .ok.            

Request: G1 E18.3.       

Answer: .ok.            

Request: G1 F1500.0.     

Answer: .ok.

Subsequent Requests do exactly the same, except they change the value for E:
E36.7
E55.0
E73.3
E91.7
(as you can see the difference is always aprox. 18.3)

Shouldn't the software be issuing M commands?
specifically either M101, or M102 - as specified in the process_string part of the firmware:

				//turn extruder on, forward
			case 101:
				ex[extruder_in_use]->set_direction(1);
				ex[extruder_in_use]->set_speed(extruder_speed);
				break;

				//turn extruder on, reverse
			case 102:
				ex[extruder_in_use]->set_direction(0);
				ex[extruder_in_use]->set_speed(extruder_speed);
				break;

And try as I might, I can not find a place where the code interperts a command like G1 E***
You can check out the process_string code here:
[pastebin.com]

To summarize:
I think I need to find a way to tell my RepRap host software I'm not using the 4D firmware..... am I right?

Any insight would be greatly appreciated from sages such as yourself (I'm practically grovelling here folks.... )

-Leav

The reason the motor does not stop is because you commented out the line after the if(), so the next line becomes the thing that is conditionally executed. I.e. you have created :-

void extruder::set_speed(float sp)
{
      e_speed = (byte)sp;
      if(e_speed > 0)
            analogWrite(motor_speed_pin, e_speed); //analogWrite(motor_speed_pin, e_speed);
      return;
}

Indentation is irrelevant in C and C++.

Yes you will need to change the preferences in the host to not send 5D code. I don't know where it is exactly because I don't use any of this stuff myself.

---

[www.hydraraptor.blogspot.com]

thanks nophead! my recent love affair with python must be getting to me

I'd appreciate any help regarding the preferences file! does anyone have a clue about this?

They're located at reprap.properties.dist in the reprap folder in windows or a similarly named file in the same folder in linux.

Check and make sure that the changes you make to that file occur in the preferences tab in your host program as well.

and finally all the pieces fall into place.

I was using:
reprap-host-windows-20090804

which (mercifully) does not have a reprap.properties.dist file.

I just happened to have:
reprap-host-windows-20081218

which I found when searching for "reprap.properties.dist" and this successfully turns the motor!

3 cheers for legacy software!

and ofcourse for everyone who helped us out along the way!

Hopefuly this will all turn out ok now... *crossing fingers*

This .dist file is just the defaults to use when it is run for the first time. You should change properties using the GUI menu and not worry where they are stored.

---

[www.hydraraptor.blogspot.com]

so this was just pure luck?

where are the preferences stored, by the way?

Every version of the reprap host software since at least 27 May 2006 has had a reprap.properties.dist file.

In released versions, it is (or should be!) found inside the reprap.jar file (which is a zip format archive, as are all .jar files, but please do not change anything inside there unless you really know what you are doing with .jar files).

When a user makes a change to any property in the reprap host software, and saves the change, the software creates a file called reprap.properties which is saved where Java thinks per-user per-application properties files should be on your system.

On Unix-like OSes (Linux and OS X for example) this is under ~/.reprap/ -- that is, in a directory called .reprap in your home directory. In Windows-like OSes it puts these files somewhere else, maybe under C:/Documents and Settings/USERNAME/Application Data/ or somewhere like that. Windows Vista and Windows 7 are, I think, different from Windows 2000 and Windows XP in this respect. Searching for files named reprap.properties should find it, under any OS, including Windows.

If a user really messes up their preferences, or gets confused and changes things and then forgets what they changed, it can be useful to exit the reprap host software, delete this file and then start the host software, to "start over" with the default properties.

To allow current reprap host software to talk sensibly to a "3D" Gcode microcontroller, set the property FiveD to false . It defaults to true, because 5D firmware is the current default RepRap firmware. This property is the 17th one in the first column of properties in the "Globals" tab of the Preferences dialog. Properties are displayed in alphabetical order in this screen, so once you know the name of the property you wish to change, finding it is fairly simple.

This particular property is documented on the wiki page that describes all of these properties, specifically see http://reprap.org/wiki/Java_Software_Preferences_File#FiveD.3Dtrue .

Bottom line: I recommend that you set this parameter, and do not use old versions of the host software.

I hope this helps explain what you have discovered "the hard way"

---

---

Jonathan

Jonathan,


First, thank you very much for the comprehensive explanation about the properties file.

Regarding the FiveD flag....

Quote
Jonathan
I hope this helps explain what you have discovered "the hard way"

I'm hard pressed to imagine anyone finding out about this in a more convoluted way, but at least I've learned a whole lot!

I'm still skeptic about my host software containing that preference... it's just too easy

Again thanks for your help at pointing out the proper solution!

-Leav

Funny Thing happend... I opened up the newset host software and it did not have the FiveD setting.
I don't mean that it was false, it was simply not there!

Thanks to Jonathan's explanation I immediately traced this back to the properties file... I deleted it and bang: the FiveD parameter appeared!

i think this should maybe be classified as a bug? the software should know about old properties files and not use them... certainly the functionality where properties are completely left out if they do not appear in the old properties file is not a feature, but a a bug - right?

Correctly upgrading properties files as the software changes is a relatively awkward problem in some circumstances, and the workarounds are straightforward (delete the file, or use a text editor to manually merge new stuff into the old one, if you need to keep your old settings values intact). So the reprap.org team did the obvious thing: ignored it completely Yes, this could be considered a bug.

---

---

Jonathan