Something seems amiss in that while I do not have a P2S, an error should spit out that says there is a g-code path conflict to prevent just what seems to be getting described here.
As I recall it will manifest during the slicing process. Are your printers configured to “Print by Object” or “Print by Layer”? Print by Object seriously constrains the available buildplate volume
Introduction to print-by-object
When there are multiple print objects in one plate, you can choose to print multiple models at the same time (by layer, the default print sequence), or you can choose to print them one by one. Print-by-object can reduce stringing and oozing caused by traveling between models. And if one model fails, it usually does not affect the printing of the other models when using this mode. You can select this function in the Special mode:
Thanks! It’s always a single object on the plate, printed by layer (default), and the slicer shows no g-code path conflict warning. The toolhead hits the tree support trunks during normal printing.
Thanks! I’ve only tried Z-hop up to 0.8 mm (Spiral Lift) so far, so 1.5–2 mm is definitely worth a test. I’ll run my test model with tree supports and Z-hop 1.5 mm (spiral) and report back.
Did you notice any side effects with such a high Z-hop – for example more stringing or blobs, longer print times, or visible marks on the model? And do you use the 15 mm brim on the model itself, or mainly to keep the support trunks on the plate?
Have you done the long bed level/position calculation recently on your printer. The one it tells you will take 20+ minutes to do?
For the nozzle tip to strike either the model or the supports and NOT give you the error seems to say the nozzles physical location (in the real world) is different that where the nozzle thinks it is, in the math equation.