Somewhat related:

The generator hangs during slicing when the beam width gets "too small". I'm not clear on what defines the actual practical lower limit. For example on an arbitrary test object (some text on bottom of a cube), using .4 nozzle with .2 layer height and .42 line width, reducing the beam width to 0.1 caused a hang. With 0.2 width it took a long time but completed (though generated "garbage"). After switching to .6 nozzle w/ .3/.62 height/width, it no longer hangs with a beam width of 0.1, but will with 0.01 (the currently configured minimum value).

@Noisyfox Perhaps you can take a look? (I think you originally ported this? If not, sorry and NVM!) It's probably preferable not to impose some arbitrary minimum, if it could be calculated. Or maybe the algorithm could be improved to skip unworkable cells?

There's no way to exit gracefully after a hang, the "stop" button in the status bar window is ineffective. Which is likely a separate issue in general (haven't looked).

-Max

Are you able to provide a test project that would cause a hang (possibly created by BBS and Orca separately)? Thanks.

Hi @Noisyfox , thanks for your response.

I should have tested more thoroughly and provided a repro case to begin with, and probably a separate issue. Turns out maybe it's more of an edge case than I thought (my luck that the "random object" I tested with happened to exhibit the issue).

I'm attaching a repro project here since I'm posting anyway, but really this should be a separate Issue, for further discussion. I'm happy to open one if you (or anyone else) wants to work on this. Given the specific nature of what I discovered the overall state of Studio, perhaps it's not a huge priority.

In the attached project, if I just change the global-level interlocking beam width to 0.1, I get the hang. It start slowing down and doing funky things around 0.3 width.

I'm pretty sure it is because of the thin part of the text object piece, under/joining the text characters (this was an example I made for someone on the forums). It is 0.05mm thick, and I'm not sure why it's even appearing in the sliced result in this specific configuration (with or w/out interlocking).

If the layer height is changed to anything smaller than .24mm, this thin bit is no longer sliced at all (I'd expect the opposite, if anything). And I don't get the hang with 0.1 beam width (though it still takes a bit of time). Same if I change initial layer height to .24, or if I flip the cube over so the text is on top. But when it is included in the sliced result, for whatever reason, that seems to cause the interlock generator to... lock up.

It could be that if that piece was thicker and always in included in the sliced result, say as one layer, that the issue could also be reproduced. But I haven't tried.

I haven't tried Orca, but I've reduced the project file to the bare minimum changes to reproduce the issue, which are basically selecting a .4 nozzle, the default .24mm profile, and enabling interlock.

Thanks,
-Max

(Unpacking not required, just rename to remove the .zip extension.)
Interloack-Test2.bs25.3mf.zip

thank you for doing this~
@mpaperno

I managed to slice the project file with 0.1mm beam width after ~4 minutes, so it's not completed hang, but very slow due to too many microstructures generated.

Even though I haven't figured out a way of determine the proper lower limit of this size, nor have I figured out why it generats funny results with such parameters, however I do managed to solve the cancellation problem. Now it can properly been cancelled with the following changes:
Noisyfox/OrcaSlicer@4859174

It shouldn't be hard to cherry pick those changes to BBS I believe.

I do managed to solve the cancellation problem.

That's even better, thank you! Now people can try silly things with less concern. And you have more patience than I do... didn't make it past a couple minutes' waiting.

I can definitely 'pick those changes if you prefer, easy enough! Thanks again.

Thank you @ArthurBambulab and @lanewei120 ! Nice to hear from you. Cheers!