I could have sworn I already updated to the late december release, but it did indeed say RC06. I'll try again with 2.02, thanks.
Latest posts made by Naqaj
-
RE: Jerky motion in Z on Maestro
-
RE: Jerky motion in Z on Maestro
Has there been any other resolution to this issue other then "return the maestro and replace with another duet"?
I'm having the exact issue as shown in
@duckle said in Jerky motion in Z on Maestro:
@paboman Did it sound somewhat like this?
https://www.youtube.com/watch?v=8yGIwlT5qc8and I'm running out of things to troubleshoot that aren't the Maestro.
-
RE: Manually find endstop corrections on a delta?
@dc42 Can the 3-factor manual Auto Delta Calibration be changed to a 6 factor calibration? If so, where would I find that setting?
-
RE: An alternative to z-hops for delta kinematics
@dc42 said in An alternative to z-hops for delta kinematics:
I had a similar idea 2 or 3 years ago, although my plan was to split the move into 2 parts with a greater Z coordinate at the join. Or possibly use a single move with a quadratic Z term added.
Do you have any plans for revisiting this?
@edgars-batna said in An alternative to z-hops for delta kinematics:
This "Arc" Z-hopping would be interesting to try on any kinematics.
Certainly, though the point here was that a delta may provide this in an easier way to implement, simply through timing and without additional movement.
-
An alternative to z-hops for delta kinematics
I'm looking for some feedback from more experienced printer builders/tinkerers on the feasibility of the following.
Given how a delta works when making planar moves, i was thinking about an alternative to using z-hops that would avoid the extra g-code, interruption of movement, and maybe reduce the need for retraction for travel moves across a print surface.
When making a X/Y move on a delta, there'a always at least one carriage moving downwards. If the software was to ever so slightly delay the movement of the downwards-moving carriage, the result would be a move with a slight upwards curve in the Z-axis.
Has there been a delta firmware that does this? Are there undesirable sideeffects to making the nozzle move over the print in a curve? Anyone got some input on this?
-
RE: cura trouble
Every other version update, CURA resets the material settings back to 3mm filament without any feedback to the user, make sure this has not happened to you and it's still set to 1.75mm
-
RE: Wrong coordinates after delta homing
I've just gone through the tool again, using "no z-probe" in the Z-Probe settings and all three endstops set to active-high in the End-Stop settings, with none set to Z-Probe, like I did before. I left everything else on default presets
I still get a file without the Z-endstop definition in M574. If you get a different result there must be another setting somewhere causing this.
Either way, I think I can mark this as "solved"? Or can only admins do that?
-
RE: Wrong coordinates after delta homing
Found it, M574 was missing the z endstop definition.
I just double checked, this seems to be a bug in the RFF tool. Using it to generate a config file for a custom delta creates one where only X and y endstops are defined in M574.
-
RE: Wrong coordinates after delta homing
M665 R91 L228 B88 H174 ; Set delta radius, diagonal rod length, printable radius and homed height
M666 X0 Y0 Z0 ; Put your endstop adjustments here, or let auto calibration find themThese are my two delta settings, as received from the reprap configurator. I haven't gotten to any offset calibration yet, as it can't even do basic homing at the moment. There is definitely an error in the geometry somewhere, as y moves are not horizontal, but I have no idea where to look for it.
-
RE: Wrong coordinates after delta homing
I tried both M666 X0 Y0 Z0 and M666 X0 Y0 Z0 A0 B0
After restarting the board, it now sets y to 38.79 on homing instead.