ghostkeeper
-
Posts
209 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Events
3D Prints
Posts posted by ghostkeeper
-
-
3 hours ago, carvedblock said:
I don't really get it though. Cura wise, is there any difference between setting the nozzle diameter to 0.35 and setting the line width to 0.35? (for nozzle of 0.4mm in reality).
Yeah, a couple but it depends a bit on your printer. For Ultimaker 3 for instance, we've set the line width to be a formula, equal to 7/8ths the nozzle size. So if you set the nozzle size to 0.35, you'd get lines 0.306mm wide, but if you set the line width to 0.35mm, you'd overwrite the formula and get lines of 0.35mm wide.
Apart from that, we've also got some other things depend on the nozzle size, such as Outer Wall Wipe Distance (which is set by default to half a line width), but apart from Line Width it's all really minor.
https://github.com/Ultimaker/Cura/blob/b00502d10fdfeac9b87465b693e055c6b6406673/resources/definitions/ultimaker3.def.json#L10
3 hours ago, carvedblock said:Also, what about the the case when I set the line width to 0.45 (nozzle is 0.4)? The slight overextrusion should also force lines to blend more, or not? I am still missing a piece of this.
You can see this happen really well in the initial layer if you look closely. If you set the line width higher than your nozzle size you tend to get worse horizontal adhesion because the extruder can't handle the pressure pushing against the filament well. But you should get better adhesion vertically because you're really pushing the filament down hard then. This is why we're setting the initial layer line width to 120% by default, to get better bed adhesion.
Personally, in most of my prints, I like to increase the skin line width a little bit and then enable ironing. Increasing the skin line width reduces the printing time a lot because you need fewer lines. Ironing then makes the top surface look nice regardless of the crude lines/underextrusion.
-
2
-
-
There is no guide to post-processing scripts, but I've always recommended people to take a look at the other scripts as example. The search and replace script is really simple and should be clear for adaptation: https://github.com/Ultimaker/Cura/blob/master/plugins/PostProcessingPlugin/scripts/SearchAndReplace.py
-
3 minutes ago, Brulti said:
@ghostkeeper Is the box only for the formatting or can I just type something like 'Printer 01' and it will work as well?
We were imagining that you'd type something like: {printer_name}_{model_name}_{date} where {printer_name} gets replaced by the name that you gave the current printer, {model_name} gets replaced by the file name that you loaded and {date} gets replaced by the current date. If you were to type 'Printer 01' then it would always give the same name to the print job regardless of what you're slicing.
-
Yeah, I was about to! Our final decision was to turn the current check box in the Preference window into a text box where you can fill in a formatting string, similar to media tagging software. It's not all that hard to use but covers everyone's use cases.
-
3
-
1
-
-
I think we have a big enough sample size. We'll discuss the results on Wednesday.
This was sort of a pilot to see how people would react to involvement in this way. The issue itself is pretty small (trust me, we're tackling bigger issues first really), but it's interesting to hear how people organise their g-code files.
We're hearing your feedback that it needs to be customisable and that it would be more useful to have a suffix instead. The suffix should be no problem (if people agree within the team). Customisable may be a bit too much detail for a preference but we'll discuss that Wednesday then. Thanks for participating in any case!
-
2
-
-
26 minutes ago, UbuntuBirdy said:
Absolutely not needed! I like to have files with the same name from CAD, STL, GCODE. We have the extensions, wo have different icons and we have time and date of creation of the files.
For me this is a absolute useless feature - but that's only my opinion.
There is already a preference to disable it: "Add machine prefix to job name"
-
What if you add 2 extra lines to your brim? Does that then not function as a skirt?
-
We could have an incremented slice version number but that would reset if you restart Cura then or rename the file you're slicing.
For clarity, with "An acronym based on my selected printer's name" we mean that if you call your printer "Ghostkeeper's Printer" then the acronym would become "GP".
-
1
-
-
This error happens in Windows when mixing up 32-bit and 64-bit applications.
Two things you could try:
* Don't install a new version of Cura on top of an old installation. So either select a different directory to install it to, or uninstall the old version first.
* Make sure to install the Visual C++ Redistributable when the installer prompts you to.
In short, I ask you to install Cura again.
-
41 minutes ago, Brulti said:
As a non-engineer, I do also hope that there will always be a way to access the full range of settings, because I want to learn and tweaking settings is a way to learn, plus, sometimes, on that one special model, you do need to tweak a setting that would otherwise never have touched.
And I don't believe in the 'one-size-fits-all' approach of the Occam's Razor. This can work only in a civilization of clones.
55 minutes ago, nallath said:Yeah. We will keep this available. I'd like to think that this is why engineers like our product. If you want to, you can "open the hood" so to speak, in order to mess with the internals. This is why we only give errors for settings that we *know* are impossible or will break the hardware. Really improbable values will just net you a warning.
Actually, for some of the settings, I'm sort of putting my foot in the door and try to steer it such that it doesn't become a setting. Because some of these settings are just so complex to use for the user that they will hardly ever be used at all. Or there is just one option that is in every case better than its alternatives (but takes 0.05s longer to compute in the engine or something).
-
1
-
-
There's more information here: https://github.com/Ultimaker/Cura/issues/3725
It's being investigated.
-
On 4/26/2018 at 8:17 PM, yellowshark said:
If one specifies a line width of 0.5 then Cura will calculate the volume of filament to be extruded, per second or whatever, to create a .5mm line over the given distance in the time allotted from the print speed.
Almost. Cura calculates the total extrusion for the entire line. The print speed is irrelevant then.
On 4/26/2018 at 8:17 PM, yellowshark said:I assume that the printer calculates the speed that the filament drive wheel has to turn to meet the requirements in the gcode. So, up to and only up to a point, the size of the nozzle is not too important; there will be less pressure with a .55 nozzle because the filament just flows through the nozzle to create a .5mm line and more pressure with a .45 nozzle because the filament needs to be forced through the small orifice fast enough to create a 5mm line. Once one goes beyond that point one will end up with a line that is not 5mm wide and/or failure because the printer drive system cannot cope with the pressure it imposes.
Correct!
On 4/26/2018 at 8:17 PM, yellowshark said:One aspect that still eludes me in terms of where it fits in, is that my printer, driven by Repetier Hoist, knows what size nozzle it has (I assume!) because that is defined in the Repetier Host printer settings. I am not understanding what the printer end does with this knowledge, perhaps nothing?
I don't know what Repetier does with it. They work with CuraEngine though so if that nozzle size directly drives line width they'll do some translating.
Cura knows the nozzle size as well and does a few things with it. Here's a 100% complete answer for those who are interested:
- Most significantly: Set the default line widths to use. Our formula for this is that the line width should be 7/8ths the nozzle size. This seems to give best results, since it causes lines to slightly overlap, producing a stronger part. For some lines, such as infill, we use a bit thicker line width in some profiles.
- Determine how far inwards the nozzle wipe starts on a prime tower. You want to wipe off the whole nozzle.
- Determine how short skin lines can be before they get merged together. You can see this happening when you have a piece of skin inside a sharp corner: The last skin line in the pointy corner will sometimes not be parallel to the rest of the skin lines any more but will be aimed inward into the corner. This threshold depends on the nozzle size. I think the idea here was that the nozzle size is sort of the limit of the amount of detail you can apply in such a corner.
- Default value of several detail settings: Outer Wall Wipe Distance, Outer Wall Inset, Minimum Support X/Y Distance.
- Warning threshold for lots of settings in the interface are dependent on the nozzle size (like 50 settings or so).
-
2
-
1
-
4 hours ago, cjs said:
I don't think that Cura calculates the pressure build up in the nozzle. I may be wrong, but I never heard such. I think @ghostkeeper may know more.
Indeed Cura doesn't have any such modelling. And neither does the firmware. All things in Cura related to this, such as coasting, involve compensating measures to counteract the effects of the pressure differential in the nozzle at specific points in the print. Hand-wavy techniques, so to say.
38 minutes ago, yellowshark said:What was confusing me I think is what I have never understood and that is how can a nozzle which has a 0.4 nozzle (in reality, not specification) push out anything other than a line that is 0.4mm wide - and yet people set line width either side of the spec. Cura always used to need nozzle diameter and line width which always made me think that the nozzle width came into the calculations somewhere
If your nozzle extrudes enough material to fill a 0.5mm wide line, then that material has to go somewhere. It goes sideways, producing a line of the desired width. Of course, this only works up to a certain point or the pressure in the nozzle is going to exceed the pressure that your feeder can exert on the filament. And it has some detrimental effects in corners as well.
Cura models lines as being rectangular. It instructs the printer to extrude exactly as much material as is needed for a rectangular block of 0.1mm high, 0.4mm wide and 10mm long for a layer height of 0.1mm, line width of 0.4mm and line length of 10mm. 0.1mm * 0.4mm * 10mm = 0.4mm^3, so you'd see an increase in the E value of 0.4 for such a line. In reality, the line sags a bit so the line is slightly wider. And the line collides with the lines next to it and this increases backpressure which causes the material to slip a bit again. There's a million effects going on there... Some people have gone really deep into researching this.
If you ask me, the most significant effect in dimensional accuracy is that lines get dragged along with the nozzle in corners after just being extruded. This means that the line will always sort of take a "shortcut" in a corner because the nozzle drags the fluid along with it in the corner a little bit before it's fixed on the surface. The effect is that inner corners are slightly too small and outer corners too. We sort of have a fix with the "Post Stretch Script" in Cura's post-processing scripts. It's a bit crude but with some models really effective. If you can think of a reliable solution in software that would be awesome.
-
1
-
-
8 hours ago, createthis said:
I recently upgraded to the latest firmware on my UM2+ in order to gain the ability to print TPU for quadcopters. It prints great (love this!), but I immediately noticed a big blob on my prints. Switching back to PLA, there's that blob again. Is there a workaround short of waiting for Cura 3.3?
Two workarounds, depending on how technical you are. Choose one:
- Download this file: https://raw.githubusercontent.com/Ultimaker/cura-binary-data/master/cura/resources/firmware/MarlinUltimaker2plus.hex And then upload it via Cura by going to the machine manager, click Upgrade Firmware then Upload Custom Firmware and select that hex file (also connect via USB first).
- Or go to the machine manager, click Machine Settings, and then paste the following text in the "end g-code" field:
Quote;Version _2.6 of the firmware can abort the print too early if the file ends
;too soon. However if the file hasn't ended yet because there are comments at
;the end of the file, it won't abort yet. Therefore we have to put at least 512
;bytes at the end of the g-code so that the file is not yet finished by the
;time that the motion planner gets flushed. With firmware version _3.3 this
;should be fixed, so this comment wouldn't be necessary any more. Now we have
;to pad this text to make precisely 512 bytes.
-
1 hour ago, drayson said:
@ghostkeeperSo that means the issue with the the start/endcodes which forces all extruders to heatup without cooling the not used one are already fixed?
1 hour ago, drayson said:EDIT1:
had the chance to take a look into it on a PC of y colleague.
Looking at the gcode, if disable one train, it heats up and holds prepared (without cooldown) also the secon (disabled) train...
Any hint to overcome thi issue? From my point of view, this is not usable for UMODE....
1 hour ago, drayson said:@ghostkeeper
EDIT2:
checked what happens if just using train2...
it heats up just T1 (that'Sok), primes it buth then swichtes to T0 (train 1) and tries to prime it even when it's cold...
Seems that there is something wrong... Any hint appreciated...
No, this bug still exists as far as I know. Only I also know that it doesn't occur with the Ultimaker 3, meaning that it's something in the definition files that's different between the two.
The bug was kicked off of our planning because they didn't think it was important enough. But if someone finds out what causes this then we might be able to fix it still.
-
On 13/04/2018 at 1:41 PM, drayson said:
Going though the change log I recognized
Single extrusion mode Ultimaker 3
Single extrusion mode allows to disable the unused extruder. This has the following positive effects:
- Printing profiles are optimized to print with a single extruder, increasing print quality.
- Global settings, like build plate temperature, are set for the active extruder.
- The ‘print one at a time’ feature is now available.@ghostkeeper, @nallath, is this REALLY only applicable on UM3 or can it be also applied on an UMO Dual Extrusion?
Can't test it by myself as cura 3.3 beta always crushes at startup (had this also on other betas, wheras on finals it's no issue...)
No, this is applicable to all multi-extrusion printers, so also UMODE. It allows you to temporarily disable some extruders, preventing the profiles in those extruders from influencing your settings for the extruder you're printing with and allows you to print one-at-a-time.
-
1
-
-
38 minutes ago, Brulti said:
Thar's an interesting idea, but I don't think drawing the line directly into CURA would be easily doable, if at all. However, the ability to tell CURA that it must consider an object as the shape for the support-blocking feature might be easier to do.
So, we'd create the blocking object outside CURA in whatever 3D program one uses, import it in CURA and tell CURA 'this object is the support blocking shape'. What do you think?
This already exists. You can load your model in Cura and in Per Model Settings select your mesh to be "Don't support overlap with other models".
In fact, that's what we started with. This new support blocker just places such an object in the scene with a pre-generated cube so that you don't have to go through CAD software.
-
17 minutes ago, Brulti said:
CIRCULAR PRIME TOWERS! ... Hum, sorry...
Although, I think if we want to have really stable prime towers and eliminate almost completely the chance that they get toppled over for some reason, especially on tall prints, we'd need to have the prime towers be wider at the base than at the top, like a pyramid or something alike. I've no idea how hard or easy it would be to encode that though. And to have the Prime Tower menu allow us to define 'Tower Base Thickness' and 'Tower Top Thickness', with a check in CURA making sure that the base is wider than the top, and that the top isn't just a single pixel in width.
That by itself is easy to implement. It's probably harder to then predict beforehand how wide the prime tower is going to be to determine where the user is allowed to place objects before slicing.
-
10 hours ago, papavomsee said:
Hello,
Creality CR-10 here.
Have 3.2.1 installed without problems.
Beta 3.3 crashed instant with my configuration.
With blank config it will start, selecting CR-10 and Add Printer it will crash :(Next start the wizard is back, nothing configured.
If I choose for example Ultimaker 2 it works.
If i try to add the cr-10 later, it will instant crash again.
Seems it don't like my cr-10 anymore :(
Link to cura.log
https://www.dropbox.com/s/caqdrq9e1eoqszr/cura.log?dl=0We now have a "fix" that'll likely be included with 3.3 stable that causes Cura to no longer crash on this but instead deactivate the printer and display a message.
As for the actual bug though, it looks like someone renamed the "low" quality profile to "fast". I'll implement a version upgrade routine to fix that for other people, but for you your configuration will stay broken because your files have already been upgraded to 3.3.
Thanks for testing and helping us debug your bug
On 28/03/2018 at 9:44 AM, ahoeben said:I am not sure if that was an intended change.
I don't think it was, actually. You like it better?
-
1 hour ago, Tafelspitz said:
Stupid question: how doI get the new firmware into the machine? Couldn't find a "howto"
That's not a stupid question!
You download one of these .hex files to your computer. Then you open up Cura and connect your computer to your printer with a USB cable. Then in Cura you click on your printer's name in the top-right, go to "Manage Printers...". Then click on "Upgrade Firmware" and select "Upload custom firmware". Then you should be able to select the .hex file you downloaded and it'll upload that firmware.
I don't know if it's documented somewhere on this website. If not, there should be some how-to somewhere I guess (though uploading custom firmware is fairly advanced).
-
1
-
-
Not as far as I know. You can install an image from an SD card as per gr5's initial post, but it won't automatically run from the SD card itself by default. The printer is in many ways a full-fledged computer though so if you can still run the printer and get it into development mode you can access it via SSH (username and password: ultimaker) and then you may be able configure it differently by installing Grub or something.
The printer normally accepts a Screen connection via USB with the two pins on the board next to the power input. You could also try that if it's not in development mode.
I'm not very experienced on the firmware side of things though (or the internals of Linux for that matter) so maybe someone like @Daid can give you a better answer.
-
3 hours ago, cjs said:
Update: Did find the Setting: Minimum Support X/Y Distance. This setting seems to affect the support X/Y distance even though the description says otherwise. I'm honestly a bit confused by all the support distance settings (Support X/Y distance, support Z distance, support stair step height, support join distance) and do not understand the purpose they all have.
The way that this works (or should work) is as follows:
- If Support Distance Priority is set to "XY Overrides Z", then the X/Y distance between support and model should always be held, even if this causes the vertical distance to be larger than the Support Z Distance settings. The Support Z Distance is essentially just how far it must move the support downwards after computing the support with proper X/Y distance.
- If Support Distance Priority is set to "Z Overrides XY", then the Z distance between support gets precedence so it should always be correct. EXCEPT in parts with a fairly vertical slope, because then this would cause the X/Y distance to be very small. If the horizontal distance becomes very small, the Minimum Support X/Y distance kicks in and that gets precedence again so the vertical distance may still be larger than the Z distance.
- Support Stair Step Height is separate from all that. At the bottom of the support where the support rests on the model, the support is sort of stepped so that it doesn't rest on the model everywhere. This makes it easier to break off from the model, and improves slicing speed a bit too.
- The Support Join Distance is also separate from all that. If two pieces of support are very close together horizontally they get joined together. This prevents having lots of very thin pillars of support in favour of creating one bigger pillar which is stronger and prints faster too.
-
1
-
1
-
In the meanwhile we've also actually fixed this bug in the firmware. You can get a new hex file here: https://github.com/Ultimaker/cura-binary-data/tree/master/cura/resources/firmware
Or you could use the previous workaround: Put at least 512 bytes of comments in the end g-code of your printer.
Both should be in the Cura 3.3 release (the workaround is still in there for people who didn't update their firmware).
-
Indeed, I believe the Ultimaker 3 has it disabled for most materials (like PLA) but enabled for the more flexible materials like PP which ooze a lot during stand-by.
Possible to make dynamic gcode in cura?
in UltiMaker Cura
Posted · Edited by ghostkeeper
Simplified expression.
Yeah, that looks like it should work, actually. I am confuzzled!
I would expect a ZeroDivisonError here if the bed temperature is 0, because then you'll evaluate 45 * 0 / 0 = 0 / 0. I think the error is happening underwater and it is just displaying the old value then. Try this:
"' M190 S' + ('45' if material_bed_temperature else '0')"