After spending a few weeks with a defective Melzi board, I changed to RAMPS 1.4 from reprapdiscount.
It's installed and it wants to print, but the motors are clearly not set up correctly. The print head goes through the motions, but it moves veeeryyy slowly, and it doesn't move far. It's like everything is compressed. My practice parts are look like blobs of chewing gum from the bottom of a table.
I think the new drivers (on the RAMPS) need different settings. When I manually move an axis 100 mm, it moves about 15mm. And again, it's slow.
For two days, I've studied the firmware files, but I just don't know where to go or what to do. The RAMPS drivers are jumpered for 1/16 steps.
What do you have in your config.ini of your firmware? Important things are:
#define DEFAULT_AXIS_STEPS_PER_UNIT {22.222, 22.222, 2590, 781} *<-- X Y
Z and E values, found via calculation and tuning (these are mine). This
may be your issue with not moving 100mm when you ask it to move 100mm*
*
*
#define DEFAULT_MAX_FEEDRATE {500, 500, 3, 1200} *<-- X Y Z and
E values, maximum mm/s that they can travel. Whichever is smaller between
this number and the feedrate as defined in pronterface is your maximum
speed that it will move*
When it moves "15mm" instead of 100, does it reliably move 15 every time,
or does it sometimes move 14.9 and sometimes 15.5? If it is reliably 15,
then you need to change your steps_per_mm. The calculation here is 100/15
* 22.222 where 100 is how far you asked it to go, 15 is how far it went,
and 22.222 is the current value in *your *steps_per_unit, which is probably
different than mine!
If it is not reliable, then it is probably something hardware-related.
Before trying to print something (and getting very frustrated), you should
first calibrate everything. Then calibrate again, and finally once more
for good luck and *then* try to print something. A good calibration set of
steps is here: reprap.org/wiki/Calibration
On Tue, Nov 13, 2012 at 2:45 PM, seatlanta <hyd...@gmail.com> wrote:
> After spending a few weeks with a defective Melzi board, I changed to
> RAMPS 1.4 from reprapdiscount.
> It's installed and it wants to print, but the motors are clearly not set
> up correctly. The print head goes through the motions, but it moves
> veeeryyy slowly, and it doesn't move far. It's like everything is
> compressed. My practice parts are look like blobs of chewing gum from the
> bottom of a table.
> I think the new drivers (on the RAMPS) need different settings. When I
> manually move an axis 100 mm, it moves about 15mm. And again, it's slow.
> For two days, I've studied the firmware files, but I just don't know where
> to go or what to do. The RAMPS drivers are jumpered for 1/16 steps.
nospam2006110401.sv...@muzik.ca> wrote:
> Hi James,
> What do you have in your config.ini of your firmware? Important things
> are:
> #define DEFAULT_AXIS_STEPS_PER_UNIT {22.222, 22.222, 2590, 781} *<-- X
> Y Z and E values, found via calculation and tuning (these are mine). This
> may be your issue with not moving 100mm when you ask it to move 100mm*
> *
> *
> #define DEFAULT_MAX_FEEDRATE {500, 500, 3, 1200} *<-- X Y Z
> and E values, maximum mm/s that they can travel. Whichever is smaller
> between this number and the feedrate as defined in pronterface is your
> maximum speed that it will move*
> When it moves "15mm" instead of 100, does it reliably move 15 every time,
> or does it sometimes move 14.9 and sometimes 15.5? If it is reliably 15,
> then you need to change your steps_per_mm. The calculation here is 100/15
> * 22.222 where 100 is how far you asked it to go, 15 is how far it went,
> and 22.222 is the current value in *your *steps_per_unit, which is
> probably different than mine!
> If it is not reliable, then it is probably something hardware-related.
> Before trying to print something (and getting very frustrated), you should
> first calibrate everything. Then calibrate again, and finally once more
> for good luck and *then* try to print something. A good calibration set of
> steps is here: reprap.org/wiki/Calibration
> -sean
> On Tue, Nov 13, 2012 at 2:45 PM, seatlanta <hyd...@gmail.com> wrote:
>> After spending a few weeks with a defective Melzi board, I changed to
>> RAMPS 1.4 from reprapdiscount.
>> It's installed and it wants to print, but the motors are clearly not set
>> up correctly. The print head goes through the motions, but it moves
>> veeeryyy slowly, and it doesn't move far. It's like everything is
>> compressed. My practice parts are look like blobs of chewing gum from the
>> bottom of a table.
>> I think the new drivers (on the RAMPS) need different settings. When I
>> manually move an axis 100 mm, it moves about 15mm. And again, it's slow.
>> For two days, I've studied the firmware files, but I just don't know
>> where to go or what to do. The RAMPS drivers are jumpered for 1/16 steps.
Maybe the last settings I sent were not what you needed to see. Here's a cut-and-paste from configuration.h:
#define DEFAULT_AXIS_STEPS_PER_UNIT {32.05, 32.05, 960, 176} // default steps per unit x,y,z,e #define DEFAULT_MAX_FEEDRATE {500, 500, 5, 45} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.
#define DEFAULT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for r retracts
*Correction *By the way, I erred when I said a 100mm move results in a 15mm travel. The carriage consistently moves a hair less than 35mm. Two 100mm moves cause an actual travel of about 69.5.
Hmm, that was not quite what I was hoping for, these numbers seem "ok" --
as in with the values it should move with reasonable speed.
What happens when you move it within pronterface - what are the mm/min
values in Pronterface? If you change them will it speed up or slow down?
Alternatively you can do it using the Gcodes, I think it would be G0 X200
F2000, where X sets the speed.
What happens if you change your 32.05 to a value around 92.23? This seems
very high to me, which either means you have steppers with a smaller
rotation per step than me, or different gears or something. I switched
from 1/16 microstepping to 1/8 microstepping, and changed my value from
44.444 to 22.222, according to my calculation (below) you need around 92
steps per mm (very VERY accurate!)
I got the 92.23 from (200/69.5)*32.05. This should at least put you closer
to 100mm moving 100mm
Also important to remember, when playing around never disconnect the
stepper from the stepper driver, unless the power is disconnected from the
entire system!
On Tue, Nov 13, 2012 at 4:34 PM, seatlanta <hyd...@gmail.com> wrote:
> Maybe the last settings I sent were not what you needed to see. Here's a
> cut-and-paste from configuration.h:
> #define DEFAULT_AXIS_STEPS_PER_UNIT {32.05, 32.05, 960, 176} // default
> steps per unit x,y,z,e
> #define DEFAULT_MAX_FEEDRATE {500, 500, 5, 45} // (mm/sec)
> #define DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} // X, Y, Z,
> E maximum start speed for accelerated moves. E default values are good for
> skeinforge 40+, for older versions raise them a lot.
> #define DEFAULT_ACCELERATION 3000 // X, Y, Z and E max
> acceleration in mm/s^2 for printing moves
> #define DEFAULT_RETRACT_ACCELERATION 3000 // X, Y, Z and E max
> acceleration in mm/s^2 for r retracts
> *Correction
> *By the way, I erred when I said a 100mm move results in a 15mm travel.
> The carriage consistently moves a hair less than 35mm. Two 100mm moves
> cause an actual travel of about 69.5.
> *From Sean: What happens if you change your 32.05 to a value around > 92.23? This seems very high to me, which either means you have steppers > with a smaller rotation per step than me, or different gears or something. > I switched from 1/16 microstepping to 1/8 microstepping, and changed my > value from 44.444 to 22.222, according to my calculation (below) you need > around 92 steps per mm (very VERY accurate!)*
> We are thinking along the same lines. I did a calculation and inserted
92.0977. I changed *only the x-axis *numbers, then uploaded the file, and tried it. *No change*. The carriage still moved about 35mm. I was expecting a change in distance, either more or less.
mm/min setting in Pronterface is 3000.
I'm attaching two screen shots, one from Pronterface (Ignore the temperatures; that's another story.) and one from slic3r settings in Pronterface.
James in Atlanta (in my workshop, at the workbench, staring at the Mendel)
James in Atlanta (in my workshop, at the workbench, staring at the
Mendel) and Sean,
I'm suspecting there may be some crossed wires here (not 'lecric
ones); does Sean realize that you have a Mendel, rather than a
Mendelmax? Won't the parameters you are using be very different?
*Chris said: OK, I only have a little knowledge. *
But a little knowledge is better than none, right? Then there's the saying:" A little knowledge is a dangerous thing."
In any event, I'm happy that my heating resistor is no longer warming the entire shop. I grateful that I have not seen any more flames. I'm very pleased that the print head moves around and pretends to print, albeit at an odd scale and a leisurely pace.
My main concern at the moment is why my uploaded firmware changes are not appearing in the Pronterface messages. I can change the string text at the beginning, and those changes do appear. I don't understand why I can't change the configuration.h numbers.
I'm going out to the shop and try to stare at it more intelligently.
The problem is it is loading the settings from eeprom, not the default settings inm configuration.h (you can see that in the first few lines in pronterface when it starts up).
You can force it to use the defaults (in Configuration.h) with M502, then restore them in eeprom with M500. Use M503 to see what the current settings are.
I am not sure how you erase the eeprom settings though.
On Tuesday, November 13, 2012 10:25:00 AM UTC-8, seatlanta wrote:
> *Chris said: OK, I only have a little knowledge. *
> But a little knowledge is better than none, right? Then there's the > saying:" A little knowledge is a dangerous thing."
> In any event, I'm happy that my heating resistor is no longer warming the > entire shop. I grateful that I have not seen any more flames. I'm very > pleased that the print head moves around and pretends to print, albeit at > an odd scale and a leisurely pace.
> My main concern at the moment is why my uploaded firmware changes are not > appearing in the Pronterface messages. I can change the string text at the > beginning, and those changes do appear. I don't understand why I can't > change the configuration.h numbers.
> I'm going out to the shop and try to stare at it more intelligently.
I'm still a bit confused about this. Several weeks ago, I didn't even know that a configuration.h file existed. Now, I can edit it and upload it. But I don't understand why I can edit and upload it, and the edited version appears (with my text identifier at the beginning), but the stepper settings *don't change*.
Yet, when I use M92 to change the settings from Pronterface, it works.
I don't get the relationship between the two methods. And I have not yet grasped the idea of "default" settings. I can read the various M codes, and I know I can force things back to their default settings, but I don't know what will happen if I do. What are the defaults? And I really don't understand the value (or danger) of erasing the EEPROM settings.
Thanks again. James in Atlanta (working toward being a master programmer)
On Tuesday, November 13, 2012 3:42:08 PM UTC-5, Jim Morris wrote:
> The problem is it is loading the settings from eeprom, not the default > settings inm configuration.h (you can see that in the first few lines in > pronterface when it starts up).
> You can force it to use the defaults (in Configuration.h) with M502, then > restore them in eeprom with M500. Use M503 to see what the current settings > are.
> I am not sure how you erase the eeprom settings though.
I’d like to help by giving my version of what I think happens here. I
would appreciate anyone correcting me.
Your Mendel (not Mendelmax) has an Arduino, which is running a program
called Marlin. Marlin is in an executable form (1’s and 0’s) and
lives in the EEPROM (electrically erasable programmable read only
memory), on your Arduino. This is non-volatile memory (it doesn't
forget, when power removed). Meanwhile, you have Marlin + 40
additional files ‘config.h’, ‘pins.h’ etc, which are mostly text files
– which you can alter on your PC. Using the Arduino interface, you
load Marlin.pde and you can alter and save any of these 41 files.
Prior to uploading to the Arduino, you convert all these text files to
an executable version by using the Verify/Compile menu item, from the
Sketch menu. You then upload to the Arduino. This action overwrites
the old executable program held in EEPROM on your Arduino.
I take it you have done all of this, but the steppers are still in
need of caffeine. My previous post asks if you are using the correct
parameters for a Mendel. Are you populating config.h with parameters
for a Mendelmax, rather than a Mendel? Surely this will make a big
difference.
Chris beat me to it, but let me re-say what he did in bullets:
*Configuration.h creastes your default settings, which you upload to your board, yay *EEPROM is where your settings that you change on the fly CAN be saved if you ask it to *uploading new firmware w/ the values changes your "default" settings but does not effect EEPROM *Sending M92 in pronterface changes your dynamic settings, which are not saved anywhere and get lost on reboot (M503 Tells you current settings being used) *when you reboot the RAMPS, it reads data from the EEPROM, and ignores yoru default settings *You can save your current settings to EEPROM with M500 *You can start using hte settings in EEPROM with M501 *You can use the settings from your firmware with M502
On Wednesday, November 14, 2012 8:54:31 AM UTC-5, seatlanta wrote:
> Thanks, Jim, for the suggestions.
> I'm still a bit confused about this. Several weeks ago, I didn't even know > that a configuration.h file existed. Now, I can edit it and upload it. But > I don't understand why I can edit and upload it, and the edited version > appears (with my text identifier at the beginning), but the stepper > settings *don't change*.
> Yet, when I use M92 to change the settings from Pronterface, it works.
> I don't get the relationship between the two methods. And I have not yet > grasped the idea of "default" settings. I can read the various M codes, and > I know I can force things back to their default settings, but I don't know > what will happen if I do. What are the defaults? And I really don't > understand the value (or danger) of erasing the EEPROM settings.
> Thanks again. > James in Atlanta (working toward being a master programmer)
> On Tuesday, November 13, 2012 3:42:08 PM UTC-5, Jim Morris wrote:
>> The problem is it is loading the settings from eeprom, not the default >> settings inm configuration.h (you can see that in the first few lines in >> pronterface when it starts up).
>> You can force it to use the defaults (in Configuration.h) with M502, then >> restore them in eeprom with M500. Use M503 to see what the current settings >> are.
>> I am not sure how you erase the eeprom settings though.
Thanks for that. James, I was wrong regarding the uploaded program
living in EEPROM - it goes into Flash Memory (see; http://arduino.cc/en/Tutorial/Memory ).
Chris, the Arduino link was very helpful. And Jim's' comments helped clear up some questions about the Arduino memory.
At this point, I can made distorted prints of simple, small objects. Printing a 20mm cube and measuring the finished product moved me much closer to the correct calibrations for the three axes. I have now memorized the calibration formula, and I sometimes dream about it.
My friend, Will, came over last night and provided a second opinion about some of the remaining problems. He has completed his machine and it prints with nary a problem. Disgusting!
*Voodoo* We spent about an hour trying to analyze the E motor and why it quit operating. I plugged it into the x-driver and it extruded when I did an x move. I plugged the x-motor into the E driver, and it moved left and right when I did forward and reverse extrusions. Therefore, the motors function, and both drivers function, but when I plugged everything back as it should be, the extruder didn't budge. I went indoors and thought about it, and when I returned, it worked.
*Why Z deserves to be at the end of the alphabet* The last problem to solve (I hope) is the z-axis, which continues to bind. When that happens, one motor stops turning and the other doesn't. This creates a rapidly worsening binding problem that screws the nuts off the lead-screw and slams the x-carriage into the bed on the right side.
When I check my parallelism and perpendicularity (words I like to use), everything is OK. When I move the z-axis manually, it's smooth as silk. But when I home the axis, it usually goes berserk. So it can take a short move, but not an extended move.
Will and I decided the vertical bearings (bushings) at each end of the x-carriage are not aligned in the vertical direction, probably because both fittings broke early in the game and I had to put them back together with super glue. By the way, several of my pieces were very brittle and snapped during construction. At this point, I also have several stress fractures in some other parts. This doesn't seem like the way it should be.
And before anyone asks: Yes, I was very careful during construction and treated everything with kid gloves.
Will is printing two new parts for me. Maybe that will solve the problem.
*And on the plus side*
- I'm still getting good temperature control - I'm no longer seeing any smoke or flames. - The resistor is still green, and not crumbling like charcoal. - The printer is functioning, but has some mechanical issues that I know I can handle.
On Wednesday, November 14, 2012 1:58:43 PM UTC-5, UK Chris wrote:
> Vlad,
> Thanks for that. James, I was wrong regarding the uploaded program > living in EEPROM - it goes into Flash Memory (see; > http://arduino.cc/en/Tutorial/Memory > ).
Firstly, I really enjoy your humorous slant on your multitude of
Reprap problems - please keep this up.
Secondly, I suspect that when you transferred from the Dark Side
(Melzi), your Z motors were wired in series - this will obviously
limit the current and therefore the torque to your steppers. As the
RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
like this and get max torque from each.
Thirdly, once Will has printed the parts you require, swap your duff
Melzi board with his/throw iron filings into his machine - that'll
wipe the smug look off his face.
I will throw my humble +1 behind Chris' observations.
And, say congrats! Your hurdles have been many, and occasionally
treacherous. The fact that your humor has come through it all intact is
appreciated.
Regarding Voodoo...
I have worked in a land of mystery and magic for many years.
IT
I learned two things long ago that are just as true today, in that land,
and in this one of oozing plastic :
1) The magnetic field generated by the (non-existent) plate in my head
often fixes things that others cannot, and does involve anything more than
it's proximity to the device in question.
2) Failing the magic of my plate, 70% of all other problems can be
resolved by taking a smoke / beer / food break. Or, just getting some
sleep.
On Fri, Nov 16, 2012 at 10:49 AM, UK Chris <honeya...@rapro.co.uk> wrote:
> James,
> Firstly, I really enjoy your humorous slant on your multitude of
> Reprap problems - please keep this up.
> Secondly, I suspect that when you transferred from the Dark Side
> (Melzi), your Z motors were wired in series - this will obviously
> limit the current and therefore the torque to your steppers. As the
> RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
> like this and get max torque from each.
> Thirdly, once Will has printed the parts you require, swap your duff
> Melzi board with his/throw iron filings into his machine - that'll
> wipe the smug look off his face.
I just talk to the voices in my head - its like having a whole team of
individuals working on the same problem
On Nov 16, 2012 3:02 PM, "Larry Knopp" <lwkn...@gmail.com> wrote:
> I will throw my humble +1 behind Chris' observations.
> And, say congrats! Your hurdles have been many, and occasionally
> treacherous. The fact that your humor has come through it all intact is
> appreciated.
> Regarding Voodoo...
> I have worked in a land of mystery and magic for many years.
> IT
> I learned two things long ago that are just as true today, in that land,
> and in this one of oozing plastic :
> 1) The magnetic field generated by the (non-existent) plate in my head
> often fixes things that others cannot, and does involve anything more than
> it's proximity to the device in question.
> 2) Failing the magic of my plate, 70% of all other problems can be
> resolved by taking a smoke / beer / food break. Or, just getting some
> sleep.
> On Fri, Nov 16, 2012 at 10:49 AM, UK Chris <honeya...@rapro.co.uk> wrote:
>> James,
>> Firstly, I really enjoy your humorous slant on your multitude of
>> Reprap problems - please keep this up.
>> Secondly, I suspect that when you transferred from the Dark Side
>> (Melzi), your Z motors were wired in series - this will obviously
>> limit the current and therefore the torque to your steppers. As the
>> RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
>> like this and get max torque from each.
>> Thirdly, once Will has printed the parts you require, swap your duff
>> Melzi board with his/throw iron filings into his machine - that'll
>> wipe the smug look off his face.
On Sat, Nov 17, 2012 at 2:49 AM, UK Chris <honeya...@rapro.co.uk> wrote:
> Secondly, I suspect that when you transferred from the Dark Side
> (Melzi), your Z motors were wired in series - this will obviously
> limit the current and therefore the torque to your steppers. As the
> RAMPS has pin-outs for two (parallel) Z steppers, consider wiring them
> like this and get max torque from each.
Actually when connected in series, the motors each get twice as much
current (hence torque) as when they're connected in parallel... what makes
you think it's the other way around?
A stepper is simply a bunch of coils which have some resistance
(reactance to changing voltage/current generating back EMF). Put two
in series and you double the resistance and therefore halve the
current and consequently torque. Now, from reading your posts, I
figure you know your stuff, so I'm anticipating opening a large can of
'whoop-ass'.
one more thing - in addition to my terrific MM1.5+ (it's printing
prototypes every day), I have a Huxley which was supplied with Melzi
electronics (I managed to palm that off on a fella from the
colonies ;)
So I'm replacing the electronics with a Megatronics
http://reprapworld.com/?products_details&products_id=274&cPath=1591_1606 , which I am going to connect today. Like the RAMPS, it has parallel
outputs for the Z steppers and I was going to wire them that way. Why
would both circuit boards have two sets of Z O/P's?
> one more thing - in addition to my terrific MM1.5+ (it's printing
> prototypes every day), I have a Huxley which was supplied with Melzi
> electronics (I managed to palm that off on a fella from the
> colonies ;)
> So I'm replacing the electronics with a Megatronics
> http://reprapworld.com/?products_details&products_id=274&cPath=1591_1606 > , which I am going to connect today. Like the RAMPS, it has parallel
> outputs for the Z steppers and I was going to wire them that way. Why
> would both circuit boards have two sets of Z O/P's?
Has anyone any ideas why then, that the RAMPS has parallel outputs for
the Z (as does my new Megatronics), the photos supplied by TL show
parallel wiring and this; http://www.flickr.com/photos/87350090@N03/8192085683/ does too?
I understand the argument that a 'current limited' Polulu is sharing
the current between two parallel steppers, but surely we can just turn
that up to its specified limit.
If I'm doing this wrong, then I suspect lots of other folks are too.
As an aside, I have had much grief with Z vibration (having accurately
aligned it, so many times), until I got rid of the aluminium (spiral)
couplers and replaced them with these; http://www.thingiverse.com/thing:9622 I know, it's old tech and doesn't look sexy - but they dam well work.
Reduced the vibration by 95%, the rest disappeared after a thin
application of PTFE oil. (Wiki says not WD40)
.jpg?part=4)
+(2).jpg?part=5)