13.06.4 Project Planner Failures

[hp-65 4]

I had a lot of fun with 13.06.x during the last, past days.

Until now. Until printer number three sunk its head directly into an object :-/

It looks like the new project planner ignores or misinterprets the given head sizes in the preference menu.

Play with it and watch the grey zones around the models!

Additionally, the lack of specifying the order of prints makes things even worse

because the algorithm seems to work only towards a positive y direction.

If the head size towards y-max is only 10mm, but has 80mm to y-min,

one loses 70mm of space because there's no way of telling Cura it better

starts with the object at y-max.

And because Cura 13.06.4 does not care about the y-min size, I lost an extraordinary beautiful fan shroud in a plastics vs. plastics fight :(

 

[Daid 289]

Odd, there is code in place to account for this "switched around fan" setup. Because, my home printer has this.

I'll do some tests to be sure. See Cura/util/objectScene.py, it has "leftToRight" and "topToBottom" variables that it uses to see if it needs to go in one direction or the other depending on the head size.

I do think 10mm is too little, a normal Ultimaker has ~18mm between the nozzle tip and the end of the head in the shortest direction.

 

[hp-65 4]

I didn't use the project planner for a while, an unforgivable mistake:

Whamm, there went another fan...

Short description:

Although the "scene" sort- and placing algorithm takes care about object hits, it completely

ignores their order. At least, not in relation to the size of the printing head.

I didn't test this on my Ultimaker and concentrated on the y-axis, because the crashed machine has

the fan towards y-min.

Maybe that's the reason because it's working for most of us while we're using the Ultimaker?

With the fan on the left side?

My (debug) settings:

xmin 100 ; only to block x-placement

xmax 100 ; only to block x-placement

ymin 50

ymax 1

Try swapping ymin and ymax and look at the gcode output (or put in some debug prints

after sorting completes or the slicer starts to work):

The objects are always sorted in the same (wrong) direction...

Here are my findings, so far.

  def setHeadSize(self, xMin, xMax, yMin, yMax, gantryHeight):

    self._leftToRight = xMin < xMax

    self._frontToBack = yMin < yMax


    self._headOffsets[0] = min(xMin, xMax)

    self._headOffsets[1] = min(yMin, yMax)


    self._gantryHeight = gantryHeight

Ok, a clever solution (except for the overall readability of the algorithm, which got lost without a single comment :wink:

Indeed, if we know the right direction, towards the longer head part, we only need to

store the shorter dimension.

Unfortunately, the "scene sorter"

  while len(self._todo) > 0:

    n += 1

    current = self._todo.pop()

    for addIdx in current.todo:

      if not self._checkHitFor(addIdx, current.order) and not self._checkBlocks(addIdx, current.todo):

        todoList = current.todo[:]

        todoList.remove(addIdx)

        order = current.order[:] + [addIdx]

        if len(todoList) == 0:

          self._todo = None

          self.order = order

          return

        self._todo.append(_objectOrder(order, todoList))

  self.order = None

only cares about the initially created hit map, created via:

  def _checkHit(self, addIdx, idx):

    addPos = self._scene._objectList[addIdx].getPosition()

    addSize = self._scene._objectList[addIdx].getSize()

    pos = self._scene._objectList[idx].getPosition()

    size = self._scene._objectList[idx].getSize()

    if self._leftToRight:

      if addPos[0] - addSize[0] / 2 - self._offset[0] <= pos[0] + size[0] / 2:

        return False

    else:

      if addPos[0] + addSize[0] / 2 + self._offset[0] <= pos[0] - size[0] / 2:

        return False

    if self._frontToBack:

      if addPos[1] - addSize[1] / 2 - self._offset[1] >= pos[1] + size[1] / 2:

        return False

    else:

      if addPos[1] + addSize[1] / 2 + self._offset[1] >= pos[1] - size[1] / 2:

        return False

    return True

but never about the preferred direction towards the small head dimension.

Until know, I indeed did not manage to find any code that cares about the direction or am I missing something?

I was afraid of touching this hell of a sorter code, so I disabled it and wrote a quick workaround that allows

me to select the order of the objects by simply clicking at them, but that's probably not what you want :wink:)

It really would be nice having this piece of code back and working!