New 12" user and I am LOST!

[printbus]

To be blunt, reducing the homing speed to "fix" what might be wrong is a bad idea. At best it is masking what the problem is. More than likely the underlying problem is still going to surface as z-axis issues during prints. Why would it be that no one has had to slow down the last homing leg before?

[Chadd]

After reading this and some searching it appears that a lot of people have issues with the default homing speed. Most say changing it from 4 to 3 takes care of the problem. I am about to upload the firmware to try it out, I am a home built CNC machining guy and have dealt with home building CNC machines.

I know these printers don't have much load on them but in all honestly from a structural standpoint these printers are horrible, I don't think the over all structure of the printer is capable of being repeatable to within the tolerances that we are asking them to be. Slowing down the rate that the machine homes at for sure can't hurt anything.

But I agree the home rate isn't the underlying problem here. Poor design is.

To be blunt, reducing the homing speed to "fix" what might be wrong is a bad idea. At best it is masking what the problem is. More than likely the underlying problem is still going to surface as z-axis issues during prints. Why would it be that no one has had to slow down the last homing leg before?

[printbus]

After reading this and some searching it appears that a lot of people have issues with the default homing speed. Most say changing it from 4 to 3 takes care of the problem.

Who says that? On these printers? I don't recall this ever being discussed in this subforum, except for my INCREASING the homing feedrates. I can't speak to what MakerFarm is providing for firmware these days, but the standard configuration.h file at least used to specify a Z homing feedrate of 50mm/min. That's less than 1mm/sec. So, I'm not sure what the 4 or 3 is referring to.

[Chadd]

Unless I am mistaken this is the home feedrates from the config file.

#define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0}

that is the X, Y, Z, extruder rates, in that order.

There are at least a few threads on the reprap.org forums about this.

Who says that? On these printers? I don't recall this ever being discussed in this subforum, except for my INCREASING the homing feedrates. I can't speak to what MakerFarm is providing for firmware these days, but the standard configuration.h file at least used to specify a Z homing feedrate of 50mm/min. That's less than 1mm/sec. So, I'm not sure what the 4 or 3 is referring to.

[printbus]

Unless I am mistaken this is the home feedrates from the config file.

#define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0}

that is the X, Y, Z, extruder rates, in that order.

There are at least a few threads on the reprap.org forums about this.

What is the origin of that config file? Is it a stock Marlin configuration.h from the Zalm repository, or the configuration.h that the manufacturer (MakerFarm) provides to be used?

It is correct that the Z motors on the i3v printers can't be reliably driven to 4mm/sec. I found even 3 to be borderline in my testing.

[Chadd]

Yes that was directly from the config file that I downloaded for the Rumba from makerfarm.

I am going to download the rambo firmware from makerfarm and look at it. I have run into a few discrepancies with documentation for the 12" i3v.

"edit" the rambo config file has the exact same feedrates that I posted above.

What is the origin of that config file? Is it a stock Marlin configuration.h from the Zalm repository, or the configuration.h that the manufacturer (MakerFarm) provides to be used?

It is correct that the Z motors on the i3v printers can't be reliably driven to 4mm/sec. I found even 3 to be borderline in my testing.

[Chadd]

The Ramps config is different here are the values from it.

#define HOMING_FEEDRATE {50*60, 50*60, 50, 0}

Maybe this is the issue that people are having? Would that be .883 mm/sec?

I sent an email to Colin to ask him about it.

Yes that was directly from the config file that I downloaded for the Rumba from makerfarm.

I am going to download the rambo firmware from makerfarm and look at it. I have run into a few discrepancies with documentation for the 12" i3v.

"edit" the rambo config file has the exact same feedrates that I posted above.

[Chadd]

I heard back from Colin regarding the speed setting in the config file. It looks like this was our problem, here is what Colin replied.

Hi Chadd,
Thank you for letting me know, I have changed the firmware and uploaded so everyone can download it. The firmware should have been as follows: #define HOMING_FEEDRATE {50*60, 50*60, 50, 0}. Those numbers are the speed at which each axis moves when it homes, if the Z speed is to high the two motors can get out of sync which causes everything to be out of whack.

Thanks
Colin

[tsteever]

Okay, so remind me. Is this in the config.h?

[printbus]

I heard back from Colin regarding the speed setting in the config file. It looks like this was our problem....

Here's my guess at a scenario - at 50mm/min (yes, 0.83mm/sec), the 12-inch printers take just over 6 minutes to do a full-travel home in the Z axis. Um, yeah, that's a freakin' long time. Experimenting, someone might have found that WHEN HOMING, you could appear to drive the Z motors a lot faster than that. Well, somewhat true. The Z motors will move the x-carriage DOWNWARDS nice and fast. Maybe even more than 4mm/sec. The problem is that the motors don't have the torque to lift the x-carriage using M5 rods at that rate, and that someone forgot about the *minor* detail that the X-carriage is lifted upwards a bit for the second leg in the homing process.

FYI - My take on all sorts of testing the Marlin motion-related parameters such as those in the configuration.h file, including snippets of gcode that are handy for testing the physical movements, can be found in thread http://3dprintboard.com/showthread.p...-MakerFarm-i3v. As incentive, I'll tell you that while the 4mm/sec value is unrealistic for Z, the 50mm/minute feed rate is conservative and the printers can do better than that.