1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

[Help] config.g for Kickstarter Robo3D

Discussion in 'Software' started by mattcelt, May 27, 2020.

  1. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    22,716
    Likes Received:
    7,241
    As for the stepper wire colors -- good luck :)
    This is how they NORMALLY go and if you are lucky the Chinese ones on the Robo are wired in a normal way

    4_wire.jpg
     
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    22,716
    Likes Received:
    7,241
  3. mattcelt

    mattcelt New Member

    Joined:
    Jul 10, 2015
    Messages:
    9
    Likes Received:
    0
    Fortunately I took pics of the connectors before disconnecting any of them from the Marlin, and I labelled each bundle. So at least I have a record of which connectors where connected to which pins on the original board. I'm going to put my faith in the Marlin and Duet boards being labelled correctly on the PCB and attach them in the same orientation, colours be damned.

    Thank you profusely for all of those images. I think if I had had some of those before, I might have simply stuck with the Marlin. I didn't know it had a screen connector built in! o_O

    But in for a penny, in for a punt... hopefully I'll post tomorrow with some happy news!
     
  4. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    22,716
    Likes Received:
    7,241
    Generally if you get the stepper motor wires reversed then the motor just runs backwards and that is an easy fix :)
     
  5. mattcelt

    mattcelt New Member

    Joined:
    Jul 10, 2015
    Messages:
    9
    Likes Received:
    0
    Yeah, but getting ZA and ZB going in opposite directions might do some damage! :eek:
     
  6. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    22,716
    Likes Received:
    7,241
    Well, it would be an interesting science experiment for certain ;)
     
  7. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    49
    Likes Received:
    19
    Sorry if this is dredging up something too old, but I'm embarked on a similar journey, only I'm installing a Bigtreetech SKR Pro v1.2 board and running the LPC/STM32 RepRapFirmware port on it. This board supports six steppers, and I intend to eventually add a second extruder for two-color printing, but that's a project for a later date. Currently, my motherboard upgrade isn't quite at the point where it can print -- I've still got to fine-tune some things and fix a thermistor connection that's flaky -- but I've got the basic motion control working, including bed probing. Some key points, and differences from the configuration you posted earlier, are:

    • Like you, I've hooked up my two Z motors to independent stepper drivers, so that the board can control them independently. This is handy for keeping the gantry parallel to the bed via a G32 command. I'm not sure that would work in your configuration, if you lack Z probing.
    • I've configured the Z switches as a bed probe, not an endstop probe -- that is, there's no M574 definition for a Z endstop. Instead, there's an M558 (similar to what you defined), plus a homez.g script that uses the switches as a bed probe. I'll post the relevant config.g excerpt and homez.g script below.
    • For the time being, I've left the two Z switches tied together, so that if either one is released, it triggers, using a single input on the control board. I have this hooked up to my E0 endstop switch input, which seems to have been necessary in RRF 2.x and earlier, but it looks like it'd work hooked up to the Z endstop input with RRF 3.x. It looks like you separated the two switches and hooked them up to separate inputs (E0 and Z) on your board. I suspect these two approaches are equivalent, given that you recombine them in your config file.

    Anyhow, here's a snippet from my config.g file that shows my setup:

    Code:
    ; Endstops
    M574 X1 S1 P"xstop"  ; configure active-high endstop for low end on X via pin xstop
    M574 Y1 S1 P"ystop"  ; configure active-high endstop for low end on Y via pin ystop
    
    ; Z-Probe
    M558 P8 C"!e0stop" H5 F120 T6000  ; set Z probe type to switch and the dive height + speeds
    G31 P500 X0 Y0 Z-0.5  ; set Z probe trigger value, offset and trigger height
    M557 X15:215 Y15:195 S20  ; define mesh grid
    
    My homez.g file looks like this:

    Code:
    ; homez.g
    ; Modified from example at https://forum.duet3d.com/topic/10246/z-homing-gcode-bloody-for-beginners/3
    G91  ; relative mode
    G1 H2 Z4 F200 ; raise head 4mm to ensure it is above the Z probe trigger height
    G90  ; back to absolute mode
    G30  ; lower head, stop when probe triggered and set Z to trigger height
    
    The homeall.g file also needs to be modified. Here's mine:

    Code:
    ; homeall.g
    ; called to home all axes
    
    G91  ; relative positioning
    G1 H2 Z5 F200  ; lift Z relative to current position
    G1 H1 X-227 F1800  ; move quickly to X axis endstop and stop there (first pass)
    G1 H2 X5 F6000  ; go back a few mm
    G1 H1 X-227 F360  ; move slowly to X axis endstop once more (second pass)
    G1 H2 X5 F6000  ; go back a few mm
    G1 H1 Y-250 F1800  ; move quickly to Y axis endstop and stop there (first pass)
    G1 H2 Y5 F6000  ; go back a few mm
    G1 H1 Y-250 F360  ; move slowly to Y axis endstop once more (second pass)
    G1 H2 Y5 F6000  ; go back a few mm
    G90  ; back to absolute mode
    G30  ; lower head, stop when probe triggered and set Z to trigger height
    
    I'll probably be making changes to both of those. As they stand, they probe the X and Y endstops twice, which is what the RRF configurator likes to set up; but I don't think that's really necessary on a Cartesian printer, since accuracy of X and Y positions isn't really critical.

    Also, bed.g needs to be updated to get G32 to level the gantry:

    Code:
    ; bed.g
    ; adapted from bed.g example in https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
    G28 ; home
    G30 P0 X20 Y120 Z-99999 ; probe near a leadscrew, half way along Y axis
    G30 P1 X200 Y120 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors
    
    All of this works, in that I'm able to home my Z axis, use G32 to level the gantry (I can move it out of alignment and then watch it level itself with a G32 command), and use G29 to build a height map. This last one looks pretty terrible, though:

    [​IMG]
    As I said, I'm not quite ready to print yet, so I don't yet know if this height map will be useful or if I should just ditch it. As I'm sure we've all seen, the bed flexes a lot when it's being probed, which can't be good for accuracy. I've noticed on mine that there's a lot of play in the mechanism. I'm not sure if it's always been like that or if it's worsened over the three years that I've had the printer. Either way, I'll probably have to do something about that.
     
    mark tomlinson likes this.

Share This Page