Dual Y gantry IDex question

  • David, I assume you're the right person to ask this:
    I am working on a dual Y gantry IDEX (4 IDEX extruders – as mentioned in my other post)
    I am adding an 11th stepper driver -- which I think I figured out how to do -- using the LCD pins the driver would attach to r: 85,84,83, and 82 (for the limit switch)
    I plan to use that one for Z axis so I am think M584 Z10 would do it -- as my z axis is using beefy nema23s, and moving that off to a larger external driver makes sense.

    I was digging through IDEX config, and I am basically added similar code for yAxes bitmask as there is for the xAxes bitmask. I don't anticipate ever configuring tools with multiple concurrent Y axis, I understand the need for a bitmask as the intent is to allow duplicate printing, but I am having a bit of trouble understanding a couple of points.

    just wanted to check if this was correct:
    for Tool.h
    // this is odd way of mapping as the bitmask intent is to be binary, yet it's defined as hex value.
    const uint32_t DefaultYAxisMapping = 0x0002;

    then I'm moving on
    I am doing this in both cases:
    for (uint32_t xaxis = 0; xaxis < numAxes; ++xaxis)
    if ((xAxes & (1u << xaxis)) != 0)
    const float xCoord = xyzPoint[xaxis];
    for (uint32_t yaxis = 0; yaxis < numAxes; ++yaxis)
    if ((yAxes & (1u << yaxis)) != 0)
    const float yCoord = xyzPoint[yaxis];
    if (usingMesh)
    zCorrection += grid.GetInterpolatedHeightError(xCoord, yCoord);
    zCorrection += probePoints.GetInterpolatedHeightError(xCoord, yCoord);


    I want to make sure I use the correct coordinate when doing the GetInterpolatedHeightError – so hence I added an inner loop - is it necessary to check the y axis as the comment says it's irrelevant, but yCoord is still passed in in the original implementation.

    The last bit I'm unsure about in the DoArcMove

    arcAxesMoving = reprap.GetCurrentXAxes() & ~((1 << Y_AXIS) | (1 << Z_AXIS));

    how would I incorporate the reprap.GetCurrentYAxes() -- if it even makes sense to do so?

    Thanks for your help


  • administrators

    In the code snippet you published, I think you are incrementing numOAxes too many times. You should incremental it once each time you need to the Z correction, so that when you divide the Z correction by numOAxes at the end you get an average Z correction.

    I'll take a look at DoArcMove when I am in the office e later today.

    Now that I know that somebody needs Y axis mapping, I'll probably add that feature in the next beta.

  • I got Y axis mapping working – I figured out the DoArcMove too ... I'll revisit the InverseBedTransform code later...

    the thing that was tripping me up was ToolOffsetTransform

    this finally worked:

    for (size_t axis = 0; axis < numVisibleAxes; ++axis)
    bool isX = ((xAxes & (1u << axis)) != 0);
    bool isY = ((yAxes & (1u << axis)) != 0);
    if(isX || isY || (axis > Y_AXIS))
    const float totalOffset = currentTool->GetOffset()[axis] + axisOffsets[axis];
    const size_t inputAxis = isX ? X_AXIS : isY ? Y_AXIS : axis;
    coordsOut[axis] = (coordsIn[inputAxis] * axisScaleFactors[axis]) - totalOffset;

    stayed up way too late to get it working.

    Got the 11th stepper driver working too – kinda confusing that re-assigning drive numbers doesn't also re-assign the limit switch, but that's not a big deal to me -- as the extruders don't need limit switches, so I'll carry on wiring things up further, now that things are basically working.


Looks like your connection to Duet3D was lost, please wait while we try to reconnect.