dev2: Problems with offset Values, Dual Extrusion & BLTouch

Before implementing the Rumba32 board & dev2 Firmware to my selfmade cartesian printer (Rumba board, V1.0.4 Firmware),
I realized a test sample with XYZ motors, E1&E2 Extruder and BLTouch, Rumba32, dev2-FW.

Motors, homing and BLTouch are working, next step is position handling of E1, E2, BLTouch

Testszenario: bed, 0/0, E1, E2, BLT with offset values

                           | y axis
                           |             Print bed
                           |  + 0/0
                           ---------------------------------------- X axis                           
                       O E1(3;3)
        O E2 (10;7)

               O BLTouch (-5;-10)

One minor issue first: I found that for the test szenario I have to enter positive offset values for the tools and negative offset values for the ZProbe while they all are in the same quadrant of the coordinate system.

But there are 2 issues I cannot reproduce completely:
1) If I repeated HomeAll several times, "sometimes" there is a "move to illegal position prevented"
2) If I change the Z-Probe X Offset by 10, the probing position changes by 12.
3) If Z-Probe X Offset=10, ENDSTOP_X_BACK_ON_HOME=1, the Probing X position is 25mm from switching position.

I know this informations are not enough for an effective help.

So what I'm asking for / proposing as a next step:
Where in the code can I add log output of which variable (i. e. absolute positions in steps) to collect more information about whats going on.

Then I will perform more tests to collect more reproducible information.

Thanks in advance!


  • Oh, I saw the title could be misinterpreted.
    Should be something like ...Problems with offset Values of Dual Extrusion & BLTouch

  • First extruder offsets are unusual. Why is not one of the 0,0 so you have a fixed reference to work with.
    I also do not understand your graphic. Here again E0 on 0,0 helps understanding. If it is 0 and E1 is 20 then selecting it should move 20 to the left and homing X would leave a 20mm space to endstop. That would be the expected behaviour.

    Same for z probe. Should use same sign. If not it is a clear error in firmware. Need to test that when I have some time. Only have a delta for testing but at least offset switching distances should show up correctly.

    Every time the offset change the void Motion1::setToolOffset(float ox, float oy, float oz) gets called, so that is where you could add debug information about set offsets and compare if the signs are send correctly.
  • In final setup E0 will be at 0/0, E1 at -40/0 and ZProbe at -20/35.

    The unusual values are a result of several tests because of some for me unexpected behaviour

    I'll add some debug information and will report.
  • Ok so E0 is the right extuder, E1 40mm left and z probe in between with y offset to the back.

    E1                  E0

    Hope to do some more tests on weekend as well.
  • Found 2 issues (in my mind ;-), which I will add in github, which I hope is your preferred way. Is it?
    The different sign of probing offset and tool offset could not yet be reproduced. I will still try to reproduce, may be something with preventing unallowed positions...
  • Small question about the heads offset:

    What command can be used to change the offset values? 

    The M218 command is not implemented in Dev2 unlike Marlin.

  • The offset value are usually stored in the EEPROM of the controller.
    I'm using Repetier Host or Repetier Server, with both all EEPROM parameters can be listed and edited.

  • Needing a computer to adjust our printer is penalizing.
    Currently I am using a touch screen, but I also need the LCD screen so that I can adjust the heads offsets through the Repetier interface.
    The absence of the M218 command is penalizing, especially since it is now possible to correct the offsets using the Gcode interface on the touch screen or to use the specific menu.
    But these 2 methods work with M218 :(
  • With the console in touch screen you can send regular gcodes like M218.
  • When I send M218 T1 X50, the console displays:
    Unknown command: N31 M218 T1 X50.00

    M218 is not present in the "implemented codes" list in "main.cpp"

    If I search through all of the code, it is not found.
  • When there is no M218 command in firmware implemented there is nothing server can do of course:-(
  • I found that for the test szenario I need to enter positive counterbalance esteems for the instruments and negative balance esteems for the ZProbe while they all are in a similar quadrant of the arrange framework.
  • Two weeks ago I had the same problem.
    In the meantime there were some modifications in Offset Handling.
    Try latest version from github.

Sign In or Register to comment.