dkightley wrote:I'm at a loss as to how changing how this is represented in the preview will have an effect on the printed model. The v2,x preview showed the second and subsequent layers printing above where the first layer was printed....showing the model "levitating" above the raft. This graphical representation looks as if has been changed in v3 to show the first layer printed at the elevated height and then the second and subsequent layers being printed at approximately the height where they actually is printed in real life. The effect looks equally strange. The model no longer "hovers", but looks as its been mis-drawn. Both can be said to be either right or wrong....but how can this be correctly represented to satisfy everyone??In version 2.2, this worked correctly.
For example, setting to a .014mm gap yields the result in the first picture below.
Setting to 1mm gap yields the result in the 2nd picture below.
This is exactly what I would expect. I have control over what the machine is doing. I can also easily see the result of changing a value in the user interface and validate that the control is changing the parameter I want to change. And as odd as it may seem, I may actually want this if I am doing something creative with multiple processes and overlapping models.
I don't see any downside at all to making it work like it used to. In fact the way it is now, I don't think there is good control between 1st layer after separation and the layer after that. The way it worked prior to 3.0, the 2nd layer after separation would have a fixed relationship with the 1st layer after separation.
Sure, I can goof up and set the gap too large, but that's my fault. I want the control.
Surely the real issue is the first layer of the model is for some reason sticking too hard to the raft after being printed in fresh air and dropping under the effect of gravity. To me, this is probably caused by other factors...and not how high the layer is printed! Or how it is represented in the preview!
PPLDC3 wrote:Adding my voice to this thread. The second layer of the print is just squishing down all the material from first layer after the raft. It's impossible to remove the print from the raft, and makes it near-impossible to use our Airwolf printer.
dkightley wrote:In a bid to help move this on, I've done a comparison between v2.2.0 and v3.0.2:
Run 1- a 10cm cube run on a fresh install of v2.2.0 using the machine default profile (0.2mm layer)...modded only to add a raft with a separation distance of 0.5mm
Run2 - the same cube run on v3.0.2 using the above default profile exported from v2.2.0 and imported into v3.0.2
Run 3 - as Run 2 but first layer separation of zero.
The z location values for layers 1 to 6 were identical at 0.45, 0.95, 1.32647, 1.54869, 1.77092, and 1.99314. This is the raft.
Layers 7, 8, 9 and 10 for each run:
Run1: 2.6073, 2.8073, 3.0073, 3.2073
Run2: 2.6073, 2.5073, 2.7073, 2.9073
Run3: 2.3073, 2.5073, 2.7073, 2.9073
So, the theory put forward that I supported does not prove to be correctly implemented in the code....and there does seem to be some more work required in this area to get a working solution.
The v2.2.0 code did (surprisingly) print the first layer of the model in fresh air, but then printed subsequent layers on the basis that the first layer didn't drop. This obviously worked for small separation distances, but using a silly distance like 2.5mm probably resulted in a totally messed print as the second layer would not have been printed snugly to the first layer.
In a change that I assume was to try and handle oversized separation distances, I assume a code change was made which looks as if it ended up with the second layer onwards being printed as if there was no separation distance...and not at a calculated distance taking the height of the non-amalgamated first layer into account.
So...to conclude....based on the evidence I have laid out above, I now also believe there is a bug in v3...insofar that more work is needed on achieving the desired effect of easier raft separation.
To reiterate what I said......the preview DOESN'T represent the end result of the extrusion process, quite correctly as the S3D support staff say. It does, however represent EXACTLY what the slicer code is telling the hardware to do.Thanks for your efforts on this, Doug. That seems to confirm what I'm seeing in the print previews, despite the support team telling me that the preview doesn't represent what actually happens