One vertex slightly off?

Discussion in 'OpenBeam Kossel Reprap and OpenBeam Kossel Pro' started by thoughtfix, Jan 17, 2015.

  1. thoughtfix

    thoughtfix Member

    OK I had the strangest problem for the last couple days. My printing was a little too high far from the X vertex and low enough to hit the bed/extruder skip close to the vertex. I switched from slicing with slic3r and printing with "production" MatterControl to slicing and printing with the Openbeam build of MatterControl. There were some weird problems (like a 435mm retract default. What?) but I got it working.

    Now it seems to be a little better, but the latest two prints have been very small diameter. The problem across the width of a 10cm diameter print is only about 0.2mm - not even enough to count for a whole motor skip. I tried the following:

    • Checking to make sure all shoulder bolts are tight
    • Checking to make sure the bed is level
    • Swapping the X and Y carbon fiber rods to see if it was a length issue
    • Adjusting the tightness of my belts
    None of that fully fixes it but somehow printing with MatterControl makes it a little easier. Maybe it's because my G29 Z is slightly higher to begin with, my models have a smaller diameter, and I am using dried hairspray on glass for the first layer. I also have an odd workaround where I have the X vertex's belt two twists loose and tighten those two twists after bed leveling while it's drawing the skirt.

    Oh here's a lovely print, but it melted the top because it was too slow. (MatterControl defaults are SLOW compared to Johann's Kossel Mini settings.)
    grainiac likes this.
  2. Chris

    Chris Member

    I noticed this the other day when printing a relatively large item, and then started manually measuring the accuracy of Z0 across my whole printing surface with a level gauge. I actually have over .5mm difference between "close to the Y vertex" and "far away from the Y vertex". I also swapped some arms around just in case, but there was no change which means this is almost definitely a Marlin firmware issue.

    The firmware and accompanying Marlin code that @Terence Tam sent out seems to be based on either Johann's "fsr" or "kossel" Marlin branch (https://github.com/jcrocholl/Marlin) -- neither of which has been touched since last June. I spent a few hours tonight working with @Matthew Wilson (original Brainwave designer) to get a slightly updated version of Terence's Kossel Pro configuration merged into a clone of Johann's "deltabot" branch, which has all kinds of changes to the bed probe calculations (among other things). We got so far as to get things to compile but it got too late to start actually testing on real hardware so we plan to start testing things over the weekend.

    If you're very brave, you're welcome to grab my working copy and compile a copy yourself: https://github.com/ex-nerd/Marlin (but be ready to flip that power switch if the probe looks like it'll start scratching the glass). On the other hand, we'll post an updated firmware in this forum once we've worked out any problems.
  3. AndyG

    AndyG Member

  4. Frank

    Frank New Member

    What shall I say: the same problem. On 10x10 cm I can measure a distance up to 0.4mm. I'm right: the side between the X and Z - axis is the lowest (from x-50 y50 to x-50 y-50) . There the hot end will touch the glas. The best side is near the Y-axe.

    IMHO it looks like a problem how the firmeware is using the correction vectors. It's a delta printer so it is not possible but my first idea was: there is an commutation of X and Y axis. What is if that the firmware is doing so ...if the matrix is not in the right orientation?

    Attached Files:

  5. Chris

    Chris Member

    @Frank That matches my printer, too. I suspect it's a calculation issue with the bed surface calculation. There have been some significant changes in how Marlin does bed probe calculations since that kossel pro firmware was written, and I'm hoping that the updated code will solve this particular issue and also give me a chance to slightly correct some of the positioning used for probe deployment.
    Bryce Johnson and Frank like this.
  6. Frank

    Frank New Member

    Well thats nice.. or not. Is nice: I can stop to find my issue. Is not nice: we have to wait again..
  7. Chris

    Chris Member

    @Matthew Wilson posted some instructions on how to get updated firmware installed: http://forums.openbeamusa.com/threads/updating-the-firmware.121/

    These include a link to my github fork of Johann Rocholl's fork of Marlin (which has some delta printer enhancements not yet available in upstream Marlin). This will eventually be posted on the (brand new) official OpenBeamUSA github org.

    That said, I'm still seeing about 0.4mm difference in height between x60,y-60 (z>0) and x-60,y60 (z<0). In delta terms, the closer you get to the Y vertex, the further off the bed extruder gets. The further from the Y vertex, the closer to the bed.

    I haven't actually looked at the calculations used for the autolevel algorithm (and I suspect they're over my head without a significant trigonometry refresher) but I'll start digging into that section of the code next.
  8. Chris

    Chris Member

    FWIW, I've heard from @Matthew Wilson that his printer is unaffected by this issue. I've also confirmed that it's still happening in the latest updates we've done to the firmware (photo attached) though not quite as much (total change of about .2mm across the whole print surface, about half of what I was getting before). I've just posted a request for help in the deltabot google group to see if anyone there has ideas. Feel free to chime in: https://groups.google.com/forum/#!topic/deltabot/3da-GBj_fpU

    Attached Files:

  9. Chris

    Chris Member

    Now that I look at my photo and recall watching it print, I'm pretty sure the "off" is "tilted around the cartesian Y axis". The top right part covered up in the photo by the end effector was just as good of a print as the visible part in the bottom right. Obviously the back left is slightly thinner (nozzle scraping the tape) than the front left, but it's definitely not "off" at the angle that I thought it was when I was measuring random points around the bed.
  10. AndyG

    AndyG Member

    If @Matthew Wilson doesn't have the issue then I'm wondering if it's something more mechanical - possibly tower tilt?

    Do you guys think that adjusting the vertical length of one or more the towers could be beneficial to our issue?

    When I built my printer I "calibrated" the vertical towers by basically pushing them into the lower triangle until they touched the aluminum end caps, seating the bolts, and then doing the same with the upper triangle.

    I'm a work day away from being able to play around.
  11. thoughtfix

    thoughtfix Member

    I don't think the length of the vertexes come into play. It is critical for the carbon fiber swing arms to be the exact same length, but that seems to be the case since they were all properly built using the fixture.

    We think it's a firmware thing because the auto-leveling goes through but the math is very, very slightly off biasing one vertex.
  12. thoughtfix

    thoughtfix Member

    Mine seems to be off as a relation to the distance to the X (the vertex closest to the probe) axis. The closer it is to that vertex, the lower it is. But only by about 0.3mm or so. Enough to barely hit the print bed (and clog the nozzle) when near the vertex and enough to barely raise the extrusion too high (preventing it from sticking) on the far side.[/QUOTE]
  13. chadman

    chadman Member

    I believe additional assumptions are in play, such as all columns being parallel, etc. There seems to be numerous systems without known problems, mine included. I would consider the possibility of a mechanical issue.
  14. AndyG

    AndyG Member

    I understand where you are coming from. Especially since the auto level routine should feasibly get rid of any difference in the bed level and it does seem to work quite well. If it were only firmware related though I would expect a much larger sample of people having issues. There has to be another variable here.

    I reviewed this last night: https://groups.google.com/forum/#!topic/deltabot/V6ATBdT43eU and it certainly brings back memories of my linear algebra classes but I'm years off from having done anything similar.

    I'll just keep plugging at it from my end and see if I happen upon any eureka moments as I throw darts at a board. Thanks for the continued effort.
  15. David Boyd

    David Boyd Active Member

    I haven't tried printing anything bigger than a calibration cube since I got mine printer back up but I have seen the same behavior - mayber .05 mm difference.
    Blogs I found about this generally indicated adjusting the end stops on the tower until things are level. However, there is no easy way to do that on this printer.
    I wonder if it is possible to set small offsets for each tower from the end stop in Firmware?
  16. Wacky

    Wacky Member

    Yes, IMHO this should be done. Although, with reasonable care, we can position the end stop switches in an appropriate position, the nature of the assembly makes it virtually impossible to position them with absolute accuracy. However, all the switches do is establish a known point on the position scale of the particular axis. That position need not be "zero" (or 300 mm), but could be any value. Once set, it is trivial for the stepper to index to a desired reference position.

    Along those lines, I think that the position established SHOULD be such that the expected value of the G29 probe results is 0. That way, once "tuned" it is not necessary, and, in many cases more accurate, to skip the G29 probing for every print.
  17. PJR

    PJR New Member

    Marlin does support setting delta end-stop adjustment offsets using the M666 command (M666 Xnn.n Ynn.n Znn.n) to set individual towers offset or all at once. Unfortunately this only seems to work for the X and Y axes in the current firmware - hopefully Chris or Matt can find the problem (or point out where I am getting it wrong!)
  18. David Boyd

    David Boyd Active Member

    Cool. This is good information.
    Long term, I think we should look at storing those values in EEPROM to make setting easier and not requiring a Firmware update.
  19. AndyG

    AndyG Member

    Well, by playing around with endstop adjustments I've managed to reduce the issue.

    Here is what I am looking at measuring with a set of feeler gauges

    X0,Y0 - .533mm off of bed
    In front of X axis - .432mm off of bed (-.102mm from center)
    In front of Y axis - .584mm off of bed (+.051mm from center)
    In front of Z axis - .483mm off of bed (-.050mm from center)

    I need to recalibrate my G29 Z offset now but overall this gets me pretty close to level. The value might be slightly lower or higher but I'm limited by the gauges I have access to and probably the quality of them($10 on amazon, woot!).

    Now here is the odd part. I did 10 runs where I would change the endstop value of a single tower then measure in front of each vertex. At no point was I able to adjust the height of the point in front of the X axis. Regardless of which endstop value I changed my measured offset from center was always -.1mm.

    If anyone cares I attached my data - note the X axis bounces from -127 to -102 because of the gauges I have and the pressure required to slide the gauge under. Overall I would consider the difference a human error and settle on -.102

    Attached Files:

  20. David Boyd

    David Boyd Active Member

    Did you adjust the endstops using the M666 command or in firmware or some other way?

    Interesting thing with the X axis.

Share This Page