Ksanto
-
Posts
20 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by Ksanto
-
-
Now you get silly, I simply wanted to communicate how irrational your statement can seam. In gemany, when a comparison is bad, we say it is limping (The comparison is misleading). Once I saw someone in a Forum with this in his signature: Not everything that limps is a comparison.
I give you that this was not very precise, what I meant was "A bridge sitting on something below is called road. So directly below, not far below.
A bridge in the technical senses (3D printing is very technical, is it?) is known for not touching the thing it is bridging over (expect the occasional leg/piller)
1 hour ago, Slashee_the_Cow said:Or a walking path over a lake.
A bridge is not "on" a lake, it is over the lake.
1 hour ago, Slashee_the_Cow said:Or a railway overpass.
The bridge is not touching the rails, that would be a disaster.
1 hour ago, Slashee_the_Cow said:Or the thing a road sits on so you don't fall into the river below.
now you mixing things up, that is not a comparison anymore
1 hour ago, Slashee_the_Cow said:Or the (usually raised) area in a ship where all the main controls are. Or the top part of your nose.
That are both not Bridges in the technical sense.
1 hour ago, Slashee_the_Cow said:None of those change the fact that because Cura has to look to make bridges in any part of that area, it has to make bridges in every part of that area, and since a road is a generally very stable surface, it's definitely a good place to put a bridge on. Even though you don't need a bridge sitting on top of a road.
I was telling you all the time that wenn this is this what the developers decided to do I can work with it. I only wanted a confirmation because it seem very irrational compared to the definition of a bridges by Ultimaker by my understanding of it.
1 hour ago, Slashee_the_Cow said:It's working as intended. The fact that Cura is designed to make that whole skin area bridges, probably intended, so the line directions are consistent. The bridging algorithm: working as intended, because it's making bridges. It's far too simple an algorithm to account for situations like this.
It seems you assume that it is working as intended because it is making something the can be interpreted as bridges. Thats a circular argument. Im right, because Im right. "far too simple" ther is an explanaiton/evidence for your assumption/statement! This is something I would trust you to judge better. One could have a conversation on this basis.
Bye
-
Thank you for the additonal Information.
When I sad that I "did never see any difference in flow" I meant in Curas Flow Color Scheme. I do not have the Matrix sighte/eye/vision as you have. (A Yellow, A Brown and a Red Benchy) 😄
Suddenly it works, so as Slashee_the_Cow said :
On 10/5/2023 at 12:30 PM, Slashee_the_Cow said:Computer problem diagnostic step #2: Attempt to show someone else the problem, and it fixes itself so you look a bit silly to whoever you just tried to show it to.
I think I expect to see the change from the sides, but did not realise the the walls surrounding the rise bottom layer still not belonging to them and keep there values and so also there color indipendently.
Regards
Ksanto
-
1 hour ago, Slashee_the_Cow said:
Let's drop the personal stuff and limit ourselves to the matter at hand. There really only seems to be one bone of contention left there.
I really would like to agree with you, but you still do not understand my point and your second replay while I'm writing this lines is the biggest evidence for this. You simply do not get it, and this is a problem with the you you. The Personal you. I do not need an analysis of the Statu Quo, I need evidence the this behavior will persist for the long term.
1 hour ago, Slashee_the_Cow said:Okay, by my own admission I'm a little embarrassed for myself that this took me so long to realise, but if editing your model is feasible (even if you only have the STL, you can edit that, it's just a lot of hassle), but I think the long horizontal lines could be fixed (I'm defining "fixed" as replaced by short vertical ones which are a lot less likely to fail) by just adding a couple of thin inner walls on that layer, which will break it into three disparate areas, and the long horizontal span that needs to be bridged would be their its own area, which would hopefully be bridged with vertical lines:
As I already stated before:
2 hours ago, Ksanto said:If this is how it's intended to work in the long term I can work with that but I would be mad if I adapt to it and in the next version it is working totally different.
So, yes, this possibility was there all along, and yes, I did already consider something like that. But that is and never was the Point of the Question.
2 hours ago, Ksanto said:As I have already stated, I did not questioning how it is doing what it does in the first place. Only did I react to your assumptions/statements and gave my own assumptions.
I did repeat myself many times in many ways during our ongoing conversation, but this is the clearest example of it.
1 hour ago, Slashee_the_Cow said:Bridges are considered skin when they're in a skin section (you'll see in the layer view with line type, they're the same yellow as the rest of the skin), and if a skin section has bridges, the whole section is considered bridges. Your example shows both the long horizontal bridges of the large section and the vertical bridges of the small section printing next to the infill, so I'm sorry if I'm misunderstanding you, but I don't see the point of the second half of that statement.
This is informative, thank you, but it doesn't matter in the context of the question. That you do not understand nor value the secont halfe of the statmen is a core problem with us. Even if it is lacking *two small* words I did miss due to fatigue, repeating myself like a broken record, over and over again:
2 hours ago, Ksanto said:As established just a suggesting assumption opposing your Statement. It does not help me to understand why it does this more than understanding what it does if I can not assume that it is intended *to do* what it is doing. What would help me is to know that this is intended although it seems irrational to ME.
1 hour ago, Slashee_the_Cow said:You're not accounting for the infill breaking up the large horizontal area. That gives us a lot of short horizontal lines (c)
yes I do, I did state specifically "... fits the definition of shortest path over unsupported area best". In my understanding of the defineiton of bridges, the "...the infill breaking up the large horizontal area" shuld never be toched in this manner by bridges as they never bridge any bridging area. To make it clear, again, yes, the algorythem ist filling the whole area uniformly, but this does not mean that this is making fully sense, nor that shis is intenden as is. But I also not in a position to demand change, I will happily adapt if it is confirmed to be as intended.
1 hour ago, Slashee_the_Cow said:And since it treats the whole skin area as bridges, those short horizontal lengths are by far the best bridges (even if they're not areas that need to be bridged); they have something below them and are attached to a strong wall on one side and a supported wall (the one around the infill) on the other. Since a skin area will always have all lines running in the same direction (assuming you're using the lines pattern, although I don't know if bridges will always use the line pattern regardless of the top/bottom pattern setting, it's not a situation I've ever had to deal with) it uses the worst case for a few of the bridged lines because it's the same direction as the best case for so many of the other lines (which as I said, don't need to be bridges, but are considered to be).
A bridge with something below is called road. Yes, I only know of one bridging pattern (at the moment). Yes that's the status quo, and I could deal with that, if I can relay on it not changing in the long terme.
If it is not a problem with reading/writing comprehension (from your side/my side) I think what we have her is a "If the only tool you have is a hammer, you tend to see every problem as a nail" Situation. Your analytical way of problem solving does not allow you to say that you can not help in this situation but you also can also not refrain from trying. That seems to be what fueled my initial perception of you as a Fanatic in the first place.
Regards
Ksanto
-
7 hours ago, Slashee_the_Cow said:
I wasn't saying which variables were unknown. I was saying what variables exist and can be a factor in a situation like this. Some models would not exhibit this behaviour at all purely because of how the bridging algorithm works on their design, so I couldn't just pick a random model to test with.
But surely while having roughly the same proportions. Having a long bridging edge where support is needed otherwise while having two smaller areas divided by infill. But it was never the point to validate the behavior in special but in general, if the bridges are intended to extend (in whatever case) over the whole layer in this manner. Nether you nor I can tell, because we are not involved in the development. The examples in the "Introducing The Experimental Bridging Settings" thread suggest something different.
7 hours ago, Slashee_the_Cow said:As for point four, you didn't say what quality preset you were using, nor if you were using a profile for a particular material (which shouldn't affect something like this, at least in the slicing, but many of the slicing settings interact in ways you wouldn't see coming).
On 10/5/2023 at 10:25 AM, Ksanto said:bump up Bridge Skin Support Threshold to 95% (used the provided Normal Profile for Anycubic i3 Mega for my exampl)
You have a point in me not communicating the Material preset, but it does merely change the general temperatures.
7 hours ago, Slashee_the_Cow said:Is this how you always treat people trying to help you?
Only people who getting cocky while missing the point. I Specifically made clean through my writing style with the slashed "wrong" and the following correction to "not right" (totally different statements in this case) that there can be different viewpoints on the same topic and that I accept your point of view. Hence your point of view is that this could be a isolated case, but my viewpoint is that it seems strange this is even intended in general. That's why I made clear before I listed the points that the following would be pointless. I appreciate your efforts, but you should focus your energy to other things then shooting around the target.
7 hours ago, Slashee_the_Cow said:In case that last bit didn't tip you off, I was explicitly stating that I was wrong and that you could hold at least that part over me. I'm pretty sure
snowfalkessnowflakes never admit they were wrong, and nobody has the heart to tell them if they are. I have no idea what you think I'm a"Fanboy"fangirl of though, unless it's "blame 5.4", but you're not the first person to tell me that. I don't know if I can block you but I am sort of offended you'd think I'd consider it, I'm not that sort of person, although I can't expect you to know that, so no offence personally aimed at you.It did not. Maybe I missed the point because I'm not a native english speaker, but your text came across as an accusation followed by an lecture after the cocky and point missing "Need I go on?". Never did I expect to see this sentence out of my perspective, but yours.
It just seems like you're obsessively trying to defend/explain decisions/processes that I had not questioned at all at this point. An overreaction that is usually attributed to fanboys. The algorithm is obviously working like this now/at the moment, but is this behavior intended? But in the given context I will refrain to use the term Fanboy/girl and use the more neutral term Fanatic (not in the context of being a fan to sth/sb anymore but in the general therm as fan comes from fanatic), if at all. After all, I'm kind of a fanatic myself in that I want to make it clear to you that you are fighting a battle that has no enemy. Furthermore I apologize for my assumption that you were a bubble-filtering snowflake. That was based on the assumption that you were also a Fanboy/girl in combination with the misunderstanding of the quotet sentence.
7 hours ago, Slashee_the_Cow said:And you expect me to go through the print profile figuring out the flow rate for each kind of section why?
No I expect nothing from you, beside maybe refer me to examples or statements that were given/made anywhere else and to accept that you can not do anything in this case as you personally cannot answer the question if this behavior is intended. Everything you have achieved is to lay out why it is bridging like it is, but not if this is intended.
7 hours ago, Slashee_the_Cow said:The bridges have to connect to something at each end, and it picks whichever part is strongest, which is usually because it either has something underneath or is considered to be a strong itself (like walls). What it connects to at each end is referred to as its support, like a real bridge. It has nothing to do with supports printed in the model to hold parts above the build plate (or other parts of the model), other than the name.
As I have already stated, I did not questioning how it is doing what it does in the first place. Only did I react to your assumptions/statements and gave my own assumptions. If this is how it's intended to work in the long term I can work with that but I would be mad if I adapt to it and in the next version it is working totally different.
7 hours ago, Slashee_the_Cow said:Also, "vertically" as I phrase it? Technically inaccurate, but it's easier than saying "depthwise" or "along the Y axis", also especially because if you're looking at a single slice (like a layer) from a 2D perspective, the Y axis is vertical. Horizontal is objectively correct in my usage here because I am using it to refer to lines that run parallel to the X axis.
This was not a criticism, I only wanted to clarify that I adopt your wording as a common language within this thread.
7 hours ago, Slashee_the_Cow said:The thing here is that Cura prints whole skin areas (generally with the edges defined by other types of feature, like walls or infill) as one, with the same settings, so that it looks consistent because it's expected to be seen. So instead of just bridging this area (highlighted in pink):
But Bridges are not Skin and Cura it is capable of for example printing Infill right next to Skin. As established just a suggesting assumption opposing your Statement. It does not help me to understand why it does this more than understanding what it does if I can not assume that it is intended what it is doing. What would help me is to know that this is intended although it seems irrational to ME.
7 hours ago, Slashee_the_Cow said:It's giving the same treatment to this area, because it's the biggest polygon that can be made without hitting another feature type:
And the vast majority of that area is best served by horizontal lines, so the bridge follows suit.
But (a) is still shorter than (b) and following along (a) fits the definition of shortest path over unsupported area best. Still just a suggesting assumption opposing your Statement. yada yada yada
7 hours ago, Slashee_the_Cow said:The other area:
If it used horizontal lines here, then a more significant proportion of it would be bridges with nothing underneath them, so it determines that vertical lines better serve the purpose.
This area was never up for debate. It is in any way the shortest path (b) over the unsupported area. yada yada yada
7 hours ago, Slashee_the_Cow said:My intention was to provide all the evidence and reasoning possible behind why the bridging behaviour acts like it does.
Is it working as intended? If I'm correct about the logic I've discerned behind its behaviour, yes.
I don't think any of the Cura developers actively read the forums (you'd need to wait for @gr5 to pop in and confirm that) so if you want an answer straight from the proverbial horse's mouth, you would need to go to the Github repo and ask there, but I know they're generally pretty busy, some being volunteers (it is open source, after all) so I'm not sure how quickly you'd get a response.
Even while I think that you are correctly presented its superficial workings this does not preempt any possible that this is not a unintended outcome. Your attempts at explanations honor you, but unfortunately they don't help me to decide whether I put up with it or whether I get more worked up over it (it's escalated quite a bit now) than here / what was originally planned.
7 hours ago, Slashee_the_Cow said:I'm not sure if the wink emoticon means you're joking or not, but that is not the way to endear yourself to software developers to get an official answer to your question. This stuff is a lot harder than most people think, especially a program with so many proverbial moving parts (different situations it has to be able to adapt for) as a slicer.
No, I'm not one of the Cura developers, but I am a programmer, and I have dived through the Cura source code a little bit, and trust me when I say to dive all the way down would require the submarine James Cameron used to go through the Mariana Trench, which is why lots of people work on different sections, more than me having a curious peek in.
That was my way of trying to tell you that it could be quite offending in it selfe to call the bridging algorithm stupid. You have to read and Understand (quote! to) the sentence together with the sentences that where following to keep/understand its meaning.Im some kind of a developer myself, more on the mechanic/electric side but you need some code to wake the ghost in the machine. So I would be offended by someone labeling my algorithm stupid (beside myself) if is does what it is intended to do. I do not know how to make myself more clear about my intentions/asking.
16 hours ago, Ksanto said:this is the reason I phraised my question as is. I'm not in the position to criticise decision regarding code/development.
Regards
Ksanto
-
Will look into that tomorrow, I did never see any difference in flow over support when bumping up the flow only for bottom layers. Thank you for confirmation.
Regards
Ksanto
-
I would like to chime in on this, for ages I've been looking for a way or explanation why Cura doesn't interpret the layers above the support / support interface (after the z gap) as bottom layers, since I like to set the flow on the layer(s) directly (after the z gap) over the support/support interface.
Regards
Ksanto
-
Hi Justin,
as I don't have an ultimaker nor an other printer with core xy, my experience are not directly applicable, but what I would suggest, under the assumption you prefer quality over reliability (likelihood of failing the print), I would suggest to print it with the blade up. As I stated, I have no experience with standard Ultimaker Profiles, but I have my profile tuned in enough that I would trust it to hold the hilt till the support graps the cross-guard. From there on it should be stable enough and the potential ugly area would be minimised to the tip of the pommel and the underside/hand side of the cross-guard.
Alternatively, it would be more reliable to print parts like this lying flat or raised and or diagonally if they are to long to fit the build plate in XY direction. With good support there should be an acceptable loss of quality to only one side of the part.
PS: Cura warned me that the part has errors in its structure, if Cura is not able to fix them sufficiently this could be the bigger problem.
Regards
Ksanto
-
2 hours ago, Slashee_the_Cow said:
Variables:
- Version of Cura used
- Model
- Printer
- Bridge settings
- All the other slicing settings
- Need I go on?
Not that it does have any meaning, as it was and is a general question of it being working as intended:
NO unknown Variables:
- I specified the version and so the question was specifically about 5.4.0
- the question was generally on the intention of the behavior, I do want to print other things, not only this model for the rest of my life
- I did state the type of my printer (Anycubic i3 Mega)
- I did state that I choose the standard normal profile for my printer and have bumped up the Bridge Skin Support Threshold to 95%
- see above
-
no, you should consider being
wrongnot right
2 hours ago, Slashee_the_Cow said:Anyway, the problem isn't anything wrong with 5.4. Take that as an "I told you so" if you want.
I cant wait but I never said it was a bug or anything "wrong with 5.4.". If I had done this, I would have said so. However, I deliberately asked if it behaved as intended before filing a bug report, before claiming that it was a bug. From this point on, I consider you a Fanboy. Block me if you want, my special snowfalke.
2 hours ago, Slashee_the_Cow said:The problem is that parts of layer 13 don't sit upon anything, it's the first layer that produces skin for some areas.
Isn't this the purpose of bridges. Bridging between layers/areas over thin air? aka unsupported?
2 hours ago, Slashee_the_Cow said:These screenshots are set with Colour Scheme set to Line Type. Especially when the problem is with certain types of lines, it's much more useful than flow.
fair enough, technically I agree. but I found that the contrast between lines and air did not come out very good with yellow to grey and the distinction between line types was preserved.
2 hours ago, Slashee_the_Cow said:It's starting with the infill and then doing the walls because there's something there that it can attach to. It then completes that lap:
So far I would agree.
2 hours ago, Slashee_the_Cow said:Then it starts doing some horizontal work:
exactly this is my problem
2 hours ago, Slashee_the_Cow said:So why does it do the long horizontal lines? It's looking for the shortest route between two best supported areas. If we look at the layer below, there is absolutely no support in that gap:
Again: no support=bridging=works as intended. However: The shortest route between two best supported areas would still be all "vertically" as you phrase it later.
2 hours ago, Slashee_the_Cow said:Where it does the long horizontal lines, the first line of skin that was printed is the only support that exists along that gap. It hasn't printed the skin in the shorter horizontal areas because it's bridging first so that the regular skin can match. So why not do the short lines between the walls and the infill first? Because then there isn't a valid path from one wall to the other:
If it did the short lines first, it would be a bunch of vertical lines in between a bunch of horizontal lines, and it works to make all the skin in an area the same direction. So why doesn't it do the whole thing in vertical lines? Because for the majority of the area, the best supported part is between the side walls and the infill, because there's already skin below it, and none of them have to cross a gap.
Very informative, even if I do not understand what it has to do with support (are we still talking about bridges? - see definition above) nor what matching the skin means. Why would there not be a valid path from one side to the other when the "rectangular areas" between the infill and the wall would be filled first? Then there wouldn't be a valid path of the second bridging area also? What are your sources?
I of course would expect it to make them all the same direction and would say it would be nonsense if it tried to attach vertical bridges to horizontal bridges. So fare, now for the all vertical lines solution: That would be the expected outcome under the given circumstances. What with the nonsense about the Support? See definition of bridging, it should not have any difference if there is something ot nothing underneath. What are your sources?
3 hours ago, Slashee_the_Cow said:So then it does the extension. The first skin it draws is against the infill, then goes around anticlockwise:
Then it does the lines:
So why is it doing them along that vertical axis instead of the shorter, horizontal lines? The answer again lies in the lower layer:
There's no support in that gap. It does all the lines in each area in the same direction (duh). But wait, earlier it was doing horizontal lines across a big gap so that all the lines didn't have to cross a little gap? Yeah, but remember, it's looking for lines between the best supported areas. If we look at it before it starts filling in:
The gap area has no support whereas it considers the already existing geometry (the infill) as a supported area. So by drawing the lines vertically, then it's doing all of the lines so that they start and end at the best support, rather than doing some lines where there's no support. There's not enough pre-existing area where horizontal lines are the obvious choice to outweigh the few lines that aren't supported. The bigger area had a lot of area where horizontal lines were the obvious choice because they didn't have to cross gaps.
Works as expected, still don't understand why supported area should have any influence. What are your sources?
4 hours ago, Slashee_the_Cow said:Can this behaviour be changed? Not sure. You could try playing with Top / Bottom > Top/Bottom Line Directions (it's a series of angles at which the lines are drawn) to be all verticals/horizontals if you want, but you're still going to have this mismatched bit. So if they're diagonal by default, why doesn't it just bridge diagonally?, some might ask. Answer: the bridging is stupid. It first looks for adjacent (which in this context means parallel) skin to bridge to.
Changing Top/Bottom Line Directions is reported to do nothing in threads back as far as 2018. Beside I do like my Top/Bottom Line Directions for the other layers as is. The wall in vertical direction are also adjacent/parallel!
One correction: the bridging is only as stupid as it's developer. 😉 In other words, I do not judge, this is the reason I phraised my question as is. I'm not in the position to criticise decision regarding code/development.
3 hours ago, Slashee_the_Cow said:(And yes, I did need your project file to figure this out, because then I could actually see the order things were being printed, the line types, and the layers above and below)
Everything for nothing as nothing of this answers my core question:
10 hours ago, Ksanto said:is this the intended behavior?
This question only can be or could have been direcly answered by somebody whith autorety by Ultimaker (Adminestrator for example) or somebody involved with development. My expectation was finding help at finding the answers somewhere by an official source or get answered by an official source.
We only achieved to debate whether it is/would be better one way or the other. Nevertheless, thank you for your efforts.
So why did I even bother to reply to you anymore? Well, You certainly made an effort and I even learned one thing or another (perspectives). But boy, you should find another enemy for yourself and accept the you can sometimes not fulfill every demand in the relative position you find yourself in.
Sleep well
Ksanto
-
It is indeed simple yes or no answer with no variables. But not for us both. Etherther developers intendet it to be the hole layer or not. But only they can tell. A third option for people not involved, like us both, is to say that one did not heard of anyone saying neither one thing nor the other, as I did to my self after failing to find anything regarding this behavior.
I did deliberately not provide the project file because I could show that the problem can be recreated with on-board resources. It would be less hassle for you to add the printer and/or use the integrated profile to make sure there it is not a problem with my installation, wich could be translate to the project file, than me going through the process of downloading the installer file (which is a long way around as our company has restricted teh download oft executables) and installing it. But either way, here you have.
Regards
Ksanto
-
Not the parallel installtion is the hassle, but the insall <old version>, not working -> next, insall <old version>, not working -> next ...
there is a clear answer, is this intended or not. I'm not some kind of software archaeologist whos mission is to find the last version on which it works as he expected. It could also be the new way it works NOW.
Regards
Ksanto
-
Appreciate your efforts. I already tinkered with Mesh fixing resolution because of the protruding line bug. Also consideres to install a older versions but didnt want to go down the rabit hole to install/test multible verions (stopped with the behavior of hoarding old cura versions, somewhere on the way between 3 and 4, because it confuses preprocessing CAD programs alot).
-
Hey Folks,
befor opening a Report on GitHub (Cura 5.4.0) I wanted to ask if anybody can tell me if this is the intended behavior:
I try to force Cura to use bridging on a specific Part and have to bump up Bridge Skin Support Threshold to 95% (used the provided Normal Profile for Anycubic i3 Mega for my exampl) so bending of the Part would be easier / more stable. Thing is, the bridging direction is not uniform and I think I alredy understood why, see the picture:
Because the bridging is happening inside the top Layer, the shortest distance between two walls is inside the top layers, so the direction follows a sub optimal Path for the intended bridging area. My understanding of bringing always was that bridging would happen only between two outer walls.
So, is this the intended behavior?
Regards
Ksanto
-
Tested and Seems to be the solution, man I was blind, thanks.
-
Hi Waldwurm,
ich habe den selben Drucker und keine vergleichbaren Probleme. Benutzt du das unmodifiziertze Normal Profiel? Hast du nach dem Teil mit Cura 5.4 nochmal das mit Cura 5.0 (neu gesliced) gedruck (ich gehe davon aus dass zwischen den gezeigten Drucken ein gewisse Zeit vergangen ist)?
Grüße
Ksanto
-
Hello Together,
is was tuning in some other place in my Profile within Flow view (Cura 5.4.0) , when I noticed that the two first layer had a lighter color, hence less absolute flow, despite having initial layer flow already on 125%.
I then changed to the included Normal profile for my Printer (Anycubic i3 Mega) and it was the same. In the pictures you can see the difference between the shown flow of layer 2 and layer 3, dispide there is no divination in the setting from the standard 100%?
Can anybody tell me why the Flow (in case of the standard profile, the initial layer has also a deviating line width, which is not the case in my own profile, which I did not published deliberately as because this seemingly bug is also present with the profile shipped with cura) of the first two layers are deviating?
Regards
Ksanto -
Thank you for your help and clarification of the problem, I will check it and change the topic name appropriately.
At least now it is documented what setting in preset Profiles can prevent the compensation from working. Thanks a lot.
Regards
Ksanto
-
1
-
-
I think that is not the case hier, I think you misunderstood the Problem, beside this it is a clean cura 4.13.1 install. Print profile for both cases is normal. But for the sake of pleasing you, her are the 4 variants.
Thank you for your efforts.
Regards
Ksanto
Anycubic Chiron - Normal - Owl-Filament Black.3mf Anycubic Chiron - Normal - Test Dimater Max.3mf Ultimaker S5 - Normal - Owl-Filament Black.3mf Ultimaker S5 - Normal - Test Dimater Max.3mf
-
Hello Folks,
I was in the process of catalogue all my Filaments, when I got curious what the difference of extruded length between the two with the greatest variation of Diameter would be. I was left stunned, the length did not change, even though the diameter significantly differ.
Then I created a material with the thickest diameter that could work with a 1.75mm Printer (which is 2.49mm, to still show up) and got the same length on both Materials as before after slicing. After that I searched for different combos of the words Material, Diameter, Thickness, bug etc. but only found old resolved problems from 2-3 years ago. Then I suddenly noticed that it was never mentioned which manufacturers Machine the problem was with. I then tried it with a quickly added Ultimaker machine and worla, the setting suddenly applied.
Can anybody confirm this behaviour is as intended and also maybe forward me to where this is described?
Regards
Ksanto
-
Beforehand, I only try to understand how/why Cura is working/acting (like this). As you can read in the following, there already is a solution (more of a workaround) for the core Problem that it would not finish/print correctly.
I recently recived a Palette 2 and configurated cura to their specifications (later more on this), cliced, convertet the gcode with there Programm called Chroma and attempted to print it like this.
Everythin seemed fine till the last switch of the Color. The Filament transporting stepper stopped while the printhead was still moving.
I checked everything I have done so far twice (software, hardwar and executional wise), redone the whole procedure, outcome was identical. So to checked if the Problem was the converter (Chroma) and attempted to print it whitout converting, in a single color with the same gcode to see if the same was happening. The outcome was still that at the point whre the last colorchange wuld acure (abut 94% in the print) the filament transport stopped as before.Then I came back to read the Problems section of the article on configuring cura. There they mentioned hat:
QuoteYou can also check that the last color to print is assigned to the first Extruder, ...
So I tryes that and the outcome was flawless. The Print was running to its end without any problems.
So can anyone explan to me why Cura stops the filament tranport wehn the last activ extruder is any other than the first, even if it before had no probmlems with filemt tranport being the same for all extruders?
Keychain evident order.gcode Keychain first extruder for last color.gcode
manual shaft support
in UltiMaker Cura
Posted
If you mean together with normal support, I would not know how (could not find an instance where anybody got it working) but you could modify a support blocker to only add support on a small area with tree support enabled.