DodgeDeBoulet
-
Posts
23 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by DodgeDeBoulet
-
-
12 minutes ago, ahoeben said:
(that's how the bug came to be; I made a silly copy/paste error while implementing that feature)
Satisfying my perversions almost always gets someone into trouble 😆
-
1
-
-
1 hour ago, ahoeben said:
It looks like I somehow gave you the link to the current version instead of the development snapshot. Here is the development snapshot I meant to post. The version - as shown in the Connect to OctoPrint dialog - should be 3.5.15-DEV.
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!
-
1
-
-
5 hours ago, ahoeben said:
Sorry, that's a bug which slipped through testing last time 'round. I have fixed the bug, but have not yet published a new version of the plugin.
You could help me by testing this development snapshot. Download the file and drop it onto the buildplate in Cura as if you were opening a 3d model. It would be great if you could let me know if this bug is fixed, and if the plugin works as expected in general.
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! 😂
-
2
-
-
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?
-
2 hours ago, ahoeben said:
I have not yet gotten round to implementing the functionality of matching the reversedness of the axes with OctoPrint.
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 😄
-
1
-
-
@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 😁
-
1 minute ago, nallath said:
Yup. It's fusions fault (or the add-on). Both files say that they are specified in millimeter.
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.
-
24 minutes ago, bagel-orb said:
You shouldn't change the unit in fusion 360. STL doesn't save the unit in file and every program silently assumes that the unit is in mm.
This is a problem of the STL file format. Try using a less dated file format! Fusion should be able to.export to all sorts of format. Try 3mf.
Didn't realize Cura recognized anything other than .obj and .stl ... still fairly new to this.
-
I guess I need to eat my words ... it's apparently a change in order of magnitude that Blender doesn't get along with either:
So ... apologies. I understand the issue now. The exponents are actually being correctly interpreted, but the assumption is that that "1 unit" is 1mm.
-
10 minutes ago, bagel-orb said:
You shouldn't change the unit in fusion 360. STL doesn't save the unit in file and every program silently assumes that the unit is in mm.
This is a problem of the STL file format. Try using a less dated file format! Fusion should be able to.export to all sorts of format. Try 3mf.
How do you account for the differences in the exponents in the facet stanzas? That very obviously indicates a change in order of magnitude, and it's obviously something that Cura is not correctly interpreting.
-
I've created some stands for an Ableton Push 2 MIDI controller in Fusion 360. For convenience's sake I set the measurement units in F360 to centimeters. However, when I export the STL and load it into Cura 4.5, it materializes on the bed at 1/10th of its intended size. I can re-scale it in Cura by 1000% and it looks right, but I'm surprised I have to do that.
If I set the units to millimeters in F360 and re-export the STL, it looks normal. Here's what a cm-scaled STL looks like compared to a mm-scaled version without being re-scaled in Cura:
And here's the diff output of ASCII versions of the STL files (mm on the left, cm on the right; problem exists whether the STL is exported as ASCII or binary). The scaling is being set appropriately by F360, so (to me) this seems to be a Cura issue:
-
Thanks. I've subscribed to the issue so I won't forget either 😁
-
1 hour ago, ahoeben said:
Hi, I am the creator of the OctoPrint Connection plugin. That plugin is not maintained by Ultimaker, so the there may be hope yet for supporting the setting to invert controls to match what is configured in OctoPrint. I must admit I was unaware of that setting in OctoPrint.
Then I am hopeful. Thank you for taking an interest in this feature!
I understand that you may have competing priorities, and that it may take a while to implement (or never happen). Regardless, I am delighted and grateful that you've built this plugin; it makes the process of pushing jobs to my printer completely seamless.
-
So, I'm feeling a little guilty. I went back into my OctoPrint configuration for the Ender 5 Plus and noted that I have "Invert Control" checked for the Z axis. I set it that way so it would mirror the movement controls in the actual printer's settings screen.
So, I guess it would be nice for Cura to support a similar option, and I withdraw (and apologize for) my complaint about what seemed to be a bug to me 😁
-
1
-
-
It makes sense, but for a display that otherwise so closely mimics the functionality provided by the OctoPrint Control tab, it's counter-intuitive.
If would be nice if this was a user-customizable option 😁
-
I normally use the OctoPrint Control tab to monitor my prints, but I happened to notice that Cura's plug-in offers a Monitor page that provides much of the same functionality. It seems to work fine, with one exception: Pressing the "down" button causes the bed to rise, and the "up" button causes it to lower. A little counter-intuitive ...
I searched the forums and didn't find any other posts reporting this issue ... is there a way to fix this?
Initial Layer Flow: Percentage of Configured Flow Rate or Extrusion Rate?
in UltiMaker Cura
Posted · Edited by 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!