RC3 Perimeters width can not be more than nozzer diametr, why?

[Arrow111]

Dear alexrj we had found out with our friends in new RC3 version not explainable situation when we are entering ( at config advanced window) perimeters width more or => to nozzle diameter the slicer starting constructing bridges at not expected places. It means we are not able correctly set up width of the extrusion as far as we are loosing object real dimensions. Actually based on our opinion all those problems coming up when you are inputting in to the algo calculation the nozzle diameter. "Kiss" one do not have place to input nozzle dia, so we think and recommend you and team to remove this input from your slicer calculation to bypass such further bugs or improve if it is possible the advanced window settings and synchronize them properly to all other input configuration data. If you remember, I had once already open such bug report about not needed bridges at RC2. I know it is not easy but please find time and energy to fix it to make this slice perfect as far as I don't like to use Kiss one...Is it possible? We are using RC3 at Win XP pro, sp3. Looking forward to hear from you soon. Thanks in advance for reply. Truly, Robert & friends.

[Arrow111]

Same you have here https://github.com/alexrj/Slic3r/issues/1779 To understand better explained problem see pic's in 4 frames. http://s23.postimg.org/pwzz9bysb/frame_1_ok.jpg http://s23.postimg.org/bru67ipqz/frame_2_not_ok.jpg http://s23.postimg.org/4r66eqnyz/frame_3_ok_only_after_24_layer_and_further.jpg http://s23.postimg.org/jym5z3ftn/frame_4_full_part_Y_bearing_stl_g_code.jpg

[Arrow111]

any news?

[alranel]

Greetings. I actually understood nothing of this report. You talk about perimeter extrusion width, then bridges. I'm confused. Then you're asking to remove the "nozzle diameter" setting. Did I get this correctly? If so, such request is legit, but it does not make any sense.

When you click on "New issue" here on GitHub you are invited to read the guidelines for reporting a bug. I suspect you didn't do it, since you attached none of the required information. I wonder why you skipped reading the guidelines :-(

[jkoljo]

I think that this is a duplicate of https://github.com/alexrj/Slic3r/issues/1672

[Arrow111]

This is not duplicated issue regarding "adding bridge where no bridge should" at 1672 issue.it is already in RC3 version colleagues but already with new "bug skin" as it was explained above.Dear alexrj it is exactly what I said - when we are entering ( at config advanced window) perimeters width more than nozzle diameter there in slicer then the slicer starting constructing bridges at not expected places as it was shown in attached pic links. Issue is very clear, just try to repeat it at your side with any your config and you will see it. Please take this model to test explained above bug:http://www.sendspace.com/file/0zsv2f. Are you able to try it simple as I had explained?If no I will close the issue without any solution and will live on bug free 0.9.8 version. Thank you. B.R. Robert

[avaradus]

Dear alexrj, this bug is generates wrong bridges in case when "Advanced - perimeter width" more or equally "Extruder 1 - Nozzle Diameter".

Pictures with bugging wrong bridging http://s23.postimg.org/bru67ipqz/frame_2_not_ok.jpg https://f.cloud.github.com/assets/641933/1842422/c7f2b6e2-74bb-11e3-99fc-720b922e3cf0.png

[jeder73]

He!! I think I do understand it wrong...

Till now I always thought, that, if you leave the extrusion widths at "zero", Slic3r uses some best-practices-patterns which are calculating with nozzle diameter and therefore depends from it. But if you change the extrusion widths (regardless if in percent, depends from layer height or in mm), the nozzle diameter is ignored und used nowhere. Of course these are assumptions.

In your example, you change the extrusion width from 0.39 to 0.41mm. These are absolute dimensions. In my opinion, in that case Slic3r ignores the nozzle diameter. Have you already tried, if you are using a width 0.41mm and you are getting errornous fillings, if this also occur, if you just change the nozzle diameter to 0.5 mm?

About my motivation: I am limited to the precompiled version of Slic3r because I use Repetier Host and did not get it anyway to run with the "perl slic3r.pl" call... That is why, I am yet searching for solutions for the wrong bridging problems, I get them very often, I can only help myself by rotating around the z-axis or using the "old" version (before RC1), but there are things, which just work better in RC2 and it generates more exactly shaped printouts (with RC2 I need less tolerance-delta at designing holes and shapes).

Perhaps it is solved in the actual master branch, but, like mentioned before, I cant use it.

Please could anybody confirm or disprove my assumptions about the dependency from nozzle diameter? It is just for understanding the arithmetics in Slic3r...

[Arrow111]

Dear jeder73, are you busy with RC3 development and bug fixings? Based on our experience only the 0.9.8. version do not have bugs & can be counted as stable version. At RC1 and RC2 versions the nozzle diameter were not participated in the algorithm of the slicer. Only in version RC3 it acquired affection. Why was it done like that , we do not understand yet..

