From Fab@Home to Repstrap... but with a tracking issue.

So for the last year I have been working on transforming an inoperable Fab@Home (http://www.fabathome.org/) to a RepStrap. I used the structure and motors from the Fab@Home but I swapped the control board out for a RAMPS 1.4 with Arduino Mega 2560 using Pololu drivers. For software I am using Sprinter with Pronterface. I am having some issues though with the tracking of the printer head. Everything has been properly calibrated and works well in manual mode. However, when attempting to print a part it displays correctly on the virtual build platform through Pronterface. When I try to print though it makes some very odd shapes that don't resemble the actual part in any shape or form. I removed the hot end and attached a pen to track the actual movement. In the picture attached I attempted to print a 10mmx10mmx1.2mm square. I have been trying to figure out what the problem could be for a while now and can't seem to figure out the issue. If anyone could lend some help or advice I would greatly appreciate it, I am at a total loss now.

RepRap firmwares "talk" a pretty standard flavour of G-code. Accordingly, the first thing to check would be a look at that G-code. There are viewers for it, Pronterface and Repetier host have one built in.

In case your robot doesn't follow the G-code you should start by checking each axis individually.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

A video would probably help

That's the thing. As far as I can tell the G-code seems to be correct, I have viewed it with a few different programs and created it with a few different programs but every build has the same issue. Also, I have quadruple checked that the G-code and printer are running off absolute coordinates. When running each axis in manual mode it doesn't seem to have any issues either and runs with great accuracy. I think from here I will try and create G-code from a .dwf file rather than an .stl to just get 2-D coordinates then try one line at a time in both the x and y direction utilizing G-code and see how it works. I hope this gets me somewhere...

What program do you recommend for uploading videos? I have not had to upload videos to here before. The video will be larger than whats allowed as a direct upload to this site.

Use YouTube and post the URL (or embed the video).

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Here is a youtube video of it running, That loud motor you hear is actually my extruder motor not an axis motor. I turned down he potentiometer on it so it doesn't sound as bad now and it sound worse in the video because my microphone was right next to it.

[www.youtube.com]

From the sound on the video, at times you can hear motors whining (aside form the loud extruder motor) but the pen doesn't seem to be moving. My guess is that the accelerations or velocities in the G-code program are set way too high. (Another video with the noisy extruder motor unplugged would make this easier to determine.) It also could be that the number of steps/mm is wrong, but if the axes seem to work correctly in manual mode, then I'd try lowering the velocities and/or accelerations in the slicer.

Thank you very much for your advice. I thought this may be an issue and adjusted the firmware in sprinter down to 400 mm/min as seen in the code below:
#define _MAX_FEEDRATE {400, 400, 2, 45} // (mm/sec)

You mentioned that the velocities in the G-code may be too high, I wasn't aware that velocity information was stored in the G-code. If so, will the G-code settings override the firmware settings?

I haven't tried adjusting the acceleration or jerk yet but I will do that next. I won't be able to test it though and post results until tonight.

If you look at the G-code, you'll see periodically an "F" followed by a parameter which is the feedrate, typically in mm/min. The print speed settings in your slicer program dictates the feedrate. Note that if you get the feedrate low enough, the motors should be able to track even if your accelerations are set optimally. One thing that is confusing is that sometimes you see rates specified at mm/min and other places mm/sec. For starting to print with a new printer, you might try setting a printing speed of, say, 30mm/sec, which should generate a feedrate parameter of 1800 mm/min. (ie, you'll see "F1800" in your G-code.)