Show all posts by user
Try to check this in Configuration.h:
// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR 1
#define Y_HOME_DIR 1
#define Z_HOME_DIR 1
by
hercek
-
Delta Machines
Richrap tutorial recomeds to calibrate only slow forward extrusion and with hotend hot so that the extrusion actually pushes plastic through the nozzle. The calibration is specific for given extruder spring force. It should be also new filament (not a piece of filament which did already run around extruder pulley). The reason is that the filament will get deformed a bit in the extruder and this h
by
hercek
-
Delta Machines
OK, it is a bit more complicated:
Slic3r uses retract_speed from both retract and also for reversing of the retract (which was done before).
For normal printing moves:
* retract_speed is not used at all,
* the speed of filament feeding is determined by filament diameter, print move speed in XY plane and E-stepsPerMm.
If you have your extruder e-steps correctly calibrated as advised by richRap a
by
hercek
-
Delta Machines
Firmware specifies only the maximum speed. In your case it is set to 10000 (the 4th arument of DEFAULT_MAX_FEEDRATE). 1000 is probably more common. It depends on your extruder. But this value is not really important (it is only the top limit). The actual extruder speed is set by slic3r. The option name is retract_speed. Set it to something low for the tests (e.g. 200).
by
hercek
-
Delta Machines
Your jerk values seem to be low for a delta. Try 20 for x,y,z. But this is unrelated to the problem that filament does not stick to your heatbed.
by
hercek
-
Delta Machines
First callibrate extruder as described e.g. here:
If it does not help, then there can be more reasons for this:
* Your z-height is not correct (the nozzle is still too far from the bed when printing the first layer).
* You print the first layer too quickly (try speeds around 20 mm/s or even slower).
* You do not have suitable bed surface or temperature.
by
hercek
-
Delta Machines
A2:
If you use Marlin you will need to modify only one function:
Marilin_main.cpp: void calculate_delta(float cartesian[3])
This will add 3 calls to an inverse trigonometric function, some additions, and multiplies. I do not know how slow the inverse trigonometric functions are in ATmega or ARM. Maybe there is a way to get rid of them but I do not see it now.
If you will not use ARM board, yo
by
hercek
-
Delta Machines
Convetional threaded rod delta:
The picture is from this page: [3d-delta-reprap-southafrica.blogspot.sk]
by
hercek
-
Delta Machines
I do not really understand what you want. Looks like from google translate
But if your problem is that effector is not moving smoothly (it pauses from time to time for about a second) then try to lower DELTA_SEGMENTS_PER_SECOND from the original value of 200 to something lower. You can go safely down to about 80 without degrading print quality if your maximum print speed is about 15 cm/s or lowe
by
hercek
-
Delta Machines
Check again that your belt is GT2.5 (is pitch of the teeth on the belt 2.5 mm?), your pulley has 20 teeth, and 1/16 microstepping is really selected. If this is correct then yes, your steps/mm should be 64.
Not sure about Repetier, but steps/mm can be overwriten from EEPROM. Check the output of M503 (print EEPROM parameters) and specifically the parameters for M92 (set axis_steps_per_unit). Do y
by
hercek
-
Delta Machines
A2 Wrote:
-------------------------------------------------------
> Reading this made me think that if simultaneously
> the hot end could move in X, Y independently of
> the table X, Y,
> could you get closer to a constant velocity, or
> could it help in some other way?
Looks too complicated and expensive to move both effector and bed. If you mind non-constant velocity of effecto
by
hercek
-
Delta Machines
Line #define DELTA should not be commented out.
Compare you config to this one:
by
hercek
-
Delta Machines
Ok, I did not realize that redoing the whole toolchain is an option.
In such a case, I agree that the open loop part of a 3d printer (probably stepper control only) should be "stupid" and do just what it is told. So what we would need is to provide only the information when to increment/decrement rotor position for each stepper. These are the data which need to be communicated from PC to the pri
by
hercek
-
Delta Machines
jeffegg2 Wrote:
-------------------------------------------------------
> The Delta Marlin firmware has an error. You need
> to use lower case for the function name in Marlin
> main.cpp. Who ever updated it left that fault in
> when you enable the R/C servo code.
You probably wanted to post this to Marling (or Repetier) issue tracker at their github web pages
by
hercek
-
Delta Machines
jeffegg2 Wrote:
-------------------------------------------------------
> If it does not work, you can always revert
I did not want to discourage Itai. I just wanted to point out what he may need to plan for.
by
hercek
-
Delta Machines
nicholas.seward Wrote:
-------------------------------------------------------
> I think handling both would be nice for bots with
> strange geometries. However, to do it right I
> would want the acceleration to remain continuous
> as you transition from one limit to the other.
> (On the surface, this doesn't sound trivial.)
It is probably not such a big deal (at least for delta
by
hercek
-
Delta Machines
I guess it would not be very usefull. I mean the tranformation between delta and cartesian is pretty smooth (you can differentiate it, more than once ). So smooth movement on towers will lead to smooth movement on the effector. Well, except that pesky locations where the speed limiting tower is switched. Speed transformation will not be smooth there, but at least it will be continuous. And this
by
hercek
-
Delta Machines
Marlin:
Cartesian system is converted to delta system and the dynamic limits of movement are used on delta coordinates. That means speed, acceleration, and jerk limits are obeyed for carriage movements. The limits are not considered for the effector movements.
Repetier:
I do not know.
by
hercek
-
Delta Machines
Itai Wrote:
-------------------------------------------------------
> I will first try to modify the firmware to
> compensate for the special geometry. I have looked
> at Marlin's source and if there are not hidden
> traps I see only one place where the inverse
> kinematics is calculated. That should not be too
> difficult.
Yes, there is only one place in Marlin. The point is t
by
hercek
-
Delta Machines
Marlin firmware does not support this. I do not know about Repetier.
If it adds square roots or a lot of computations it is probably not worth it.
These work well: MP JET Ball Link (Ø7 mm, M3, M3 short)
They claim to ship everywhere, but I do not know for what price. Maybe you can find a local soruce.
by
hercek
-
Delta Machines
slicer ini file needs:
print_center = 0,0
pronterface ini file (.pronsolerc) needs:
set build_dimensions 200.00x200.00x300.00-100.00-100.00+0.00+0.00+0.00+0.00
build dimensionas are (200x200) and (-100,-100) are (X,Y) offsets
by
hercek
-
Delta Machines
Can be many things, but most probable are:
* wrong diagonal rod length, or
* wrong delta radius.
by
hercek
-
Delta Machines
Jokeri Wrote:
-------------------------------------------------------
> What can I do to fix the symbol problem, other
> than changing those to somethign else?
I do not know. It depends on what kind of maxima version you are using. But symbol names do not matter as long as they are unique. If you are using MS Windows version then you can try to to convert the file from UTF-8 to UTF-16 and
by
hercek
-
Delta Machines
You can do it with Erik Zalm's branch of Marlin firmware.
by
hercek
-
Delta Machines
Those strange things are supposed to be α, β, γ (endstop adjustements). It should be standard UTF8 encoded Unicode codepoitns. You can replace them with some other variable names which are not already taken (e.g. ga, gb, gg; or whatever else which is unique in the document).
by
hercek
-
Delta Machines
JohnSL Wrote:
-------------------------------------------------------
> I looked for the M666 command and couldn't find it
> on the wiki, and I also didn't find it in the
> source code in RichRap's version of Marlin. Is
> that a new command that has been added recently to
> Marlin?
by
hercek
-
Delta Machines
edwardh Wrote:
-------------------------------------------------------
> Here's my output after a single run:
>
> (%o35)
>
>
> The r, xa, ya, and xc seem reasonable, but I'm not
> so sure about the α, β, and γ. I understand
> that I need to iterate with this approach, but
> also I don't think I quite understand the physical
> representation of those latter three
by
hercek
-
Delta Machines
Ok, at least it looks like your steppers and steper drivers are correct.
I do not know Repetier so I do not have more ideas.
Except, you should check whether endstops work correctly. Use M119 to check their status. Press them manually (with your hand) and check witn M119 that they activate when pressed and deactivate when released.
It still can be related to feedrate and steps per mm if Repetie
by
hercek
-
Delta Machines
I do not use Repetier but ... if it moves too quickly then the obvious thing to check is your steps per mm (you probably have a too high number there).
Do you have really 8x microsteping activated with jumpers on your Ramps?
Do your steppers realy have 400 steps per rotation?
by
hercek
-
Delta Machines