This is a zip file of the rostock-mini firmware that I am currently using. The only changes I made to it were to update the files to compile with Arduino 1.0.1 and modifications to the configuration.h file to work with the rostock mini.
This is a zip file of the rostock-mini firmware that I am currently using. The only changes I made to it were to update the files to compile with Arduino 1.0.1 and modifications to the configuration.h file to work with the rostock mini.
Hey Jay,
I’m new to the DIY 3d printing world.. Ive used 3d printers that were already built and functioning. This is my first go at building my own. I have a rostock mini fully assembled; however, I have hit a road block with the software/firmware part.
I have Repetier installed and have tried firmware from the Repetier website, as well as your firmware that you have in a zipfile on this site. For both firmwares, I successfully compile and upload to Arduino.
Once I open Repetier, just to test out that things I work I try to manually control the printer. The visualization shown in Repetier shows the correct movement. For example, when I hit Z+, it traces a line Z+, and so on for each axis. However, my actual printer is not moving at all in the right direction. For example, when I hit Z+, it does not go in the Z+.
Any suggestions or help you could offer would be very appreciated.
Thank you very much in advance.
Eddie
Keep in mind that the X/Y/Z axis for a traditional “3-axis” printer directly map to X/Y/Z motion of the head. (e.g. if you turn the Z stepper the head moves in the Z direction).
However, with a Delta printer, the firmware translates the normal “X/Y/Z” motion into a combination of motion for the 3 steppers. (e.g. For the head to go UP, all three stepper motors will go up at the same time.)
On my firmware, this “remapping” does not work correctly until after I have “homed” the printer for the first time, so I recommend making sure that your end stops are correctly set up first, and then hitting the “home” button.
When you do that, all three motors should turn and the print head should head upwards until all three axis hit the top endstops. Be ready to shut down power to the printer maually if the endstops don’t stop the motion correctly or if the direction goes the wrong way!
Jay
Thanks Jay. I’ll try making sure end stops are correct and then homing.
As I was reading my initial comment I realized I might have written something that could be misunderstood. All three motors do move simultaneously. All function.
However, I think that somewhere in the firmware (or elsewhere) there is something making the motors not act like a delta system. When I manually move the printer in any axis direction it does not move in only that direction. It moves in a swooping motion, partially moving laterally and vertically.
Also, I have tried “homing” the printer, and when I do the printer head moves in a swooping motion and rams itself into one of the 3 towers, attempting to go beyond its legal limits.
Thanks again Jay, for your help and patience.
I know what that is….one (or more) of your configuration
parameters are wrong, causing the coordinate transform from “x/y/z” to delta coordinates to mess up, warping your output space. (Probably making it into a “dish” shape instead of a straight line.)
I ran into something similar when setting mine up. If your printer isn’t exactly the same size as mine, my firmware parameters won’t exactly work for you.
The key parameter to get right is the distance from the uprights to the center. After you adjust it so that it looks right “by eyeball” you really want to get a machinists dial indicator to measure the deflection of your print head as it moves back and forth. Then you can
adjust the parameter a bit more to get it as accurate as possible.
See my post here for a video of the dial indicator in action:
https://www.summet.com/blog/2013/04/10/rostock-mini-z-axis-accuracy/
Hope that helps,
Jay
Thanks for all the help Jay, I really appreciate it.
Im working in the “˜configuration.h’ script. Will all the relevant and necessary configuration variables be in here? Or do I need to work in the advanced script?
Also, Im at the line in the script that reads
“// Effective horizontal distance bridged by diagonal push rods.
#define DELTA_RADIUS (DELTA_SMOOTH_ROD_OFFSET-DELTA_EFFECTOR_OFFSET-DELTA_CARRIAGE_OFFSET)”
However, when we double checked the equations result value, it does not equal what we measured first hand.
I might not be measuring the correct thing for “Horizontal offset of the universal joints on the carriages” and “Horizontal offset of the universal joints on the end effector”. I measured the distance between the two u-joints that share a side on both the carriage and end effector.
Is this correct?
It has been a while since I did my calibration, so I don’t remember exactly, but I believe that everything was in the one configuration.h file, so you shouldn’t need to look elsewhere.
From my vague memories, I THINK the “smooth rod offset” is the distance from the center to a smooth rod. And then you subtract out the distance from the smooth rod to the U-joint and from the U-joint on the carriage to the center of the carriage. So this gives you the effective “horizontal” distance that your push rods take up. Regardless, you can probably just change the delta radius number in one direction, and if your dishing gets worse, change it in the other direction until you get visually flat motion. (Then, switch to the machinists dial indicator.)
Hello there. Can you elaborate on why you set X/Y coordinates to 400 while the Rostock Mini bed is 180mm at most?
// JWS used to be 0 to 400 for x/y/z, changed to -200 to 200 for x/y so the bed center could be at 0,0
The original range was 0 to 400 (with a range of 400 units – I do not know why) I simply shifted the end points to (-200,200) with the same overall range of 400, which resulted in 0,0 being at the center of my print bed. I don’t remember exactly how or why this worked, but it does :>
The firmware was not originally rostock-mini specific, so perhaps you should use -180 to 180, or -90 to 90 instead, but the zero point is in the correct place for my system, and I do not try and issue GCode commands that cause the head to move outside of the print bed area ;>