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.

Log in to reply