markwal
-
Posts
22 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by markwal
-
-
Verified that upgrading to 382.05 (released on 5/3/2017, four days after my report) resolves this issue on Windows 10. It all works fine now.
-
Windows 10 from 381.65 to 381.89. Hmmm... weird.
-
I forgot to mention the important bit: On Windows.
-
Looks like the new Windows GeForce driver changed something that Cura's QT library is sensitive to. Upgrading the GeForce driver seems to preserve OpenGL support for other software, but Cura refuses to boot saying:
"Unabled to probe for OpenGL support. Cura requires at least OpenGL 2.0. Please check your video drivers."
Or something close to that. I downgraded to Nvidia GeForce Driver version 381.65 and it works, but my guess is that others will start seeing this problem.
-
Ah. You're right. They do work. I attempted on Windows first and it didn't work (probably because I got the path wrong), but now I was debugging on Mac and yep, it's already in the _plugin_locations. So, never mind.
-
How about:
Windows: %AppData%/cura/plugins
Mac: ~/Library/Application Support/cura/plugins
Linux: ~/.cura/plugins
What do you think? I could do a PR unless there's a philosophical objection.
-
Now I'm just logging QQmlComponent.errorString(). Is that what y'all do? That seems to work. I got confused because of CONFIG += QT_QML_DEBUGGING that I ran across while searching.
-
To Cura and/or plugin developers: Looking for a development tip here. How do you debug problems in QML? Under PyQt QQmlComponent.create just returns None when there is an error. Is that error logged somewhere? Do you all just debug the QML under C++ or is there a way to turn on QML debugging in a Cura build? (I'm building using Ultimaker/cura-build on latest master.)
-
Oh I see now, it's just a bug. I thought you'd moved the property and I just couldn't figure out where it went. Thanks for the fix.
-
I agree. But now what is the right way to choose a good default name? It's rather annoying to force the user to type the name they just opened if they'd like the gcode name to match the stl.
-
Before the settings rework branch merge, fileName would be the name of a mesh (the file name of the stl file). It appeared to be the first stl that was opened.
-
fileName is passed in None and remains None after that loop.
-
In current master, it looks like save local no longer proposes the name of the first mesh as the filename. Back to typing in a name. However, my plugin was also trying to use the following to propose an initial file name, but it no longer works. Did the property move? If so, where to?
for n in BreadthFirstIterator(node): if n.getMeshData(): fileName = n.getName() if fileName: break
where node is passed into OutputDevice.requestWrite
-
I notice the LICENSE files in the root of most of the projects, but I'm wondering where the attributions for other included software are (for example Qt?). Are there plans for a more extensive "About" dialog?
-
On the shank, it looks like you're either getting extrusion variability (maybe heat) or perhaps over extrusion. Since it is a thin wall, when you look at the layers in the slicer I think you'll see it isn't an evenly divided by your line thickness (probably nozzle width) so it has to estimate by injecting very thin gap fill. It's probably overdoing it a bit. You'll probably get better results if you can figure out either to have the line widths be a little wider (if your nozzle has a flat portion beyond the orifice, that can work) or change the wall thickness so that it is an even multiple of the line width so there is no gap fill error.
As it moves up, it looks like it is being over heated. My guess is that you're getting reflected heat from the nozzle onto the part that the cooling fan isn't keeping up with. One simple way to mitigate that effect is to print two of the part some distance apart (say 30mm or so) on the bed, so that it gives some more part cooling time before adding the next layer.
-
@gr5 thanks for the follow up. Yes, it does seem to be designed to support the upper layer. I saw this also on an exterior sloping perimeter (not the zigzag, just the short interleaving segments of different speeds. My guess is that at certain slopes and extrusion widths there is a computed extrusion amount that is smaller than the nozzle width and it attempts to achieve this by either filling with a dashed segment or interleaves speeds in an attempt to pull a thinner extrusion alongside the neighbor.
-
Machine: Ultimaker 2
Mode: Advanced
Settings: default
(Sorry, I use youmagine too, but this one is from thingiverse:)
Model: http://www.thingiverse.com/download:907145
from this thing: http://www.thingiverse.com/thing:555242
Generated the gcode here: https://www.dropbox.com/s/1du7l2719pxkgyz/right_knee.gcode?dl=0
Lot's of weird zigzag jerky highspeed motion just inside the innermost perimeter on many layers. For example:
From approx line 12590:
G11
G1 F3000 X109.306 Y110.671 E269.34268
G1 X109.306 Y110.450 E269.35152
G1 X109.052 Y110.585 E269.36303
G1 F144720 X109.224 Y110.496 E269.37077
G1 F3000 X109.533 Y110.747 E269.38670
G10
F144720! Really?
Of course, the firmware acceleration and max caps kick in and it doesn't go that fast, but seems pretty random. The zigzaggy doesn't seem to be necessary except to make the machine load. But perhaps there is a purpose or good reason for generating the zigzags? It's pretty interesting to look at that gcode in http://gcode.ws too. Nice neat layers with a string of rapid/random motion changes just inside the perimiter.
Anybody else seen this? It doesn't seem to happen on every model. Perhaps ones with sloping outer perimeters?
-
OK, I was able to build both 15.06 and latest on ubuntu. It took a little goofing around since I think the build script has gone stale (it specifies -D's that are not actually used by the current makefiles, for example). I got it to run by moving the result files to where they seem to be needed to load. I didn't update the build script since I just fixed things manually.
I could PR fixes to the build script, but perhaps I'll wait to do that until after 15.10 since the output path is where I intend to work. For example, for upload to OctoPrint on save.
I did get a simple save plugin to work with the 15.06 output model.
-
I'd like to try my hand at a bit of Cura 15.06 plugin development. I've got a good start from nallath's examples, but I'm wondering if I can run Cura from source in-place to make debugging them easier. Any pointers?
-
1
-
-
When you install it, it says:
New in this version:
* Fixed a small issue where Cura sometimes failed enable the save button
* Added save gcode shortcut key (CTRL+G)
* Update UM2, UM2go and UM2extended firmware for the new support url on errors
* Fixed small issue in the UM2go firmware
But I noticed also, that they moved Cura sources to Ultimaker. And it looks like a lot of changes to the build mechanics.
-
Well, you could leave the temp setting and the fan speed out of the start gcode in cura and then put them in the "start job" gcode in octoprint. Then you can adjust the gcode scripts in octoprint directly for each job. And then, if that works, a plugin writer could come along and make it easy to have start gcode selectable per job.
Cura License update – from AGPL to LGPL.
in UltiMaker Cura
Posted
I'm one of the contributors who will sign the agreement since my contribution is a very small part of the whole so I'm happy to hand it to Ultimaker to do with it what they wish.
However, I hope this doesn't mean that Ultimaker is having trouble with people just using their significant contributions without contribution back. I do enjoy tinkering. While I'm perfectly happy that there is proprietary code in the world and that people are able to make a profit off of intellectual property, I hope this doesn't mean that significant future contributions from Ultimaker to Cura will be cloud only or proprietary. I can understand why Ultimaker might need to do that, but just for my own hobbyist interests I'd rather be able to tinker. Especially with the newest stuff.