DodgeDeBoulet

Based on the results I'm getting, I think that the "Initial Layer Flow" setting is a first-layer modifier of the flow rate configured in Cura. So if I have my flow rate set at 82% and I configure my Initial Layer Flow to 100%, I'm going to get 82%. Again, this is from my observations, not from any deep understanding of how things work under the covers. I just know that my first layer doesn't seem to differ significantly in coverage/density from subsequent layers; when I print at 100% flow rate and 100% Initial Layer Flow, my first layer looks much denser (although my subsequent layers are over-extruded). Please correct my understanding if it's wrong. Thanks!

Satisfying my perversions almost always gets someone into trouble 😆

This one's a keeper! It moves exactly the way I'd expect it to, including honoring the perverted Z inversion I've enabled in OctoPrint 😁 Thanks!

Hi @ahoeben, Sorry, it looks like I'm getting exactly the same results with the development snapshot, and when I look at the version information it still shows version 3.5.14 in both the configuration dialog and the store "installed" list. I also tried removing the plugin, restarting Cura, and dragging the download onto the buildplate again but that didn't make any difference. Is there anything else I can do to help you debug this?

Ender 5 Plus w/SKR 1.4 Turbo, Marlin bugfix-2.0.x, Cura 4.6.1/Windows, OctoPrint plug-in 3.5.14, OctoPrint 1.4.0 on a Raspberry Pi 4 running Buster. Not sure exactly what's happening here, but when I click the left or right arrows in the jog position control in Cura w/OctoPrint plug-in, this GCode appears on the terminal: Send: G91 Recv: ok P15 B7 Send: G0 X-0.0 Y0.0 Z0.0 F3000 Recv: ok P15 B7 Send: G90 Recv: ok P15 B7 So nothing happens ... the hotend doesn't move. When I click the forward or backward arrows, the hotend moves as expected. However ... When I click the Z down arrow, I get this: Send: G91 Recv: ok P15 B7 Send: G0 X10.0 Y0.0 Z-10.0 F3000 Recv: ok P14 B7 Send: G90 Recv: ok P14 B7 Both the X and Z axes move; the bed moves up and the hotend moves to the right. And when I click the Z up arrow, I get this: Send: G91 Recv: ok P15 B7 Send: G0 X-10.0 Y0.0 Z10.0 F3000 Recv: ok P14 B7 Send: G90 Recv: ok P14 B7 The bed moves down and the hotend moves to the left. Can't say I remember this happening before. The control buttons in OctoPrint itself all work normally. Weird, huh?

In my case load time went from 20.23s to 16.09s. This is the time it took from double-click to launch to visibility of the build volume. I'll take a 20% improvement in load time any day. And that's 4 seconds less I'll have to wait for my 27 hour print! 😂

The screenshot you included in your last post appears to be the contents of a zip archive. I downloaded the individual file and it loaded into Cura 4.6 just fine:

Sort of a theoretical question, but I think there's something to think about here. With a printer that supports ABL and stores a mesh, there are areas of the build surface that are, shall we say, more active in the Z axis than others. The printer handles the modifications for extrusion to accommodate these, and (probably) does a reasonably good job in eliminating the variances. I'm wondering though: Would there be any advantage for print quality and performance by Cura having access to the printer's bed level mesh in support of planning an optimal model layout?

No worries, @ahoeben, and I hope I wasn't perceived as critical of your efforts. I just didn't want the issue confused by unintended misinformation 😄

@expiredramennoodles, I think you missed the point of my post. I have the Z-axis inverted in OctoPrint so that bed movement follows control selection. If I click down-arrow in OctoPrint, the bed moves down. If I click up-arrow, it moves up. This is identical to the Ender 5 Plus front panel Z-axis control. In the Cura plugin, the OctoPrint Z-axis control customization is currently not evaluated when it obtains the configuration data via the API, and thus its Z-axis controls work opposite those in OctoPrint. When I click down-arrow in Cura's Monitor panel, the bed moves up, and when I click up-arrow, the bed moves down. I've scanned @ahoeben's (fieldOfView's) commits on Github since I reported the issue but don't see anything that addresses it, and verified just now that the behavior hasn't changed with the latest version of the plug-in and Cura 4.5 installed.

LOL it appears I am not alone in my observation. See the reviews for the add-in 😁

Both files produce exactly the same result, though ... even after resetting the units in F360. The model is 1/10th the size it should be in Cura, and placed at 0,0 on the bed rather than near the center. A binary comparison of the files shows major differences in content, too. But I don't know what the file structure is so I may be barking up the wrong tree with that observation.

Sure, I've attached two versions of the file: one created with the units set to mm, the other with the units set to cm. Fusion 360's 3mf support is provided through an add-in, which does not let you export individual bodies. Their stl support is more tightly integrated, supporting individual bodies and even launching an external application (like Cura) to process the STL as part of the normal workflow. Ableton Stand with Logo Scaled in cm.3mf Ableton Stand with Logo Scaled in mm.3mf

FYI ... .3mf doesn't work either. I've tried exporting the model with both mm and cm set as the units, and regardless of how they're set, I have to scale it by 1000% to get it to print at the right size. This could be a Fusion 360 issue, but I currently don't have any other applications that support .3mf to test it with.

Didn't realize Cura recognized anything other than .obj and .stl ... still fairly new to this.