[jeder73]

No, I am just a user of Slic3r (respectively over Repetier Host). I am investigating and taking assumptions und then investigating again...

And your Issue-Request "crushed" my "understandings" (which were derived from assumptions) about nozzle diameter and extrusion width dependencies.

And thats why I need some clear agreement or disprovement of my assumptions about the internal arithmetics in Slic3r...

[Arrow111]

As far as nozzle diameter already in the count of software algorithm then it means if you will change nozzle diameter from 0,4mm to 0.5mm then polymer extrusion volume also will be reduced accordingly . That is why we had suggested in this issue to remove this new algo from RC3 and even remove the field like Nozzle Diameter as it was done in Kiss slicer software.

[jeder73]

Dear Arrow111, I am using the slicer software to realize my ideas for 3D printing. So I think it is a great thing from alexrj to fullfill such a great project of realizing a new slicer.

I am a software developer, but I am working with C# and WinForms, so I can hardly read the Perl code. So I cannot really dig into the code and see some meaningful things. The only things I can say from my experience as developer, that users normally dont want to have changes in their world. But new features wont be possible without changes. I do not really know, why the nozzle diameter was inserted as an input parameter, like the way you mentioned.

But I can take some assumptions: Assumption #1: Perhaps, it is an attempt to maintain a "relaxed" flow to reduce die swell (die swell is good and bad: it is good to fill gaps, and bad, because the material looses density, normally at a given pressure, longer nozzles produce less die swell, but the nozzles in RepRaps are usually short and higher pressure produces more die swell).

Assumption #2: If you assume a flat ended nozzle nose, you have the possibility to "iron down" the filament. This can produce strong perimeter, but is limited due to the effective, flat, outer diameter of the nozzle. Perhaps the new algorithm may calculate the maximum width of the "iron down" capacity. The minimum diameter, which limits the "iron down" capacity is the inner nozzle diameter, with a ball nose nozzle you theoretically have exactly this "effective flat" downside.

Assumption #3: You have to distinguish between the width for a "relaxed extruded" and a "squished" material, because the theoretically idealized cross-section shape of the extrusion is different. I have found some code in flow.cpp, which looks like (I have very limited abilities to read Perl, as I mentioned above and I dont know where it is at least called). There is a threshold between the idealized extrusion shape (decided by the idealized cross-section area, in that context it stands for over the length normalized volume) and a squished shape. The "relaxed" shape is idealized as a rectange which has a half circle added at each end, the rectangle in the middle is as high as layer height and the width of the inner idealized rectangle is equal to the inner nozzle diameter, that could be the reason for the input parameter.

Finally I beg you, not to think, developer want to make things worse. Usually developer want to make things better. But new features may have unexpected degrees of freedom.

If I were the developer, who developed Slic3r, and you would tell me, just to "cut" out a newly introduced feature, because it doesnt work for you from beginning, first I would get sad. Then I would get angry.

Perhaps, we should pull a request to insert some switches, to disable or enable the new, nozzle-diameter-depended-extrusion-flow feature? Perhaps, we should pull a request to add a second parameter, to have different nozzle diameters? One for handling things about the idealized flow and one for calculating default widths? Perhaps a multiplier, similar to the linear extrusion factor in relation to the quadratic filament diameter? Perhaps, perhaps, perhaps. Or we can help to find out, why the perimeter extrusion width is not equal to the expected one?

But the goal should be to make things better and there is much more then the one way, just to make a thing good by cutting out bad things...

As a conclusion, I think, in this issue, you mix two problems:

1. Extrusion is not like you expected, because the nozzle diameter as a new input parameter changes the well-know behaviour former versions
2. There are some wrong fillings, like already "issued" in #1672 and #1779, which is already fixed in master and perhaps it would be backported to stable.

For me, the second issue is the issue, which interested me, but then I mentioned the thing with nozzle diameter and "hooked in"...

[Arrow111]

Dear jeder73, nobody said that this slicer is bad or what so ever, and nobody insists to remove window as mandatory solution. I am agree to statment that this is good done job from many programmers that is why we are still here to raise issues about the bugs. We and defiantly me still thinking that there is a bug in RC3 version which is mentioned above in this issue. I don’t know if you are not using advanced control of slicer but we are using this perfect future to control and make predictable dimensions of extruded polymer and this is not fillings like you said, this is phi sable bug for me and my friends. Your question - why the perimeter extrusion width is not equal to the expected one? is good one, also dont forget about adding bridge where no bridge should be when you are playing with advanced parameters in new RC3 version. I am also agree with your statement that you left - "But new features may have unexpected degrees of freedom." - so is this bug going to be fixed or not, we will see in near future. As a programmer - I am never touching good done algos to come to unexpected degrees of freedom. This is very good message I think.FYI - we are busy now with dynamic polymer laser welding at 3d printer. This software perfect to do such works too. We want to see it perfect and better than perfect.We still here to see any additional coments from alexrj and team.

