KS-061 - Autoprobe Deploy/Retract Modifications

Discussion in 'OpenBeam Kossel Reprap and OpenBeam Kossel Pro' started by DNagt, Jan 11, 2015.

  1. DNagt

    DNagt New Member

    Evening Builders!

    First off - first post after receiveing my kit and I'm very pleased. Great Job! A really fun kit my 4 year old son and I had building over the holidays. He loves the robot. I'm pleased with the quality of all of the parts and thought of assembly. Nicely done guys!

    Oh, this is my first 3D printer however I did build my own CNC a few years back. (CNCRouterParts/FineLineAutomation self-modified FLA-100/Probotix drivers/MACh3/Vectric VCarve & 3DCut)

    So, where am I stuck? here..

    Firmware - re-flashed with what's been provided. 10mm issue doesn't 'appear' to be an issue but we'll see. perhaps I've overlooked the intent of the warning or the code line to modify.
    Windows Driver / Comms - established with Teensy driver as noted. 1/2 hour issue of reading and puttering solved the issue - no biggie.
    System - Using Repetier-Host with Johan's updated config file loaded and printer parameters input (as far as I can tell I uploaded it to Slic3r correctly?)

    My issue at this time is the Autoprobe deploy and retract coordinates for the G29 routine.

    From the firmware provided by Terence from the OneDrive link in the 'firmware...etc' thread, the following coordinates are provided..

    // ttstam: These are coordinates for deploying and retracting the spring loaded touch probe. Added for OpenBeam Kossel's integrated end effector
    const float TOUCH_PROBE_DEPLOY_1[] = {-110.00, 00.00, 100.0, 0.0} ; // This is the first point that the touch probe moves to to start the deployment, on G29, if servo actuated touch probe is not defined
    const float TOUCH_PROBE_DEPLOY_2[] = {-110.00, -125.00, 100.0, 0.0} ;// This is the second point that the end effector moves to deploy the probe
    const float TOUCH_PROBE_DEPLOY_3[] = {45.00, -125.00, 100.0, 0.0} ;// This is the third point that the end effector moves to deploy the probe (such as retracting off the belt, etc.

    const float TOUCH_PROBE_RETRACT_1[] = {36.00, -122.00 , 60.0, 0.0} ;// This is the first point that the touch probe moves to retract the probe
    const float TOUCH_PROBE_RETRACT_2[] = {36.00, -122.00, 25.0, 0.0} ;// This is the second point that the end effector moves to retract the probe
    const float TOUCH_PROBE_RETRACT_3[] = {0.0, 0.0, 100.0, 0.0} ;// This is the third point that the end effector moves to retract the probe

    However, when I run the G29 with this configuration, my end-effector is sent in the opposite direction from how the probe is deployed causing the probe to clash with an X-axis support rod. Obviously this doens't deploy the probe and it runs through the safe routine yet still drives the effector way off the print extents and hovers around 100mm doing false 'probe-bounces'.

    Running the G29 again and mimicking the deployment where it's supposed to deploy, the routine runs beautifully and touches all points on the table as programmed. Using the G28/G29/G1 Z1 Gcode test routine has put me perfectly placed for the paper test.

    The we get to the retract portion which, again seems to run fine with the exception that the coordinates seem are off of the build by just a bit. I suspect it's a build variance thing with the glass hold-down clamps and HPB table being off just a bit. That said, the probe just misses the shoulder bolt but also does not drive down the Z-axis enough to force the retraction.

    From here I've manually driven the unit to:
    a) duplicate the action coordinates given in the firmware to confirm, yes - this is where the effector is being sent to deploy/retract.
    b) determine which coordinates would work to deploy and retract the probe.

    These are my findings from the Repetier-Host XYZ GUI

    Z Home - 283.7 (did a max 300 setting, dialed in with the paper test and subtracted the rest from from 300 to create the Z-Home value)
    Autoprobe deploy
    X -130
    Y 80
    Z 140

    Autoprobe retract
    X 34
    Y 117
    Z 6.0

    My attempt at modifying the firmware to provide the new coordinates is as follows. Fabritory is me.

    Auto
    // ttstam: These are coordinates for deploying and retracting the spring loaded touch probe. Added for OpenBeam Kossel's integrated end effector
    const float TOUCH_PROBE_DEPLOY_1[] = {-110.00, 00.00, 100.0, 0.0} ; // This is the first point that the touch probe moves to to start the deployment, on G29, if servo actuated touch probe is not defined
    const float TOUCH_PROBE_DEPLOY_2[] = {-130.00, 80.00, 140.0, 0.0} ;// This is the second point that the end effector moves to deploy the probe (Fabritory Edit - was -110.00, -125.00, 100.0, 0.0 - changed to -130.00, 80.00, 140.0, 0.0 due to printer build variance - 10Jan15)
    const float TOUCH_PROBE_DEPLOY_3[] = {-50.00, 50.00, 140.0, 0.0} ;// This is the third point that the end effector moves to deploy the probe (such as retracting off the belt, etc. (Fabritory Edit - was 45.00, -125.00, 100.0, 0.0 - changed to -50.00, 50.00, 140.0, 0.0 due to printer build variance - 10Jan15)

    const float TOUCH_PROBE_RETRACT_1[] = {34.00, -117.00, 50.0, 0.0} ;// This is the first point that the touch probe moves to retract the probe (Fabritory Edit - was 36.00, -122.00 , 60.0, 0.0 - changed to 34.00, -117.00, 60.0, 0.0 due to printer build variance - 10Jan15)
    const float TOUCH_PROBE_RETRACT_2[] = {34.00, -117.00, 6.0, 0.0} ;// This is the second point that the end effector moves to retract the probe (Fabritory Edit - was 36.00, -122.00, 25.0, 0.0 - changed to 36.00, -117.00, 6.0, 0.0 due to printer build variance - 10Jan15)
    const float TOUCH_PROBE_RETRACT_3[] = {0.0, 0.0, 100.0, 0.0} ;// This is the third point that the end effector moves to retract the probe

    This, when run, sends my effector in the right X direction, but now plows the effector down further and off in neg-Y directions. Not sure how to fix this.

    Key questions I'm asking you all
    1. Am I approaching this wrong by modifying the firmware Autoprobe deploy routine coordinates?
    2. Have I interpreted the coordinate settings correctly?
    3. Should I go back to the build and swap Y and Z?
    4. Something else?

    Uploaded is an image of the axis the way I have them aligned.

    I hope I've provided enough information for assistance.

    I'll echo another I've seen by thanking the design team for adding the spring in the hot-end support - hopefully it saved the hot-end!

    Cheers!
    D

    Attached Files:

    Last edited: Jan 11, 2015
  2. shchua

    shchua Member

    Your X and Y axes are swapped. X should be on the left, Y on the right. Swap the end stop and motor connectors on the BWP.
    DNagt likes this.
  3. Wacky

    Wacky Member

    Actually, I would say that it is the Y & Z that are swapped. (And the entire unit is rotated). In any case, X->Y->Z->X should be counter-clockwise when viewed from the top.
  4. chadman

    chadman Member

    I second Wacky's evaluation. Switch a few plugs and game on.
  5. DNagt

    DNagt New Member

    Thanks for the replies. I suspected it was a build problem. Occams' Razor strikes again.

    As I got it first and was still up, I tried Shchua's solution. I swapped X and Y cable pairs on the BWP, rotated the effector to maintain consistent probe orientation with the X-Axis and sure enough, that was the solution.

    I did have to follow another thread's suggestion to put on a short screw and a couple nuts to lengthen the probe arm so it would catch, and then only had to play with the Z coordinates on the probe retract cycle in the firmware.

    I have a 0.4 Z offset in the unheated HBP/Head Autolevel G29 test.

    All works reliably now. Thanks!

    Now to deal with the bowden tube 'pop-off' issue and learn feed rates and temps. *trundles off to other threads to read and learn*

    D
  6. shchua

    shchua Member

    Print and install Chris's clips for the Bowden tube. Also route the Bowden tube as per Terrence or protoserge's advice to eliminate sharp curves.

Share This Page