Replies: 58 comments 288 replies
-
|
love it ! my first test part :
|
Beta Was this translation helpful? Give feedback.
-
|
The weird stringing is also something that we've noticed. We have a few ideas what is causing it (but we didn't have enough time to fix it before the Alpha) |
Beta Was this translation helpful? Give feedback.
-
|
Outer Wall Wipe Distance |
Beta Was this translation helpful? Give feedback.
-
|
Ok confirmation, Outer Wall Wipe Distance should not be used with this Alpha. |
Beta Was this translation helpful? Give feedback.
-
|
It's very helpful, thank you. Ultimaker's QA had been seeing issues with stringing as well but we hadn't pinpointed yet what was causing it. I don't know if this is the same issue but it is a likely candidate in any case. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This was fixed here: Ultimaker/CuraEngine#1419 |
Beta Was this translation helpful? Give feedback.
-
|
Builds for all OSs' including Mac. are now live! (And without the strange filenames that included an off-sequence version nr. even!) Just a heads up: Seems we forgot to include 'Fuzzy Skin might not work properly' in the changelog in the release ('What's New') Consider it a 'known' issue. @5axes |
Beta Was this translation helpful? Give feedback.
-
|
Instead of porting the fuzzifying algorithm to the new type of toolpaths, you could also just use clipper for the outer wall and use the original algorithms for fuzzy skin. It's not like a dense filling is important for fuzzy skin anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Quick heads' up: if you check Enable Bridge Settings in Experimental, it will fill the slicing progress bar then blank it and just sit there, never finishing. I left it a good hour or so and no change. Disabling that setting fixed it right up. Doesn't seem to matter what the actual bridge settings are - just that they're enabled. Discovered with my custom profile, confirmed with unmodified "Custom FFF printer" profile. |
Beta Was this translation helpful? Give feedback.
-
|
I'm still getting used to 'Discussions'. For anyone else commenting on this issue, please see the new thread I started just below (didn't see the 'reply' fields at first). |
Beta Was this translation helpful? Give feedback.
-
|
All good, chief. To keep it collated, it would appear that enabling the Experimental "Enable Bridge Settings" in tandem with at least one (1) "Top Surface Skin Layer" will cause anything that actually has a top surface skin to fail to slice. It will run through the slicing progress bar once, then empty it and sit there. A "ClipperLib::clipperException" appears in the log. The actual presence of a bridge is unnecessary. The top surface seems to be the deciding factor, so rotation and/or scaling can be used to negate or introduce the issue on certain models. |
Beta Was this translation helpful? Give feedback.
-
|
@Asterchades what do the logs say? Also, is this with a specific model or with all? (If the first, could you please attach the project?) |
Beta Was this translation helpful? Give feedback.
-
|
I'll get back to you in a few minutes on that one. I tried it on a different model and it worked, and now I'm having trouble getting the FFF profile to produce the issue again. My custom profile is still giving grief with bridging enabled but unless I can figure out what other setting/s are involved it's not for certain I didn't cause it myself. I couldn't get much out of the logs myself, but just in case it helps I'll post the one with my profile. Note that at this point it's sitting there trying to slice with an empty bar. |
Beta Was this translation helpful? Give feedback.
-
|
Found it! Project file: Log: Occurs on that particular model when using Bridge Settings and at least one (1) Top Surface Skin Layer. I believe the included project is set to fail. *ed1: Testing other more geometric models (various brackets and enclosures) shows the same fault, however more decorative prints (miniatures and the like) don't. Tipping such models by 15° so they no longer have a proper top surface seems to alleviate the issue, as does disabling one of the two previously mentioned settings. *ed2: It appears any model which fails to slice can be "fixed" with such a rotation (roll or pitch - yaw does nothing) unless this introduces a flat top surface. You can also adjust the size such that the yellow "Line Type" (default colour) is no longer present on a top layer and it will also work, though it will still occur even if a Top Surface isn't on the uppermost layer. The presence of any actual bridges which satisfy the experimental setting is also unnecessary. |
Beta Was this translation helpful? Give feedback.
-
|
At least for my simple bridge test it seems to work fine still. Yours seems to get a ClipperException though, with an exception saying that a coordinate is out of range. I can reproduce that. It's really weird that bridging would produce that, but apparently it does. |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't even seem to be related to actual bridging. I fired up a calibration cube and could produce the same issue, with the same slight tipping letting it go through. And there's no bridging at all in one of those - it's just the act of having the setting enabled. |
Beta Was this translation helpful? Give feedback.
-
|
I found the same thing @Asterchades did in the Mac Version. But reading all of this, he already found out a lot more than I. |
Beta Was this translation helpful? Give feedback.
-
|
Separate post for a separate issue, just to aid tracking. Support Interfaces are not working correctly. Specifically, they're not generating. There is no colour change on the preview and no alteration to the geometry generated (verified by using an external GCode viewer). However, the offset is being taken into consideration and the supports themselves will stop at the correct heights - just there's nothing above or below them depending upon whether they're a roof or floor. The Support Interface Floor will also cause the same failure-to-slice issue as Top Skin/Bridge settings when used in tandem with Support Interface Horizontal Expansion. This is inconsistent, however, and on the surface appears to be related to models where this expansion will cause it to protrude into the model itself. |
Beta Was this translation helpful? Give feedback.
-
This helps a lot. Thank you. Indeed I could reproduce your bug immediately with otherwise default settings of my UM3 printer. It looks like the concentric support interface is not being printed. Lines, grid, zigzag and triangles work fine. I'd personally tested support interfaces around a month ago (when we reworked the way that support/infill/skin outlines are being drawn) but apparently it broke afterwards. I wonder why we didn't find this ourselves since we did test print with PVA on Ultimaker printers which gets a concentric support interface by default. |
Beta Was this translation helpful? Give feedback.
-
|
Neat find on the pattern issue. Wouldn't have thought to check that, even though I probably should have just for completeness. I'm still trying to isolate the second part. It's proving harder to track down, but the logs are throwing a LOT of warnings. Specifically "The edge we're about to connect is already connected!" followed by a whole heap of "Encountered an edge going towards bead count 0, but which is not at the boundary yet. Distance: xx" with the "xx" changing. By "whole heap" I mean over two screens. *ed: OK, I cannot isolate it, in so much as I have found a way to stop my profile from hanging, and make the Custom FFF profile hang, but the two situations aren't an exact match (even if they share some elements). So I'll include a copy of the profile I get the issue with, the model I get the issue with, the log when the issue occurs, and the steps to stop/start it having the issue: Head scratching time: If you take that profile and that model, and use a Support Floor Thickness of anywhere from 0.3mm to 0.499mm (inclusive) than it will fail to slice. Unless, of course, you set the Support Roof Thickness to 0.9mm or greater, at which point those become perfectly acceptable values and it will slice as normal. Setting the Custom FFF printer profile to have 0.4mm and 0.8mm respectively, however, works just fine. Unless, of course, you also set the Initial Layer Height to 0.2mm (default 0.3mm). But changing my custom profile from 0.2mm up to 0.3mm doesn't make it work. So now my head hurts almost as much as it did after watching Tenet. |
Beta Was this translation helpful? Give feedback.
-
This is unrelated to the support interface. But we've seen it too. Specifically somewhere in the last week these cases suddenly popped up much more. It was raised by one of the developers yesterday and we're investigating. The warning usually means that one of the transitions is not completed, meaning you'll have a gap somewhere. It's not a problem for printing really, unless it occurs regularly on the same spot in the print. |
Beta Was this translation helpful? Give feedback.
-
@Ghostkeeper could it be that we didn't notice this because it was overshadowed by the problems with the gradual infill support failures or do they both share the concentric interface? |
Beta Was this translation helpful? Give feedback.
-
|
If I wanted to completely fill any large model with variable wall line widths (call it a variable concentric infill) can I just set my |
Beta Was this translation helpful? Give feedback.
-
|
Yes Infill 0% and Wall lines count = 999 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I suppose in this case it would be advantageous to increase wall print speed to equal infill speed. Should cut down on print time I hope! |
Beta Was this translation helpful? Give feedback.
-
|
Maybe this is a better way to achieve 100% infill density than Cura's current routine of setting the skin thickness to 9999? Would be good to test that. Interesting idea. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! It certainly seems to fill the tight spaces like advertised! I don't know the trick about skin thickness though. Can you elaborate? |
Beta Was this translation helpful? Give feedback.
-
|
Normally, a printed item consists of walls+skin+infill, broadly speaking. In Cura, if you set the infill density to 100%, and inspect layer view, you'll find that it didn't actually create infill. That's because it then automatically sets the Bottom Thickness to 9999mm. This eliminates a border between skin and infill where the lines don't match up. You only have walls+skin then. In the end this results in better print quality and fewer air pockets. I'm wondering if we should instead set the wall thickness to 9999mm to also eliminate the border between skin and walls. The entire print is just walls then. Previously this resulted in wall overlaps which were not ideal, and gaps in the walls. But now that may give a better result than using walls+skin. But I'm only theorising here and this can only be confirmed with empirical testing. |
Beta Was this translation helpful? Give feedback.
-
|
One small issue I noticed. I have been doing a lot of testing of infill type strengths at 100%. Concentric vs. zigzag vs. lines etc. I print these without walls When I go to run these same settings in the Arachne release I actually don't get any gcode generated. I have all the files zipped (cura profile, STL, resulting gcode), but Github doesn't like that it's larger than 10MB. If you want it and there's another way to get it to you let me know. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! The issue reproduces here. It must've been an oversight. We'll take a look at it. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, we replied at the same time. But I'm indeed getting no output at all: |
Beta Was this translation helpful? Give feedback.
-
|
Well, I'm running from source on Win64, I know you use Linux, are you running from the AppImage? |
Beta Was this translation helpful? Give feedback.
-
|
FWIW I am running from the pre-built Mac DMG. |
Beta Was this translation helpful? Give feedback.
-
|
Fixed here: Ultimaker/CuraEngine@ccad27a |
Beta Was this translation helpful? Give feedback.
-
|
I just happened to print a minifigure for a friend, but the gcode seems to be not simplified enough. UM S5, PLA, 0.4mm nozzle, visual quality @ 0.06, tree support Cura 4.8: Cura Arachne alpha: |
Beta Was this translation helpful? Give feedback.
-
|
There's a LOT of potential for this build when it comes to miniatures. It's definitely not there, though. While I'm not seeing what BagelOrb is seeing, there's a definite loss of quality as compared to 4.8 - even after taking a few steps to try and accommodate. Specifically I've tried setting the Outer Wall Wipe Distance to 0 and the Visible Line Strategy to Center Deviation (I feel the highest quality likely requires the most consistency in the outer wall, but have nothing to back that up with). In terms of results, I printed off the following (4.8 left, Arachne right): Now it's nothing if not obvious that even the left one isn't the greatest print. The overhangs are a little off 'cause I used Tree Supports, and the general print quality is a little lousy due to moisture contamination of the filament. I also couldn't find my macro camera so that's just a phone shot (zoomed) which doesn't help. BUT! All that detracting ignored briefly... There is more detail picked out on the Arachne print. This is particularly noticeable on the gun sight and scope, but also visible on the "tubes" on the helmet. However, the Arachne skin is "rippled" vertically, which you can also see on the sides of the gun (especially the barrel) and the pauldrons from the side. This could be filament, but I've printed this same model with the Arachne build a couple times and the placement is consistent, as well as being fairly evenly spaced vertically so I suspect the filament is just not helping rather than outright causing. So some tuning and fixing required, but definitely potential. |
Beta Was this translation helpful? Give feedback.
-
|
From the description of the setting:
Basically, it's a way to preserve the changes in width between subsequent segments. If the change in width between one junction and the next is too large, it will not do it. So, the consequence of setting this high is that it might/will simplify in such a way as to undo some of the advantages that Arachne brings. |
Beta Was this translation helpful? Give feedback.
-
|
@Asterchades Thanks! Overhang problems might not just be Tree Support (or missing support interface). Our and QA's testing shows that Arachne is doing worse with overhangs for some reason, probably related to the problems in this sub-thread. Then again, if it's (give or take) the same on 4.8.x in this case. |
Beta Was this translation helpful? Give feedback.
-
|
I would expect the outer toolpaths to be nearly unaltered when using the center deviation strategy. Of the outer walls are still being altered then that might be related to simplification. One difference between clipper and Arachne is that Arachne first makes circular offsets from inward verts, while clipper makes mitered offsets. When simplifying the circular offsets the final toolpath will take a bigger shortcut through the vert (so the toolpayh is more outside) than the mitered offset. The simplify algorithm might be altered to generate results closer to the mitered offsets. Not sure if that really helps this problem, though. I really wanna look closely at a print to see if the print head stalls while printing the outer walls, but I'm not with my printers during the holidays. |
Beta Was this translation helpful? Give feedback.
-
|
This was fixed here: Ultimaker/CuraEngine#1405 |
Beta Was this translation helpful? Give feedback.
-
|
Seems like Arachne got a little play with brimwalls. The wall is now not one long line but like outerwalls and innerwalls in between which printing in different orders. Just got another play on it and it seems this is happening only if i choose 12-14 brimlines. When i select fewer or more it prints one long line. |
Beta Was this translation helpful? Give feedback.
-
|
Can reproduce weird order of brim lines on a simple cylinder as well. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't this also an issue in 4.8? See also https://www.reddit.com/r/3Dprinting/comments/km3psm/been_having_this_issue_a_lot_when_it_comes_to/ |
Beta Was this translation helpful? Give feedback.
-
|
I cannot seem to reproduce this issue in 4.8, though. |
Beta Was this translation helpful? Give feedback.
-
|
We've reproduced this issue and added it to our backlog, planning to fix it before the beta release. |
Beta Was this translation helpful? Give feedback.
-
|
Gotta love that under construction vibe |
Beta Was this translation helpful? Give feedback.
-
|
We considered putting it on the build plate somewhere, but that didn't get through in the end. |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice to have some kind of indicator on the top of the screen showing what version you are in, not just for testing versions but for others as well. I sometimes have 2 different versions up at the same time and I get them mixed up. The startup dialog is a good indicator but doesn't help after the program has started and pulling up the About dialog is slow (if I remember to look.) |
Beta Was this translation helpful? Give feedback.
-
|
The Titlebar Info plugin from the Marketplace shows the version in the titlebar: |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much fieldOfView |
Beta Was this translation helpful? Give feedback.
-
|
Half of its functionality was already "borrowed": showing the print job name in the titlebar was an "innovation" of that plugin. |
Beta Was this translation helpful? Give feedback.
-
|
When I press the "eject" button for the removable drive the program closes and I have to reopen it to continue working. Good job team |
Beta Was this translation helpful? Give feedback.
-
|
Good day! Also noticed Alpha isn't playing nice with some of the plugins. Auto Orientation puts models under the plate. Will look for appropriate threads to make this and other notations, but while I'm here ; ) the Side GUI doesn't seem to load either. The new features will be awesome and I'm hoping to see Arachne become the world's go-to slicer! Have a day! |
Beta Was this translation helpful? Give feedback.
-
|
Hi and well done for such a usable alpha. I have also the same close on eject
|
Beta Was this translation helpful? Give feedback.
-
|
Same issue for me with the program closing on eject of the SD card. |
Beta Was this translation helpful? Give feedback.
-
|
The application also appears to close if I reload a model. This does not happen all the time but if I have a model open in Cura and make alterations to the original outside of Cura, Cura will then ask to reload the changed model. If I reload the changed model using the popup dialog Cura closes. If I select Reload All Models (right clicking on object) the program does not close. |
Beta Was this translation helpful? Give feedback.
-
|
Can you guys try reproducing this issue in the 4.9-beta release? So far we haven't been able to reproduce it there. If you try it again, please report your findings in #9057. |
Beta Was this translation helpful? Give feedback.
-
|
Those inconsistent layers are definitely a thing. I pulled down, cleaned off (with fire, no less), and rebuilt my hot end, re-tuned everything (heater temp within ±0.3°c), and dug out some recently dried filament in a dry box (eSun PETG in Solid Gold). Set the Arachne build to Print Thin Walls down to 0.2mm (minimum feature size of 0), turned off Outer Wall Wipe, and no Top Surface Layers so it would slice. XYZ cube w/ castle: You can see the odd layers on the rear curve in the Arachne print. About half way up, offset a little above and below centre, there's a distinct difference in the surface finish and corners. What makes it more unusual is that it only affects the "shell" - the castle appears as you'd expect, but the whole shell layer is impacted. The lines appear to correspond to feature changes in the bulk of the cube, with the top of the platform, the bottom and top of the X/Y, the top and bottom of the vertical peaks in the X, and the level of the indented Z on the top all showing at least some marks on the outer wall (but, again, not on the castle - at least visibly), though that isn't necessarily causality. In regards to actual quality (particularly overhang), the Arachne build did far better than I was expecting. It's not perfect, sure, but its only just worse than it was in 4.8 aside from that errant bit down lower. Stringing was also basically non-existent (Outer Wall Wipe to 0.0mm just in case), with only a couple of wisps under the castle archway - though it's fair to say it wasn't quite as clean overall. The mark on the lower right of the Arachne print (just beside the castle) is the hole visible on the 4.8 print - or what's left of it after Arachne is through with it. Laser Rifle Terminator (WH40K): The Arachne print still has those weird layers that stand out, though. Since they're not present - at all - on either 4.8 print, I think it's safe to say at this point it's neither material nor printer causing it. I've used fairly harsh lighting to pick it out in a photo, but it looks fairly obvious in hand. Curiously, it doesn't start showing those problems until it reaches the body proper. It looks all the world like a very small amount of negative horizontal expansion is being applied to those layers, perhaps even with a tiny bit of rotation. Otherwise I feel there's very little in it between these two. Trees are still letting both down, with the Arachne generally faring slightly worse. There's a difference in the seam location which could be contributing, and in hindsight I should have probably fixed its location instead of using the auto facilities. The 4.8 print is also generally cleaner in my opinion (neither of these has been processed beyond removing the trees). As an aside, this is one time where 4.8 printed faster. But I suspect at least part of that comes down more to what it isn't printing than anything else, removing travel moves, print moves, and retractions. Difference was about 53 vs 63 minutes. |
Beta Was this translation helpful? Give feedback.
-
|
But is there gonna be another version after that? A gamma? |
Beta Was this translation helpful? Give feedback.
-
|
A Rc ... Release Candidate :) Rc1 Rc2 Rc3 Rc4 .... |
Beta Was this translation helpful? Give feedback.
-
|
The alpha was never a candidate to be released. We knew it wasn't releasable. |
Beta Was this translation helpful? Give feedback.
-
|
Just wait until we release the Omega version! |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Not sliced. Starting the progress but then drop it. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like you've got the experimental Bridge Mode settings enabled and one Top Surface Skin Layer. Turn off the Bridge Mode or set the Top Surface Skin Layers to 0. NB That's the Top Surface Skin Layer, not the Top Layers/Thickness. |
Beta Was this translation helpful? Give feedback.
-
Yes, it works! I Disabled the Bridge Mode and work ok. |
Beta Was this translation helpful? Give feedback.
-
|
A problem on a Thinkpad P5x series laptop would be a bit weird, as that's what most of the team uses to develop on (for work anyway) :-D |
Beta Was this translation helpful? Give feedback.
-
|
Decided to test this. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the printed results. Total print time 6 hours 27 minutes. |
Beta Was this translation helpful? Give feedback.
-
|
With thin wings like this, it's possible that the variable width has replaced a lot of gap filling or zig-zagging from skin lines that previously contributed significantly to the printing time. It's a good example for the sort of thing that this branch is intended to fix. |
Beta Was this translation helpful? Give feedback.
-
|
Did you also print the 4.8 gcode to compare with? |
Beta Was this translation helpful? Give feedback.
-
I did not print the 4.8 gcode. |
Beta Was this translation helpful? Give feedback.
-
|
Decided to give this a go. Definitely like the idea. I ran into a couple of issue when printing same model, both same exact profile. Issues:
EDIT 1) I sliced it again and it showed the same weird pattern into the preview. EDIT 2) SOLVED. I tried a very old profile and it sliced right, the issue is: With arachne: When I slice it with 0.5 maximum resolution and 0.25 maximum deviation it produces that weird pattern. Same thing does not happen in cura 4.8 I'll show a couple of pictures to help maybe diagnose the cause. Issue seems to be solved: |
Beta Was this translation helpful? Give feedback.
-
|
Did both of the issues resolve themselves, or just one of them? Where the setting changes you posted enough (to solve both problems) or did you have to do anything else? |
Beta Was this translation helpful? Give feedback.
-
|
At the very least it's indicative that we might need to change some settings still. One parameter that could also affect this is the transition angle. If it's too high that would cause vibrations when it's changing line width suddenly. Increasing the resolution could maybe dampen this effect because the nozzle will be going slower due to buffer underrun? |
Beta Was this translation helpful? Give feedback.
-
|
Left : Max Res&Trav 0.5 / Dev 0.025 / Jerk Extruder 7 / accel extruder 1100 / Distributed Thinking of bumping Jerk again to 10 :P Also would inward be more appropriate to keep outside shape?
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah inward would be more effective to keep the outside shape, especially if you have 3 or more walls. |
Beta Was this translation helpful? Give feedback.
-
|
I am trying it and I must say I like it a lot. However It is hard to use it in its current state, mainly due to supports. I tried it with PETG and I clogged the nozzle. In my test changing the default "Minimum Variable Line Width" from 50 to 75% worked fine. 50% means with a 0.4 nozzle it will use 0.2 line width right? It is too low in my opinion and it may cause underextrusion too. |
Beta Was this translation helpful? Give feedback.
-
|
That's good to know to set our defaults correctly. I proposed the 50% since I know that with the Ultimaker 2, 3 and S5 this works well. But other printers might need a different default, and I tested with PLA rather than PETG. It would be good to put the most common denominator in fdmprinter.def.json as global default. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hi, Running a 1000% scaled Benchy on our large format (3 meter x 1 meter x 1 meter) printer, there slicing progress bar starts and then pauses with no discernible progress. Left it on overnight to see if it would slowly progress but it looks like we've managed to stall it out.
There's a bed level test underneath that which will slice;
but not when it's scaled above 233%
Assuming that build volume is in some way stalling the slicing process so I thought I'd share in case it helps. -Nate |
Beta Was this translation helpful? Give feedback.
-
|
It would help for us to get a project file of this (File -> Save Project...) to see if we've got the same crash here as what we've seen with other models, and to ensure that if we make a fix for the other crash that this one is also fixed. |
Beta Was this translation helpful? Give feedback.
-
|
Attached a copy, |
Beta Was this translation helpful? Give feedback.
-
|
Oh would you be so kind as to also include the square test print? That would take a ton of time out of debugging the problem! |
Beta Was this translation helpful? Give feedback.
-
|
This crashes for me as well (after just 1.4 seconds of slicing), with the assertion failure: In release mode (assertions are ignored) it then proceeds to crash with a segfault. So this issue is reproducible with that project file. We're already investigating crashes with this assertion failure this week. It's something we've seen before with other models as well (including the 100%-scaled Benchy on a plain UM3). |
Beta Was this translation helpful? Give feedback.
-
|
This crash is fixed by this PR: Ultimaker/CuraEngine#1414 |
Beta Was this translation helpful? Give feedback.
-
|
Another observation Wall lines aren't parallel when transitioning from one to two wall lines. Having this setting low as default will also improve how well gaps are filled but the flowrate will change faster and the quicker direction change can introduce ringing. |
Beta Was this translation helpful? Give feedback.
-
|
Just verified that this also reproduces when you set the max resolution to 0.001 and the max deviation to 0, so it's not related to the toolpath simplification algorithms. |
Beta Was this translation helpful? Give feedback.
-
|
Here's an idea to somewhat fill small gaps better: |
Beta Was this translation helpful? Give feedback.
-
|
You mean, like, extending the Outer Wall Wipe Distance setting also to inner walls? |
Beta Was this translation helpful? Give feedback.
-
|
Yes or more like the infill wipe (it continues in the line direction rather than following a printed line?) |
Beta Was this translation helpful? Give feedback.
-
|
First up, thanks for the great work guys! An example of where this seems to be doing it's job: Cura Arachne It may be lower on your priority queue, but is there a thought to add a setting for 'layer width' by colour in the Preview function? I think this would help with testing to see that the Arachne engine is doing what we think with layer widths? I can see that some lines are shown thicker, but it can be difficult to see, so colours for different line width might be easier to see? cheers |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we had the same idea. I added that a few days ago: #9289 |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick feedback to this alpha version: I've been using it since beginning of January almost daily and the new algorithm is a huge step forward for me. Some issues that have been mentioned here, like the omitted retractions when outer wall wipe distance isn't 0 have also affected my prints, but I didn't read through the whole thread, so please forgive me if these minor issues has been mentioned before. ) Concentric support crosses part areas on the first layer. Also it took me some time dialling in the new settings. The default minimum variable line width was a bit too small for me and my focus on sturdy parts, so I use a higher value here. Also the wall transistion settings caused some artifacts on a few curved walls with large radii and I had to adjust them via trial & error to fit my needs. For the variable line width strategy I prefer center deviation. Apart from this, the new alpha is a rather smooth experience and I'm already very happy with it. Can't wait to test the next version. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for lookin into it! I've also tried all kind of shaningans but wasn't able to get rid off it. Good to know that a raft could be workaround. |
Beta Was this translation helpful? Give feedback.
-
|
I think the best workaround is choosing something different from the conecntric pattern. Concentrix support isn't really robust. It basically only works for 90* overhangs. |
Beta Was this translation helpful? Give feedback.
-
I don't think this is related to Arachne, but rather something we changed for Cura 4.9 then, since it's about the front-end. It would be good to have a log, but even better to just report this in a separate issue rather than this discussion thread.
Also a 4.9 issue. This one is reported to us before.
This is a long-standing issue that happens with all large slices. The problem is that the post-processing scripts are Python scripts processing the g-code. If the g-code is large, it can take a lot of time. Python is not the most efficient with that sort of thing. |
Beta Was this translation helpful? Give feedback.
-
|
Thank's ghostkeeper for the explanation. I'll try to generate a log with the hanging problem. Currently however I fail to reproduce... maybe it only was apparent on my linux machine? One more minor issue that's new with arachne alpha: When saving a project file (.3mf) and I choose to overwrite an already existing .3mf, there's a message appearing every time that warns me about the fact that this file has been modified. This warning in general and the offer to reload the file in specific doesn't make sense in this context. See attached screenshot: |
Beta Was this translation helpful? Give feedback.
-
|
If it's Cura that wrote the file, it indeed doesn't make sense that it warns you about that the file changed. I mean, from a programmer's perspective it's logical, but not from a user's perspective. |
Beta Was this translation helpful? Give feedback.
-
|
I use bottom layer concentric fill pattern and separate islands are filled consequtively, line by line rather than island by island. |
Beta Was this translation helpful? Give feedback.
-
|
Cura 4.8 wasn't optimal to begin with, but the behavior has changed a lot. 4.8: Arachne pre-beta (20210305) |
Beta Was this translation helpful? Give feedback.
-
|
If the "Order Inner Walls By Inset" setting is disabled, it orders them more as you are expecting, I think. We changed how this bit works quite significantly. It's still not perfect, mind you. But it groups walls together by region rather than by inset: |
Beta Was this translation helpful? Give feedback.
-
|
Aha! So that's how it works! |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice if full polygons are printed after all polygons that are adjacent and outside of it. We never really made a fully working order optimizer which could take such hierarchical constraints into account, though, so I wouldn't expect such a feature to be in the Arachne release. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the problem is that it actually does complete the full polylines and polygons as received from the Skeletal Trapezoidation. Only these polygons are often broken up into several pieces because there is a junction in between somewhere, usually at the sharp corners. This gives the effect that it's printing region-by-region which is less desirable than printing the full polygons in sequence. |
Beta Was this translation helpful? Give feedback.
-
|
Got a crash on this model. |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't crash on the newest version anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Got an infinite loop on this particular height of benchy: |
Beta Was this translation helpful? Give feedback.
-
|
That was also why I tested it right away. I was a bit worried that he found something that we hadn't fixed yet. |
Beta Was this translation helpful? Give feedback.
-
|
No I'm just still on the alpha. |
Beta Was this translation helpful? Give feedback.
-
|
I figured I'd still better report them just to be sure. |
Beta Was this translation helpful? Give feedback.
-
|
Good call. |
Beta Was this translation helpful? Give feedback.
-
|
Good work! |
Beta Was this translation helpful? Give feedback.
-
|
I like Cura Alpha and I use it most of the time. |
Beta Was this translation helpful? Give feedback.
-
|
Or is there an easy way to make your own package with all the commits included? |
Beta Was this translation helpful? Give feedback.
-
|
yes yes i am also waiting for alpha 2 ))) |
Beta Was this translation helpful? Give feedback.
-
|
The first beta should be up at the end of this week, if I understood correctly. |
Beta Was this translation helpful? Give feedback.
-
|
It's going to be released in a few days. We've fixed ~40 crashes / bugs. |
Beta Was this translation helpful? Give feedback.
-
|
is it possible to add new printer in installing package in arachne? |
Beta Was this translation helpful? Give feedback.
-
|
You mean by yourself? Yeah. It works in the same way as the other Cura versions. |
Beta Was this translation helpful? Give feedback.
-
|
yes i added manually and it works, but would be great if it will be in cura install exe by default. |
Beta Was this translation helpful? Give feedback.
-
|
We do accept pull requests for new printers to be added in Cura by default, provided they pass the automated checks and code review. |
Beta Was this translation helpful? Give feedback.
-
|
firstly I'm not well versed in etiquette for git hub so thanks in advance for tips. i am new also to arachne cura. it is very pleasing to see the efforts the devs are puttingh in to solve the wall thickness crisis experienced in regular cura. for many hours i have tweaked line widths manually in search of the perfect slice. i have particular interest with this version for my 1mm nozzle printing but alas it wont slice when i change either the machine settings or line width to 1mm. any tips on getting past that glitch? |
Beta Was this translation helpful? Give feedback.
-
|
That sounds like a serious bug. Could you please attach your project file so we can reproduce the bug? |
Beta Was this translation helpful? Give feedback.
-
|
It seems to have been resolved in the beta version. I'll attach the
project on Monday
…On Thu, 18 Mar 2021, 7:31 pm Tim Kuipers, ***@***.***> wrote:
That sounds like a serious bug.
Could you please attach your project file so we can reproduce the bug?
File > Save project > save as .3mf file > rename file extension to
.3mf.renamed.zip > drag the file in a comment here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8965 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJIR45FO6X7U4AU2DR5K54TTEG27BANCNFSM4VBDNADQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
If your slicing bug is resolved in the beta, it's most likely something we already knew about and fixed. It's good to hear feedback that our fixes also apply to a wider variety of models! But we won't really need a project file then. We'll trust you on that it's fixed. |
Beta Was this translation helpful? Give feedback.
-
|
Will you back Fuzzy Skin in arachne? i use it lots)) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we have a ticket to re-enable it. We just didn't get to it in this beta. (Technically, beta's are supposed to be feature complete under some definitions of the word, so I understand the confusion! And |
Beta Was this translation helpful? Give feedback.
-
|
As an aside, this is the discussion for the 'alpha', the 'beta' discussion is here #9388 |
Beta Was this translation helpful? Give feedback.
and others
-
UPDATE: There now is a BETA available, this supersedes the ALPHA this discussion refers to, please see here for more information.
Hi!
Since you're reading this, you're probably here because you have some feedback on the Cura Adaptive Line Width Alpha. If so, first of all, thank you!
Keep in mind that in many cases, print quality, especially out of the box, will actually be worse than with the current latest release, 4.8.0.
We'd really appreciate it if you follow the following guidelines (in addition to any existing guidelines that may exist):
Builds for all OSs' are now live! :-)
https://github.com/Ultimaker/Cura/releases/tag/Arachne_engine_alpha
UPDATE: In the change-log included in the alpha release, and the news articles, we forgot the 6th added parameter: 'Maximum Extrusion Area Deviation'. It should have a good default, but it does affect simplification of extrusion lines, with all consequences related.
Beta Was this translation helpful? Give feedback.
All reactions