Jump to content

ghostkeeper

Team UltiMaker
  • Posts

    209
  • Joined

  • Last visited

  • Days Won

    2

ghostkeeper last won the day on March 7 2018

ghostkeeper had the most liked content!

2 Followers

Personal Information

  • 3D printer
    Ultimaker 3 (Ext)
  • Country
    NL
  • Industry
    R&D / Exploration

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ghostkeeper's Achievements

105

Reputation

  1. So then reducing the Minimum Wall Line Width will allow it to print with two walls then, using thinner lines. Does that not solve your problem? Effectively, you could see the Minimum Wall Line Width simply as the threshold at which it starts using more, thinner lines.
  2. I can clarify that a bit. Default X-Y Jerk is indeed used for two things: Getting correct time estimates, if jerk control is disabled. If Cura doesn't control the jerk, the firmware has its own defaults. To get correct time estimates, Cura has to know what the firmware's default is then. Resetting the printer to its firmware-default X/Y jerk value at the end of the print (if jerk control is enabled). That way, your prints don't influence later prints done on that same printer even if it's printed with a different slicer. The second usage is what Ahoeben found there.
  3. This discussion is about a geometric term called the "miter limit". If you perform an offset or inset of a shape, very sharp corners may move a long distance, so the sharp inner corner of your layer would move a long way inside. The miter limit adds a cap on that. If the corner is further away than a certain number of insets, it'll get capped off and turns into two shallower corners. I think the original model was just on the edge of this miter limit, and got capped off on one side due to rounding errors. MDN has a nice explanation of it here (since it's also a CSS property): https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Applying_styles_and_colors#a_demo_of_the_miterlimit_property Cura uses a miter limit of 1.2 for most things (including wall insets), meaning that corners get cut if the inset vertex would go beyond 1.2 times the offset distance: https://github.com/Ultimaker/CuraEngine/blob/6fc5f512f2d0dfe602a3d1b71d61853578cb8b42/src/utils/polygon.h#L128 A miter limit of 1.0 would mean that corners are exactly as wide as the normal wall. This is not always desirable though, since corners are also weak points of the print. We went for 1.2 as a balance. Arachne produces round joints instead of miter joints, by the way. The miter limit is removed from the walls there.
  4. Admittedly, it's hard to get right. This is where the scale is determined (in particular the unit_w and unit_h variables, determining how big each unit length of the SVG will be IRL): https://github.com/Ghostkeeper/SVGToolpathReader/blob/b12fc84aad90f2d4a9dac00d1c676b47dda4b0d8/Parser.py#L1352-L1372 In effect, the viewBox property determines how big the image should become, in millimetres. The image width and height determine how it should scale the image to be in that viewbox. It doesn't do any clipping. Looking at this now, it does seem to be somewhat different than how SVGs are normally rendered on a screen. This may need some fixing, if you can post an example in Github Issues of an SVG that goes wrong: https://github.com/Ghostkeeper/SVGToolpathReader/issues
  5. GR5's initial response is also the only one that Cura itself explicitly creates; the folder in Application Support. Other side effects of using Cura that I can think of are: MacOS creates a system log for every application. That's the one you deleted. MacOS itself created that one so it's probably best to not mess with that (though in this case it probably doesn't damage anything). You may have made file associations, e.g. for STL files to open with Cura. Since version 4.9, Cura also adds a keychain entry upon logging in to store the log-in token more securely. However since 4.8 didn't have a library to read the keychain yet, it shouldn't be influenced by this. A perhaps more likely cause for the problem is that your operating system itself has changed. For instance, Cura 4.8 didn't have support for Big Sur yet. If you updated to Big Sur since the last time you used 4.8, that might explain why it's no longer working. If you fill in an issue on Github it'll have a template where it asks for relevant information such as the operating system. This helps to narrow down the issue. And we're also quite curious as to why 4.9 won't run...
  6. The setting Remove Mesh Intersection prevents meshes on multiple extruders from extruding in the same area. If you disable that, you can achieve toolpaths that cover the same area. Getting it to produce exactly the same paths could be tricky though. Need to make sure it has exactly the same settings everywhere, at the very least. With a post-processing script this is pretty doable. That would be the preferred solution in the end at least, but requires programming skills. If you really want to get into the code where this collision prevention is implemented, it'll be here: https://github.com/Ultimaker/CuraEngine/blob/master/src/multiVolumes.cpp . However implementing a post-processing script is likely going to be easier than making modifications there (and compiling CuraEngine afterwards).
  7. Need to look into Firefox add-ons like uMatrix and NoScript, since this upload is made directly to the Google Cloud Platform, so you'd need to allow access to those domains.
  8. No, the initial layer is also sliced through the middle of its Z range: https://github.com/Ultimaker/CuraEngine/blob/991cd026ffccc6def5e5b6a937edd6ae1b7cc8bf/src/slicer.cpp#L957
  9. The real answer is that it depends on the Slicing Tolerance setting. But going by the default of "Middle", it would create a cross section from the middle of the Initial Layer Height. So if your Initial Layer Height is 0.2mm, it would create a slice at Z=0.1mm. Thus, you'd need to make sure the bottom of that sphere protrudes by less than 0.1mm.
  10. Indeed, as ahoeben already said, the changes to CuraEngine can't be implemented from a plug-in. You might be able to make changes in a post-processing step that works on the g-code string, but anything involving the polygonal shapes of support, slice layers, etc. will probably be impossible because it's very hard to retrieve the original shapes that were intended to be printed from just g-code. So you can't just perform a polygon offset or anything. Since you need to modify things in FffPolygonGenerator and FffGcodeWriter, I'm pretty sure that you can't do those things from just post-processing and will need to modify CuraEngine itself. Cura has always just had the scope of FFF printing by design. There is however one SLA printer in Cura's printer list (Peopoly Moai) which is in a similar situation as you. They interpret Cura's g-code to generate the structures that will be solidified, if I understand correctly. The names of these files have been this way since CuraEngine was started by daid (they were renamed at some point from "fdm" to "fff" only) and even then I think his only intention was to make it work for FFF. For instance, a polygon generator for SLA or something would be very similar in many ways, so that would need a more generic architecture anyway. In any case, don't wait on us to implement things outside the scope of FFF ;) Of those, Nallath, Fvrmr, Rburema and I are in the Cura team (along with Jellespijker, Konskarm, Vandrasc and Evtrados who aren't active on this forum as far as I know). SandervG works for Ultimaker but not directly in the Cura team. We generally have fairly little to do with each other but we communicate about blog posts for Cura's releases. Ahoeben and Burtoogle are active outside contributors and know a lot about Cura in general.
  11. Hey. I can share what I know of the X3G conversion. Thanks for the ping, Greg. The X3GWriter calls upon an executable called GPX to convert g-code to X3G: https://github.com/markwal/GPX The X3G files work slightly differently than g-code files and they need slightly more information. Sometimes this is where mistakes sneak in. GPX accepts extra settings as parameters and Cura translates most of those to machine settings that you can modify through the Printer Settings plug-in on the Marketplace. This means that *machine settings may affect the X3G conversion*. In particular, the Maximum Feedrates and steps per mm are important. The full list of conversions between Cura's settings and GPX settings are here: https://github.com/Ghostkeeper/X3GWriter/blob/1386edb609b467b7457a98f99cd693095bf22a61/X3GWriter.py#L219-L281 Aside from that, GPX also has a number of pre-defined profiles. In Cura you can choose one of these via the machine_x3g_variant metadata entry. The list of pre-defined profiles doesn't include the Duplicator 4 though. Here's the complete list: https://github.com/Ghostkeeper/X3GWriter/blob/1386edb609b467b7457a98f99cd693095bf22a61/X3GWriter.py#L168-L187 So to create support for the Duplicator 4, you need to somehow find out what settings are necessary in GPX to convert g-code to X3G. I don't know those and can't really help you testing them. Then you need to fill those into the machine settings in Cura. If you get them to work, perhaps we can add a profile to the GPX application too.
  12. The last real change to the Marketplace was in July when the rating system was removed. Our main focus lately (the last 3 months) has been the variable line width algorithm. But that all doesn't matter since the prime blob routine is implemented in the printer's firmware, and focus/resources in Cura development do not detract from what happens in firmware. All Cura does is output the "G280" command. We have absolutely no control over how the printer moves the bed then. For that reason it'd be better to post this in a place that is more frequented by firmware developers: https://community.ultimaker.com/forum/109-firmware/
  13. I don't think I should die for this error 😄 At least not as long as the Settings Guide shows it correctly: https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/support/support_xy_overrides_z.md I'll ping the website content people if they can fix it. They are the maintainers of those pages. Thanks for paying attention!
  14. The 15.04.06 Debian archive specifies that it requires the following packages: python-wxgtk2.8 or python-wxgtk3.0 python-opengl python-serial python-numpy I don't know in how far those are still maintained for modern Ubuntu or Mint versions. You'll probably still be able to find them online somewhere but maybe not in apt. These are for Python 2, mind you, which has reached end-of-life.
  15. I generally respond to those pings, although I don't track issues on the forum itself. If you seek to modify the layer heights, look for the buildLayersWithHeight function of the Slicer class: https://github.com/Ultimaker/CuraEngine/blob/51ee4b7adf6dfd112241cdf3fd5681e87cf6370c/src/slicer.cpp#L929 In this function it determines the Z coordinate of each layer, either by calculating from the layer height and initial layer height, or by asking the AdaptiveLayer class.
×
×
  • Create New...