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
BedTransform
and
InverseBedTransform
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);
}
else
{
zCorrection += probePoints.GetInterpolatedHeightError(xCoord, yCoord);}
++numOAxes;
}
}
++numOAxes;
}
}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
Yakov
-
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.
