The export includes a roughing op and two outlines. The first pic shows animation of the last outline op only (because impatient); the second shows moves from all three ops, iirc.
Also: slicing that outline op shows outlines down the holes too, which vanish in preview.
Now this gets weird: I walked back versions to 2.6 to get non-colliding toolpaths. When I tried to reproduce failure that I saw in 2.7 while walking back versions, it didn’t fail. In fact, as I bounce around versions, slicing this part (or minor variations) sometimes works and sometimes not in correlation with I know not what. I’m doing shift-reloads and either removing/re-importing the part or not (unless forced by error). I’ve tweaked the part & ops parameters along the way and reversed tweaks but can’t find what difference matters. In fact I think I’ve seen success and failure with no difference in conditions that I’m aware of. I’ve had at least one apparently clean result from 2.9 and I don’t know what was different between that and this example.
There are other less dramatic collisions in roughing, sometimes, and maybe some questions/requests, but I’m having a hard time isolating clean examples and don’t know which version to report against.
it turns out the be a simple fix. under expert you have this checked:
which also shows this on the JS console
the purpose of this option is supposed to be for complex topologies that are memory intensive and slow to slice when they’re just being milled as contours. I thought in this case that moves would always go to max Z, which doesn’t seem to be the case. So I’ll look into that. but disabling this produces non-colliding paths (at least for me)
That certainly sounds plausible - and capable of explaining “weirdness” as I hadn’t watched the state of that checkbox carefully.
But it’s still weird.
Apparently I need to video/screen capture a session to see what I’m doing.
When I first tried unchecking “skip shadows” it did not fix the collision (still broken). So I went back to 2.6, which did not collide (not broken), and walked versions forward again (delete part, shift-reload, import part) without collisions to 2.9 where it still did not collide (fixed). ?. At that point checking “skip shadow” and re-slicing did not generate collisions (not broken). I tried a few variations of flipping versions with/without reloading the part, with/without “skip shadows” on loading the part/first slice vs re-slice, etc. and I still don’t know what toggles the fixed/broken option.
The outlines down the row of holes still vanish between slice (present) & preview (absent). It looks like that started with 2.8 - modulo uncertain reproducibility .
Yup, it’s better when the moves don’t collide. I’ll try to find a routine that keeps it so and/or a way to consistently break it.
In that view of the sim it looks like the “left stock” from roughing remains in the holes. Do you see the outlines that would finish the holes after slicing, then not in preview?
I have another example of vanishing outlines when “inside only” selected but not when not. The exported workspace is 20MB. I’ll hold & re-check that after (assuming) you kill the bug in this topic. Unless you want it now.
(you may notice some incoming feature requests / how-to questions in that workspace too… )
I have fixes for both bugs. Interesting caching note: I’ve had to force-refresh pages twice in order to get new code reliability. The first shift + reload often still returns old code
Will push the new code at 12AM GMT / 8PM EST today
I think but cannot know for sure that it has to do with async loading and/or web workers. It’s disconcerting, for sure, to change code in an obvious-can’t-miss-it sort of way, reload the page and still get old code. So I just reloaded again (after waiting for the page to settle) and it worked the second time. I had to do this a number of times while testing fixes for these bugs. I can’t say I remember this happening in the past, so perhaps it has to do with update to Chrome.
Have you tried Microsoft Edge with Onshape? I’ve found their treatment of Chromium a little less annoying in many cases … like control over sleeping/freezing tabs. I’m on a Mac, not Windows. So this may seem an odd choice. But Chrome has been doing some pretty sketchy things of late, and it has been impacting my workflow. Anyway, if you try Edge, then you can disable tab sleep for specific sites.
.