[jeder73]

Dear Arrow111, With the word "wrong fillings" I did not mean unnecessary things, I did mean "wrong deposit of material as infill" because I think the "extrusion role" of the erroneous extrude is "infill" and not "bridge". I think the problem is a numerical "hole" in the idealized perimeter extrude and the infill is getting "out of its cage".

Mainly I agree with you, that dimensions of the print should be predictable or equal to the dimensions in the model file. Also it should be predictable how it is extruded to perform this.

Hoping also to hear from Alexrj and team about this...also hoping soon having a precompiled version with the infill bug corrected...

[jeder73]

@Arrow111: Which type of 3d printer do you work with? Is it a fusion deposit one where you use laser welding against delamination or something completely different?

[Arrow111]

Yes dear jeder73 it is FDM technology one. Our works against ABS objects delamination and hot bed 100% elimination. Thanks for right understanding in the previous message Sir. Truly, Robert

[jeder73]

@Arrow111: I think reduction of die swell will also reduce thermal distortion which is a main reason for a head bed. But...do you have a git hub repository where such "idea exchangement" is more suitable? Are you principally looking for such a discussion? I would be interested to hear more about your laser project (type of laser (Co2, GaAt...), position, angle, focussing, synchronous multi laser set up without lense, using of focussing mirrors and so on, additional things like fume filtering ...)

[Arrow111]

Dear jeder73 you wrote - "But...do you have a git hub repository where such "idea exchangement" is more suitable?" Until we will not gain the cost effective target result there are noting to show or share. Shortly there are 4 led lasers, N,S,W,E connected to the Ramps via special HW to drive output power of lasers dynamically. The light delivery optical system under development, based on FO MM wires, no mirrors.. etc. If we will get fume in the result then we can go home :) If you don’t have mass thermal distortion on the model then you dont need to have hot bed dear jeder73.So, such solution can save power which is more green tech. It has unlimited positives in the FDM technology development if we will get result.If you dont have mass thermal distortion spot on the model then you can easy print very big solid welded models with large printing speed window.etc. You know this is not correct place to discuss new solution as far as we forget about our important bug in the main tool of 3d printer. Please, let switch to the target issue and if you are able to raise your friends to participate in this issue then it will be perfect to hear what they are thinking about Filament Nozzel Diameter window in the slicer and why it should be used in did.In fact we still thinking that it is usesless and creating a mess in the slicer algo untill it is not synchronized to the advanced windows algo correctly. Dear alexrj, are you able to fix this bug? Please help .The avaradus had explain with snaps what we are monitoring. You have here discussed model which was shared as base one above & you never download it. http://www.sendspace.com/file/0zsv2f Shall we understand that you are not interested to see this bug fixed? :(

[Arrow111]

Dear alexrj, do you have any answer to this issue?

[alranel]

Dear @Arrow111, I'm very confused. Lots of talking, too many words, and NONE of the information you were supposed to supply.

When you click on "New issue" here on GitHub you are invited to read the guidelines for reporting a bug. You are required to provide a test file ALONG with exported configuration ALONG with other information listed in the guidelines. I told you this one month ago, but still nothing. I'm sorry I have to close this since it's going nowhere. If you want to help, please open a new one with just the required information. Debating whether the nozzle diameter option should or shouldn't be in Slic3r, without actually allowing anyone to reproduce your issues, is a bit silly.

Also, I have the feeling next version will already have the mentioned issues fixed so you might want to wait until it's released.

[Arrow111]

Dear alexrj, the last sentence telling me that this is bag in did , otherwise you will not motioned that this issue might be fixed. Thanks for your time and sorry for my English, We are Russians and Armenians here, and probably our English not so good to explain all in words. In any way thx for support, Hope this bug will be fixed soon or late. Mean time we are running 0.9.8 version of your good work result.

Truly, Robert and friends.

[jeder73]

@alexrj I think you have got the wrong image. The comments with "lots of talking, too many words" were from me and I am not part of the team of @Arrow111... and unfortunately I am "a son of much words". I think the main problems they have, is for the first, the issue #1779 and for the second, the circumstance, that since version 1.0.0 RC3 they are suffering from not being able to predict the flow or extrusion rate properly. They are using some experimental setups with lasers to add some extra energy to reduce the potential for delamination and distortion which at least is partly dependent of the flow.

[Arrow111]

Thank you dear jeder73 for right and sharp comment "they are suffering from not being able to predict the flow or extrusion rate properly" Truly, Robert and friends.