Conflicts of gcode paths slicer ver 2.61  

RE: Conflicts of gcode paths slicer ver 2.61

I would suggest posting some pictures of your [Plater] view in both 3D Editor view and Preview view so people can see what might be causing the problem.  This error is usually caused by trying to place 2 or more models on the same spot on the print bed...

RE: Conflicts of gcode paths slicer ver 2.61

Hi 

Thanks for quick response  attach 1  of  2 pic.

RE: Conflicts of gcode paths slicer ver 2.61

Hi 

Thanks for quick response  attach 2  of  2 pic.

May be i am wrong  but can not attach  more then one file

RE: Conflicts of gcode paths slicer ver 2.61

RE: Conflicts of gcode paths slicer ver 2.61

Hi

I found the reason of this error i use raft for print and if the raft layer of one instance   touch other  instance  raft  there is an error 

I think that the  software group of the product  should  fix it in new   release   

Regards Doron

RE: Conflicts of gcode paths slicer ver 2.61

it's still like that in 2.7.0

RE: Conflicts of gcode paths slicer ver 2.61

This is normal for PS.   Each Object is sliced individually.  This is what allows you to have different settings on different Objects.  The downside is that you have to be careful not to overlap Objects otherwise bad things can happen, like plastic being laid down in duplicate areas.  This applies not only to the raft/brim you are seeing but also other things like supports too.

You have 2 options.  Arrange parts further apart so the raft/brim doesn't overlap.  You can configure the part spacing used by the arrange tool (right click the arrange tool).  The other option is to merge the separate parts. When parts are merged into a single Object then it is sliced as a single object, the raft and brim etc are all generated together and there is no overlap.  

RE: Conflicts of gcode paths slicer ver 2.61

Thanks   did  not  know about the distance para in Arrange button

RE: Conflicts of gcode paths slicer ver 2.61

Thank you! I was seeing the same issue. Merged the instances of my objects - problem solved!

RE: Conflicts of gcode paths slicer ver 2.61

I found the reason of this error i use raft for print and if the raft layer of one instance   touch other  instance  raft  there is an error 

I think that the  software group of the product  should  fix it in new   release 

I just spent a half hour fighting the same error with Prusaslicer 2.9.2; I was attempting to print a set of eleven objects, each of which had organic supports turned on; the problem was that the discs around the bases of the organic supports overlapped slightly, causing the slicer to pitch a fit with the same "conflicts of gcode paths" error, forcing me to drag the objects around to try to separate all of them far enough that the supports wouldn't overlap. This was made considerably more difficult in that I had to do it blind -- switching from the preview mode to the 3D editor mode so I could drag the objects around caused the support preview to disappear, so I had to go through an iterative process of dragging an object, reslicing the platter, looking at the error message, identifying where on the platter the actual overlap was occuring, try to memorize how I needed to move objects, and going through the whole thing over again. Being able to see the supports, even as ghost images, would have significantly shortened my task. The support generator doesn't have a problem with the discs at the base of two supports overlapping if they're for the same object, but because the slicer goes object by object when generating the gcode, having an overlap on the first layer between supports on adjacent objects is a no-no; the slicer isn't smart enough to cut out any potential overlap.

And the 'arrange' function is worse than useless for this; it positions objects for the most efficient printing... without considering space requirements for supports, putting adjacent objects too close together for their supports to be generated without overlap. 

RE: Conflicts of gcode paths slicer ver 2.61

You can configure how far apart the arrange function places things.  When you use larger brims or larger support base expansion then also change how far apart the arrange is configured for.

RE: Conflicts of gcode paths slicer ver 2.61

Unfortunately, the auto arrange function, even with the spacing tweaked, is still stupid about positioning objects, and can produce less-than-optimal results. For the problem I was having, it wanted to push one object off onto a second platter. Since I was using organic supports, the supports had bed-adhesion discs on the build plate at intervals down the sides of the objects, and auto arrange kept lining the pieces up so that the discs faced each other:

O   O   O   O
O   O   O   O

This was forcing the objects to be far enough apart (to avoid getting the error) that I couldn't fit everything on one platter. By manually dragging the objects a short distance, though, I could get the bed-adhesion discs to alternate from one object to the next:

  O   O   O   O
O   O   O   O

This allowed me to move the objects closer together, giving me just enough room to fit all of the objects on one platter. I still had to do it blind, because I couldn't see where the slicer would put the bed-adhesion discs until I resliced everything.

It would be useful if there were a way to make the slicer consider all the supports as a single object, at least for the first layer, but that would be an annoyingly fiddly bit of code and require the same fiddling with the Z-hop that is done when printing multiple colors as veneer on the first layer with a single extruder. It would only be useful in cases where you need to crowd the build plate, and I don't know whether it would be generally useful enough to be worth the programming effort. 

RE: Conflicts of gcode paths slicer ver 2.61

Version 2.9.2 ( and probably earlier) have an option to set minimum distance between the objects, right click on one of the icons in the top icon menu in the 3d view, there will be a slider there when right clicked - that should help a bit.

RE: Conflicts of gcode paths slicer ver 2.61

See my comment above yours; the problem I was having was that I was close to the limit of what I could fit on the build plate because of the object geometry, and the auto-arrange was positioning the bed-adhesion discs for adjacent objects lined up with each other, pushing one of the objects off to a second plate. I was able to slide objects around to make the bed-adhesion discs staggered, but because I couldn't see them while I was dragging the objects around, it was an iterative process to see if I'd moved them correctly -- move, slice, move, slice until everything fit.

I since discovered -- once that plate was about 40% complete, so restarting would have been painful -- that I was applying the supports wrong, and if I inverted the objects, the supports they needed, while looking bigger, actually used less material, and the printing would be a few minutes faster. So I flipped all the objects and changed where the support enforcers were, then without the organic supports along the sides of the objects, the positioning was enormously easier.

RE:

I found this thread trying to understand this error. I found spacing my parts out to resolve the message, so I assume it's the same brim issue.

My error shows z=0.00 mm, but the max layer, in my print, 168. this should be layer 0, right? When I used the tooltip link to follow the issue, it sliced it to the top of the model, so I initially assumed it was some toolpath after the print was finished, so I ignored it.

RE:

While this is a valid workaround, it seems to me that the arrange algorithm should have access to all of the following:

• Bounding box for each object
• Support + Brim bounding boxes for each object

It should then be able to create a bounding box which is the minimum bounding box enclosing those two bounding boxes and use that for object placement.

I can confirm that this has not been implemented as yet in 2.9.2.

RE: Conflicts of gcode paths slicer ver 2.61

Yes, the mismatch between layer number and height is interesting... It seems this occurs only when it is supports/brims which conflict. I suspect what is happening is that the layer number is set as the slicer progresses through the layers producing the g-code for the parts and that supports, rafts, brims are generated after. As a result, I suspect that the layer number is not reset to zero during support generation and the result is that the error message contains the z-height where the support/raft/brim collided (or overlapped) and the layer number of the last sliced layer (+1 in most cases) of the objects.