Jump to content


Team Ultimaker
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ghostkeeper

  1. There is no interface element for it. We consider this to be an expert+ functionality, because people who have the skill to build their own 3D printer are also smart enough to edit a JSON file. To be able to edit this, you need to create a printer definition in Cura for your printer. This printer definition is a .def.json file just like the other printer definitions. The other printer definitions are located in the installation folder of Cura for your operating system (Windows): Usually C:\Program Files\Ultimaker Cura 4.1\resources\definitions You can place a new definition there, or if you don't have admin access you can also place them in C:\Users\<AbeFM>\AppData\cura\4.1\definitions To have an example printer definition to work with, I suggest copying a .def.json from a different printer that is most like your printer (in the number of extruders it has and its capability of switching out material profiles, nozzles, etc). You will also need to copy the extruder definitions in the \extruders folder for your printer. Then under the "overrides" header in those JSON files you can edit the nozzle_offsetting_for_disallowed_areas and such to what you need.
  2. In my experience, Lines and Zigzag are easiest to remove, followed by tree support and concentric. The rest of the patterns are all really tough which makes them hard to remove. Overhangs that are really close to the build plate are always problematic regardless of the pattern. That is my most common use case for PVA support. The Settings Guide doesn't mention Gyroid yet because it's really new. I'm working on an update for Cura 4.2 that includes Gyroid.
  3. Printer definitions can put disallowed areas in the scene that move along with the nozzle offset as well as disallowed areas that don't. The disallowed areas that move with the nozzle are stored in the machine_disallowed_areas setting. They indicate where the print head is not allowed to go. This is used for instance in the Ultimaker 3 for the camera in the front right corner. The disallowed areas that don't move along with the nozzle offset are stored in the nozzle_disallowed_areas setting. They indicate where the nozzle is allowed to go. This used to be used for the bed clips in the Ultimaker 3, until we found that the clips can also collide with the inactive nozzle anyway. Currently no built-in printer makes use of this one. Apart from those, Cura also generates disallowed areas to not go outside the build volume. You can configure those to either move along with the nozzle offset on both sides (as done for the Ultimaker 3) or on neither side (as done for the Ultimaker S5). This is determined by the nozzle_offsetting_for_disallowed_areas setting. So for your case you should disable nozzle_offsetting_for_disallowed_areas, then create a machine_disallowed_area on the right hand side.
  4. No, not one file. That would be shadow administration, because we also need to keep the information separate per profile layer. There's a couple of ways you can get at this though. The "user" profile contains all of the changes that you've made but not stored in a profile. The "user changes" profile contains your custom profiles. Those two combined normally add up to all your changes. If you've made custom materials those will show up in the "materials" folder and if you've edited the machine settings those will show up in the "machine_changes" folder. This is Cura's main profile administration, which is, unfortunately, split up. Saving a project file puts all of the relevant profiles in one file. It's a zip file so you could open it up with 7-zip or something. However inside the archive they will be separated in the individual profile layers again. In the log file of Cura it lists the commands that were used to start the slice. This command contains all settings that were used, hundreds of settings. Keep in mind that it also keeps all of those settings again for every extruder, so some settings will be in there multiple times (if they are settable per extruder).
  5. It's already integrated. It's in! But we've just today found an issue with Creality project files from before the merge not working after the merge. Hopefully we can get that fixed before the 4.2 beta or at least before stable.
  6. Okay, thanks! That's bad news but in a way also good news because we hadn't changed anything to fix it so I was worried that we might accidentally trigger the problem again later without knowing how to fix it...
  7. Users on Github are reporting that this issue seems to be gone in Cura 4.1.
  8. The machine settings for Steps per Millimetre are normally not visible (only because you installed a plug-in that makes machine settings visible). They are not used currently by CuraEngine but only by the X3GWriter plug-in to convert to X3G properly. However in the future we might use them to improve aliasing when rounding to steps or halfsteps.
  9. Yes, here: https://github.com/Ultimaker/Cura/issues/5265
  10. Yup, it hasn't changed. My statement wasn't quite complete though. There are multiple orderings going on, from significant to insignificant: It needs to print all mesh groups in order (in case of one-at-a-time mode) so that they can be printed without colliding with the print head. It needs to print all layers from bottom to top. It needs to print all extruders in such a way to introduce the fewest extruder switches. It needs to print all meshes for an extruder in such a way to reduce travel distances, by nearest neighbour (as described above). Within a mesh, if a mesh consists of multiple simple polygons at a certain layer, it needs to print all parts in such a way to reduce travel distances, by nearest neighbour (as described above). It prints all of the part together. Usually it doesn't print just a loop for the outer wall, but also inner walls, infill and skin. It's not common to end at the same point. Neither, to be precise. It finds the closest point on each polygon from the starting point (so you get a bunch of coordinates on the borders of polygons), then from those points chooses the closest one to go to. Then it prints that polygon completely and ends up on a new position. It again finds the closest point on each remaining polygon from the new starting point and chooses the closest one again, and so forth until there are no polygons left. Indeed it is. The starting position is two settings: Layer Start X and Layer Start Y. It's not (necessarily) on an existing polygon and it doesn't actually travel to this starting position first. Previously we had the option to make the starting position the position where the nozzle ended in the previous layer, but that didn't work any more once we introduced multi-threaded slicing. It uses Pythagoras, but omits the square root, so we're comparing squared distances. It's not so taxing then, just two multiplications, one addition and a comparison per polygon. It scales quadratically but you'll rarely have more than 1000 polygons anyway. In fact, we're doing the same algorithm to determine the order in which to print skin lines and infill lines. https://github.com/Ultimaker/CuraEngine/blob/a03d9291c6d9a37e8b4f23df60d76c249c045172/src/pathOrderOptimizer.cpp#L16 There's some stuff in there for finding the proper location to put the Z-seam as well that you can ignore (unless you do want to write about that because it's specific to 3D printing). There is also an optimisation that I hadn't mentioned yet with a bin map, which finds points that are very close together faster (the grid is stored in the loc_to_line variable).
  11. Changing support settings for an object will change how that object is supported. So if you change the Support X/Y/Z Distance for a custom support block, you're changing how that block would be supported but the block itself isn't supported so it has no effect. The block causes the model to be supported. The support X/Y/Z distance can't be changed for just parts of your model. I'm sorry. You'd need to change it everywhere or nowhere, or indeed model the support yourself in CAD.
  12. You need to look at the following four settings: Support X/Y Distance Support Z Distance Support Distance Priority (normal support only, not Tree support) Support Min X/Y Distance (normal support only, Z overrides X/Y only) I would expect that reducing the X/Y Distance has a lot of effect for you, but don't reduce it to below 0.3mm or so because then your support will stay too close to your model sideways.
  13. We did some things to improve that, which should be released in 4.0.
  14. PETG and HIPS are not supported for the Ultimaker printers. You can download that profile, and it'll show up for some other printers, but we disabled it for the Ultimaker printers.
  15. I did a performance test on that 3.5 file using Callgrind and got this result: http://dulek.net/work/3.5-beta-callgrind.out.3886 This seems to point to this change: https://github.com/Ultimaker/CuraEngine/pull/791 We'll continue discussion there.
  16. We expect that 1 or 2 lines of code need to change for most plug-ins. It's not much, but the developer needs to figure out the stuff that is broken, test it, package it and re-submit it which could be an hour or two of work. Also, some people have loads of plug-ins up there which could be quite a significant amount of work to do for all.
  17. A more complete list of features is in the great blog post, written up by my friend Matt: https://ultimaker.com/en/blog/52715-whats-new-in-ultimaker-cura-35-beta An even more complete list (that includes the most significant bug fixes as well) is in Cura itself. You can read that list from Cura's source code here: https://github.com/Ultimaker/Cura/blob/master/plugins/ChangeLogPlugin/ChangeLog.txt
  18. What's that error traceback that you see in the first textbox?
  19. There can only be one bed temperature. Bed temperature is a global setting, so shared between extruders. Cura indicates these sort of settings by displaying a chain link icon next to the setting. Each extruder has its own defaults for most settings. Like the print temperature and such, these can be different for each extruder. That is a problem for Chimaera-style nozzles because Cura will try to set the temperatures for both extruders to different temperatures but on your nozzle only one of them can win. There is no real solution for that yet (and no priority from Ultimaker to make one) but you can work around it by removing some temperature commands using the Search-and-Replace post-processing script. Some default settings that are global can still be set by the material profiles per extruder. This is kind of a complex system, but necessary for things like the bed temperature. For these, there is a resolve function that Cura defines per setting. For instance, for the heated bed temperature, Cura chooses the highest of the temperatures of all nozzles. Make sure you check "Enable Prime Blob" or use a skirt/brim/raft for the extruders that need priming at the beginning of a print. Use a prime tower if you need them primed after each extruder switch (strongly advisable for Chimaera!) Don't bother with the ooze shield in my opinion. Use a prime tower for your Chimaera printer though.
  20. Did you try updating your graphics drivers? Cura indicates in the log that you support OpenGL 3.3, which is pretty old (released in 2010). They are at version 4.7 right now.
  21. That is the correct log file ? Only there is nothing in the log that indicates that Cura finds something wrong on your computer. Technical background: I suspect, also from your pictures, that it's some redrawing bug in Qt. We aren't seeing it on our computers though. I can't find that it has been reported on QtBugs anywhere either, so the chance that it'll get fixed in Qt 5.10 is small. In the next Cura release we've updated to a newer version of Cura's GUI framework, Qt. There is some chance that that fixes things but don't keep your hope up. I looked through the Cura code that generates these comboboxes and the application menu but there is nothing to indicate that the opacity of these menus get set to 0% or anything... ?
  22. That log file is from September 2017. At some point we moved the log file into the folder of the specific version you're using. Could you look into the /3.4 folder for another log file? Sorry for the confusion.
  23. Cura stuff around your print and forbids you from slicing if that extra stuff would move outside the build volume (since that could damage your printer). Some of the stuff that's added around your print includes: Brim Skirt Raft Avoid Objects when Travelling Draft Shield With default settings, setting the brim size to 0 and disabling Avoid Objects When Travelling will allow you to print stuff using the maximum volume of your printer.
  24. We haven't seen this on our testing computers. That makes it a bit hard to fix the problem. Maybe there is something in your Cura log? Could you post that here?
  25. Looking at the log file again. I fixed a broken colour that I found because of that log, so thanks already ? So in the log it appears to be crashing right after it initializes the shaders and right before or during initialization of the main window. The most likely culprit is these lines: 2018-07-22 05:06:55,824 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:19: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,826 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:104: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,829 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Topbar.qml:175: TypeError: Cannot read property 'stageId' of null 2018-07-22 05:06:55,831 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:433: TypeError: Cannot read property 'mainComponent' of null 2018-07-22 05:06:55,834 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:427: TypeError: Cannot read property 'mainComponent' of null 2018-07-22 05:06:55,836 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:465: TypeError: Cannot read property 'sidebarComponent' of null 2018-07-22 05:06:55,839 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [301]: file:///C:/Program Files/Ultimaker Cura 3.4/resources/qml/Cura.qml:497: TypeError: Cannot read property 'sidebarComponent' of null From this it appears that `activeStage` is null at that time which is weird to me. Also strange is this line: 2018-07-22 05:06:37,560 - INFO - [MainThread] UM.VersionUpgradeManager._getUpgradeTasks [272]: Config file [.\cura.cfg] is of version [6000000], which is different from the defined version [2000000], no upgrade task for it from type [preferences]. There it looks like someone mixed up two of the version numbers that we have in Cura.
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!