Arachne engine beta release - Feedback

[fvrmr]

Hi everyone,

Welcome to the discussion thread of Arachne engine beta. You are here because you probably want to share some feedback about the release of Arachne engine beta, so thank you for taking your time and give us your feedback.

Please keep in mind that the print quality in many cases will be worse than with the current stable release, 4.8.0.

We really appreciate it if you would follow the following guidelines while posting:

• Read the release notes before posting. Make sure that it isn’t already a known issue.
• Please note the printer you used, as well as any profiles or changes.
• If you need to share a model, please save as a project (file – save project) and attach here as a .zip.
• A picture really does say more than a bunch of words sometimes.

New features in Arachne engine beta:

• Line Width Color Scheme
• Static Outer Wall: reduces ringing
  For more details see the release notes.

Bug fix highlights:

• The Randomize Infill Start, the Infill Travel Optimization, the Infill Layer Thickness and Support Layer Thickness settings are now all working on Arachne.
• Fixed numerous crashes.
• Fixed multiple infill issues.
• Initial Layer Line Width now only applies to the initial layer again.
• PVA supports should work properly again.
• Improved cornering/seams.
  More (and more details) in the actual release notes.

Known issues:

• Some models might still crash the engine, although it is less frequent than before.
• Infill support can crash the engine.
• The seam isn't positioned correctly when using the Hide or Expose or Smart Hiding placement options.
• User specified seam is not aligned.
• Paths for concentric ironing aren't generated.
• Concentric support pattern can intersect with model.
• Lines are not always symmetrical in width at the transitioning point to a lower wall count.
• Center line is not generated for center deviation strategy.
• Missing infill/support walls in certain areas when using Extra Infill/Support Wall Count.
• Brim lines ordered wrongly.
• Raft interface layers and raft layers don't align.
• Connected infill and gradual infill results in overextrusion.
• Bottom Skin Expand Distance at zero causes skin to expand beyond walls.
• Spiralize could generate both inner and outer surfaces.
• Bottom layers of a spiralized model with surface mode enabled, looks like inner walls.
• Last bottom layer might disappear for a spiralized model.
• Stringing when spiralized is enabled.
• Fuzzy skin isn't implemented.
• Connect Top/Bottom polygons isn't implemented.

All builds for the OSs are live!

Looking forward to see your prints 😄

[rburema]

Since the build is now properly online, I've marked the above discussion as outdated.

[5axes]

I don't really understand why in the Line Width simulation the color scale start from 0.1 ?

[Ghostkeeper]

This is a side-effect of unretracted travel moves actually getting a width of 0.1mm by CuraEngine: https://github.com/Ultimaker/CuraEngine/blob/e508c6044845213489230af68505f161092567ed/src/gcodeExport.cpp#L718

Ideally travel moves don't get counted in this statistic.

[nallath]

I think we should add that to the list of improvements. It would make it easier to see subtle differerences in this view after all.

[Rijaspb]

https://www.rijasexports.com/

[Asterchades]

Top Surface Skin Layers and Enable Bridge Settings still aren't playing nicely together. Same result as before - if there's enough upper most area to actually require a skin on any portion of the model, having both settings enabled will cause it to slice then go back to 0% and sit there indefinitely.

[jellespijker]

That sounds like an engine crash, can you attach the project file. So that we can test and debug with it

[Asterchades]

One project, coming up.

Cali-cube.3mf.zip

NB I've been able to produce this on pretty much any model which has an upper surface that qualifies for the top-most skin. I say "pretty much" to cover my ass in case I forgot one that worked, but I'm actually fairly confidant it's anything and everything which qualifies.

[fvrmr]

Thank you @Asterchades
I am able to reproduce this. Will discuss this with the team. Keep you posted!

[fvrmr]

We created a ticket on our backlog for this issue.
Developers see CURA-8096

[Rijaspb]

https://www.rijasexports.com/

[5axes]

Beta the result looks better. I still have a repetition of the "defaults" but just on one Level, Need to test in the real life.

[Ghostkeeper]

This is the result of the "Static outer wall" feature listed in the change log. It will now keep a fixed width for the outer wall until your model is only 2 walls wide or less.

[Ghostkeeper]

This feature really got made thanks to your (collective) feedback to the alpha, and was designed specifically with this model in mind. Thanks for that!

[Asterchades]

Curiously, have you guys approached the Marlin team to see whether there's anything that can be done at the firmware level to better aid line transitions? It feels like there's still a lot of contention between what you're trying to do and what the printers are capable of doing, or at least capable of attempting given the current firmware implementations.

[BagelOrb]

Indeed being able to accurately manufacture line width transitions is quite important. It seems that currently there aren't many features for that either in Cura nor in most firmwares. Cura has (had) Equalize filament flow to control the movement speed to alter the width (but it's not ported to Arachne yet) and some firmwares have linear advance which can be tweaked a bit to perform varying line widths better.

However, Cura has always had varying line widths for the gaps between walls and for overlap compensation. The goal of Arachne is to distribute this variation over multiple lines so that the printing process is in fact less affected by the inaccuracy of varying line width.

Many people who first look into Arachne will see there's now a focus on line width variation and wrongly assume that line width variation is something new which is not yet supported by the printers, while in fact Arachne reduces the line width variation.

The fact is that the width of the model is not always an exact multiple of the nozzle size, so you have to adjust the width of some of the lines. The framework of Arachne makes it possible to do any distribution of widths. If you have some better distribution of widths in mind than is currently possible with the settings for Arachne then we're very interested to discuss it.

[Asterchades]

Many people who first look into Arachne will see there's now a focus on line width variation and wrongly assume that line width variation is something new which is not yet supported by the printers, while in fact Arachne reduces the line width variation.

I guess that's probably where my own disconnect is. I know I've been thinking of lines which transition from one width to another across their length, rather than multiple line segments which mimic the effect but each one is still a regular extrusion in and of itself.

I was also thinking about a comment that I think Ghostkeeper made during the alpha where it can take time between when a line width change is requested of a printer and when it actually takes place - particularly in the case of bowden systems. But that, as you mention, might be more in the domain of Linear Advance, or perhaps the pressure compensation that BagelOrb is referring to below.

[BagelOrb]

Equalize filament flow doesn't work any more.

When you reimplement flow equalization please also consider implementing the back pressure compensation approach I described in my paper.

[Ghostkeeper]

Yeah, we saw this ourselves too. I reported a ticket that it should be removed since it only had effect on the gap filling in 4.8, and gap filling was removed. We have a different ticket to re-introduce it for all wall lines for which we'll look at the best way to do this, taking your research and that of Ultimaker's process engineers into account.

[BagelOrb]

I wouldn't remove the setting. The new feature should do the same thing, basically. Only difference is that now there is varying width in more places than only the gap filling, so the setting has effect on more places.

[BagelOrb]

The back pressure compensation approach can be captured in a simple setting: Flow Equalization Percentage.

With normal 4.8 flow equalization you would have: v = v_0 * w_0 / w
With the percentage setting f you would have: v = v_0 * ( (w_0 / w - 1) * f + 1)
(v_0 and w_0 are the speed and width settings according to the profile)

According to my paper the k value is good around 0.2, which means that the f value would be good around 120%

[printingotb]

The top bottom category doesn't appear so I can't change those values:

TopBottomCategory.zip
Searching for settings works though and then I can change them:

[printingotb]

Whoops. Didn't pay enough attention reading the problem. Sorry!

Happens to the best of us 😉
I did look three times before posting it to make sure I wasn't just blind haha.

Oops not the first time I share the model instead 😬
It's the same with the normal settings profile:
TopBottomMissing.zip

I noticed another strange thing that may or may not be related to this. The wall thickness setting shows as if it has an absolute value but I haven't touched the profile. Resetting it makes the profile show as modified:

[fvrmr]

Hi @printingotb it seems like it has to do with your selection. Because it is on custom selection, if you click the menu next to search settings and change it to basic or all the top/bottom is visible.
To make it visible in custom selection press default and than it will be visible also.

The wall thickness setting seems to only happen with your project file. It doesn't happen on any other printers.

[Ghostkeeper]

We split up the "Shell" category into "Walls" and "Top/Bottom", which might have something to do with this. There was an internal bug report a while ago from one of the testers that the Walls and Top/Bottom categories didn't appear and we fixed that I thought.

[printingotb]

The same happens in the "per model settings" window. The Top/bottom category is missing but changing the selection set works here too. In one case I managed to see the top/bottom settings even though the category header was missing. Can't reproduce that anymore though.
Perhaps this has to do with the "Settings visibility Set Creator" plugin?

Per model settings window:

[Ghostkeeper]

It could be partly caused by the Settings Visibility Set Creator plug-in but I doubt it.

My current theory is that this is caused by a lack of version upgrade. There is a list of visible settings in the preferences file, and this list needs to include the setting categories, which are internally also "settings". If you came from 4.8, the new category needs to be made visible.

That plug-in allows for creating a cfg file type that Cura already internally uses for the default "basic", "advanced" and "expert" settings lists, so you can create more. I'd expect that this plug-in will suffer from the same fate. Perhaps we can keep this in mind when we add the 4.9 version upgrade, as a helping hand to users of that plug-in. It would be cumbersome for the plug-in developer to have to build their own version upgrade system.

This is a change we made in 4.9 and one that we'll have to solve before the 4.9 release.

[Asterchades]

EDIT: Found the problem: the printing direction of the walls is not consistently clockwise throughout the print. Hopefully this bug will be fixed in the next release.

Sadly my first test print showed an error that was hopefully corrected wasn't. There's still a very slight (sub-1mm) shift to the rear right on layers where part of the same section also includes single extrusion walls.

xyzCalibration_Cube__Castle.3mf.zip

It's not the easiest thing to photograph given I need to provide some kind of light and it's very small, but it's definitely still there. I've deliberately used very harsh lighting to show it off a little clearer. The small variations you see on the right corner correspond to peaks on the X and Y.

[Asterchades]

I mean, yeah. Under ideal circumstances I wouldn't expect the print direction to make a lick of difference. Going from 0,1 to 0,10 should be exactly the same as 0,10 to 0,1, after all. But we're talking a sub-$200 printer here which I'm kinda pushing to its limits, even if I have upgraded it (probably another half again in upgrade costs), so "ideal" is only a pipe dream even before getting to the restrictions of FDM in general.

So with "ideal" off the table, consistency is probably the next most important thing.

[printingotb]

I think this inconsistency can also be related to where the seam is placed. If the distance from the seam to the corner varies, so may print speed and actual flow just before the corner.

[fvrmr]

Ah yes found it too. Will discuss it with the team.

[printingotb]

🤦 I spent the entire morning taking pictures and analysing this dice tower only to discover that it was the same issue as this. I thought I had checked that already 🤦 🤦 🤦

So the only thing I can add is some beautiful pictures and an observation about the seam placement moving by changin the outer wall inset.
I had outer wall inset set to 0.02mm and thinking that it may have something to do with that, I tested increasing it to 0.2mm but then the seam is moved to the same coordinate as all the other layers(!).
It also appears that the seam position is only changed at the layers printed in the other direction so by changing the inset, I also "fixed" the direction.

The good news is that the dice tower printed perfectly apart from this and Arachne handled the varying wall thickness excellently.

The lines are brighter because the glitter additive refracts differently depending on the print direction and viewing angle.


Dice tower seam lines.zip

[fvrmr]

We have created a ticket for this on our backlog.
Developers see CURA-8114

[BagelOrb]

The line width visualization seems to visualize some ideal line width instead of the actual line width. Those two segments have a different width and a constant width, but they have colors as if they are changing width and as if they are the same change in width, which isn't the case.

[jellespijker]

@nallath you recently noticed the same behavior. Did you made a ticket for this already?

[Ghostkeeper]

Just like the line speed, the line width visualisation takes on a colour per vertex rather than per line segment.

[BagelOrb]

But the geometry of the shaded lines have constant width! That's rather confusing.

Currently it seems to show the color of some hypothetical optimal width, which isn't actually present in the gcode.

Why not just show the actual width of the lines in the gcode?

[BagelOrb]

Widths according to Cura:

Widths according to Cura when reloaded from gcode:

Widths according to PrusaSlicer:

PS:
IdeaMaker:

RepetierHost:

TinyG Chillipepr:

[fvrmr]

We have created a ticket on our backlog for this combined with this feature request: #9388 (comment)
Developers see: CURA-8113

[BagelOrb]

The order in which gap filling is printed has changed.

The gaps between the outer walls should be printed after the outer walls have been printed.

Arachne: (image shows halfway the layer starting to print the outer wall, which is outside of the 'gap filling')
halfway through layer

full layer

4.8:
halfway layer

full layer

UMS5_long_wedge.3mf.renamed.zip

[BagelOrb]

The order in Arachne will be worse for print quality because the inaccuracy with which the odd lines (gap filling lines) will get propagated outward. Sarita is working on showing this with actual prints.

[fvrmr]

We have created a ticket on our backlog for this. But we think it is more a feature request than a bug.
Developers see CURA-8109

[BagelOrb]

If a feature was there in 4.8, but not any more in arachne then that's a regression.
Whether a feature getting lost is a bug or a request to reimplement the feature is a bit of a non-issue.

[BagelOrb]

This inner line is too wide:

The line width should be in the middle between the wide side of the line and the narrow side of the line, but it appear to be as wide as the larger end only.
UMS5_long_wedge.3mf.renamed.zip

[BagelOrb]

Here's a more clear example:

UMS5_long_wedge_1mm_w.3mf.renamed.zip

[BagelOrb]

These blue lines are not and should not be 0.05mm, but their color suggests they are.

[fvrmr]

We have created a ticket for this issue.
Developers see CURA-8133

[Ghostkeeper]

This has been fixed by Ultimaker/CuraEngine#1437 .

[BagelOrb]

Why is there a very bright green location in the color palette and to which value does it correspond?

Feature request:
Please make it so that that color corresponds to the value of the setting Inner Wall(s) Line Width.
Would also be nice if the value could be mentioned in the legend.

[ahernsean]

@rburema That's an excellent decision. There's no ambiguity with that kind of a colormap. It's "boring", but it does the job precisely and accurately.

[BagelOrb]

Watch out that the dark and light doesn't interfere with the 3D visualization of the extrusion toolpaths, though.

[kvnper]

In my opinion, with colours, you can see, at a glance, which sections are a certain speed by looking for the specific colour. Light to dark muddles everything together and becomes "grey with a tad more grey than white", "white but still greyer than white white", etc. Things just become a big blur. At the very least, an option to toggle between monochrome and colour, if they're adamant.

[Piezoid]

I agree that, with shading and aliasing, a monochrome colormap might be harder to read.
For reference, there is many different viewpoints, all somewhat subjective, on what is a good colormap: Turbo an alternative Jet by Google, analysis of color discernibility, or this talk about the development of viridis and co in matplotlib.

[Ghostkeeper]

XKCD published a new colour map recently: https://xkcd.com/2537/

But yeah, I don't think monochrome is a good option. It'll tend to look like a silhouette because there can no longer be 3D shading. So you get something like a depth map image. In our case it'll probably be a bit worse than the elephant in the example there too because Cura normally produces big areas that have the same speed, like skin.

The current colour scheme was designed for the speed property. The bright green highlight is roundabout the area where normally the most lines are printed, with a small lower side for slower layers like for Minimum Layer Time, and a large upper side for the travel moves.

[BagelOrb]

"beyond which it will" >> "below which Cura will"

[Ghostkeeper]

That's indeed better. Done! Thanks.

[BagelOrb]

Minimum variable line width doesn't work as expected.
If the geometry becomes smaller than twice the minimum variable line width then Cura should not put two separate lines anymore, but 1. Therefore I expect that with a Minimum Variable Line Width of 50% all lines should be between 50% and 100% of the nominal line width.
However, we can see colors in the widths which are more orange than the outer walls, which have a locked width of 0.1mm.

EDIT:

The description is wrong for what the setting does.
Putting it at 50% means that the transition will occur in the middle between a model width of one line 0.4mm and two lines 0.8mm, i.e. at 0.6mm, which means the line widths around that transition are 75% and 150%.
I think we should update the setting name and description. Maybe something like: "Width Variation: Thinner vs Thicker"

Also it doesn't seem to work properly for the Center deviation strategy. I suggest to disable it for that strategy.

Furthermore I suggest to remove the center strategy altogether; see comment below.
If you follow my advice there then the Minimum Variable Line Width should get two children: one for even (e.g. 2 > 3) and one for odd (e.g. 1> 2) transitions.

[BagelOrb]

Gap fillers get erased when using center deviation strategy and a minimum variable line width of 100%

[BagelOrb]

Decreasing the minimal line width actually increases the line widths of the thinner lines:

@ 50% :
some lines are below 0.1mm

@ 1% : (beware of the change in layer preview color palette!)
no lines are below 0.1mm

Within the same print: 50% top 1% bottom:

50% top, 25% bottom:

min_var_line_width_comparison.3mf.renamed.zip

[al-65]

Hi all, and thanks for this innovative approach which seems to improve things like threads significantly!
If I had one free wish, I would love to have the "z seam shortest" work like it used to in the pre-2.4 versions, so the next layer starts where the previous ends :)
Best regards, Andre

[BagelOrb]

Hi al,
Thanks for your input.

The reason why that behavior changed in version 2.5 is in order to slice faster (multi-core). Also we deemed that starting from approximately the same position each layer leads to a more homogenous heat distribution which improves print quality.

Getting that feature back will unfortunately not be on the agenda. I'm sorry. :/

[al-65]

Hi there, and thanks for the quick response, though!
Just in case, one may get both this feature and fast slicing by assigning packs of, say, 10 layers to each thread so that "z-seam shortest" could at least work within those packs.
Best regards,
Andre

[nallath]

We could, but it would make things a lot more complicated. I'm not so sure that the change is worth it.

[BagelOrb]

I thought the brim was also generated with Arachne, but seeing these gaps makes me think otherwise:

I expected the gap in the middle to be filled up.

Cura Arachne beta

box_first_draft.3mf.renamed.zip
Here's the 3mf file containing the parts. Fun fact: working with 3mf file exports from Fusion 360 is riddled with bugs. Is there something wrong with Cura or is there something wrong with Fusion? (reloading from disk goes wrong, objects not grouped, merging distorts the model dimensions, group doesnt rotate about center, etc)

[Ghostkeeper]

Indeed, the brim is out of scope for now.

[BagelOrb]

Is the brim still being generated with clipper offsets then?

In that case this is not an Arachne bug. I would be okay with closing this thread.

[discip]

@Ghostkeeper
Is there any daily/weekly/dev built I could test on windows?

[nallath]

Not yet. But we are currently working on arachne for an entire sprint. We've made really good progress, so I hope that we can release an in-between version (or yet another beta).

[Anisotropic]

I hope that we can release an in-between version (or yet another beta).

You know we're kindly waiting for it.

[discip]

@nallath
Sounds good!
To be honest: I can’t wait to test a new build, especially since I am seeing that it’s being worked on in the background.
Thanks in advance.
kind regards

[rv0arm]

I wrote on the forum, I will repeat in this thread.
Very often I see the separation of the jumpers from the main wall.
Sometimes it is presented perforation effect on the connection joints.
The seams are many small holes.
An attempt to somehow influence the elimination of these problems is ineffective.
The only thing that helps me is reducing the rollback and increasing the amount of plastic flow.
Photo of defects (except perforation).

We are looking forward to a release that will fix the problems of the previous one.

[Ghostkeeper]

This is a result of the printing process, not of the g-code. We can't tell whether or not this problem is fixed without printing the same print as you, on the same printer with the same filament and same temperature and humidity.

We don't have the same printer as you, so we can't fix your problem unless you can indicate what is wrong in Cura's output g-code. Can you give us information on what you see going wrong in Cura's output?

To help the print process, you might need to reduce acceleration limits, or reduce the line width / increase the width of the print such that you get multiple walls there instead of 1.

[Piezoid]

Have you tried reducing or disabling the Outer Wall Wipe Distance setting?

[rv0arm]

I left this parameter by default - 0.4мм . Since I print with a 0.4mm nozzle on a printer Flying Bear Ghost5 .
Printed PETG file aileron .
File boat print on photo with plastic ASA.
But if you start printing the boat with plastic PETG
then you get the problem of printing and holes on the first layer if set the number of layers to 2 or 4.
I had to put the number of layers on the order of 20 to get around the problem.
I give you the files for the test.
Project files when there are problems I can not give because I have to adapt to close the problems.
And the solutions do not always correspond to the logic, since there are no usual parameters CURA.
Or they are simply removed or renamed somewhere.
Despite the shortcomings of the Beta version, I print on it because I like it better.
I print RC models, and only this version gives me the results I want despite the problems.
I print with plastic PETG .
And Arachne gives a very elastic seal in contrast to the classic.
Aileron_LR3.zip

[Ghostkeeper]

I'm a bit confused here. I think you're using machine translation, but it's making some mistakes. You can't set the number of layers to 2 or 4. Maybe you meant the number of walls?

I loaded in that Aileron model, using Flying Bear Ghost 5 and PETG. I'm not seeing any significant holes appear in the bottom:

Project files when there are problems I can not give because I have to adapt to close the problems.

Maybe you could revert some of these changes to make the problem appear again? Without knowing exactly which settings you used, I don't think I can reproduce the problem. Maybe it'll help to upload some pictures of what problem you're seeing exactly (in layer view).

[rv0arm]

I deleted the file that has problems with the bottom.
This file is commercial, and I was afraid that the author of the project would not be happy that his files are being shared.
Therefore, after 3 days, I deleted it
This part in your drawing has a problem that the inside of the wall does not connect.
The head makes a route that resembles the letter T. And the connection of the walls in the form of the letter H and the lower stick does not connect to the wall.

---

Once again I am posting a detail of the project where there was a problem with the bottom.
The head just bypassed the places marked in red, although in the slicer, as you can see, everything is OK.

[rv0arm]

To print normally, I had to put 20 layers of the wall.
And yes, I cannot now control the thickness of the bottom.

[Ghostkeeper]

Ah, so you're saying that those areas marked in red are not filled by the printer at all. Even though you can see them getting filled in layer view.

One thing you can do then is to store the g-code on disk, and load it back into Cura or another g-code simulator to see if the g-code instructs the printer to fill it. As far as I can see emulating your settings from that screenshot, it does get filled properly in the g-code. So it would then be the printer or firmware's fault that it's not executing some parts of your g-code.

[rv0arm]

So my printer is so terrible that it doesn't fit your software ...
But why, without changing the settings, I printed and assembled this model through Cura 4.8?

---

I understood -

1. My computer is terrible for your software judging by this issue -
   4.9-4.10 does not open stl files #10254 (comment)
2. My printer is also completely unsuitable for everything you do above version 4.8.

---

Please forgive me for what I have bothered.
I want to thank the people who gave advice with my crooked iron to switch to another slicer - Super sliser.
The program recommended to me works without problems with my hardware and the quality satisfies me more than ...
Once again, sorry that I made a mistake, having such equipment, I started using your product.
Bye.

[rv0arm]

I forgot to say that my printer is altered under Direct.
Filing calibrated.

[ahernsean]

Request: Add ability to mouse over a line and display its numerical width at the pointer location.

Varying line width is the signature feature of Arachne. The width is shown mapped to a color in the Cura slice preview. But sometimes it would be good to know the precise width that Cura has calculated for a particular point in the slice. Would it be possible to allow the user to mouse over the preview visualization and have Cura display the calculated line width at that pointer location? I envision this being displayed as a tooltip, but maybe there are other more appropriate places to display the value.

I was imagining something like this picture:

[fvrmr]

Hi @ahernsean thank you for your request. I will bring this up for discussion with the team. Keep you posted!

[fvrmr]

I have created a ticket on our backlog for this. Devs see CURA-8523

[Ghostkeeper]

Not going to be an easy one to implement, considering that mesh is generated in a geometry shader! We can't just sample it with a ray intersection. We can't reliably sample it from the image either due to the Lambertian shading. It must be possible but it'll be quite a refactor I think.

[rburema]

We could in theory just render a second image that isn't Lambert-shaded (but not render it), then use that to sample.

While none of this is exactly simple given the existing code base, it may not quite require as extensive refactors as you might think.

(edit: added 'Lambert' to avoid confusion with the concept of shaders)

[ahernsean]

We could in theory just render a second image that isn't Lambert-shaded (but not render it), then use that to sample.

That's precisely the method that we use in the visualization tool that I work on. We use the accumulation buffer to keep track of which object is drawn in each pixel, no matter how that object is colored or lit in the visible frame buffer. Then, when the user probes the window to "pick" an object, we can take a look at the accumulation buffer value at that pixel and know what object is chosen.

[jornada812]

Freezing on slicing
Slicing is unsuccessful when connect infil lines is enabled
Profile https://yadi.sk/d/ACblFO39PzjCEA
Model https://yadi.sk/d/egEVjcps-4X3nQ

[jornada812]

With the beta release back in March your issue reproduces, but not with the current state of the code. We didn't build a release yet since March. If you want to test the fix, you'd have to compile CuraEngine and update the settings list in the front-end.

Sorry. For some reason I thought that after fixing the errors, the version is immediately updated for subsequent tests.

[Ghostkeeper]

@discip CuraEngine only supports compilation with MinGW, on Windows, so you probably can't use Visual Studio Code. Some people tried and made fixes for MSVC, which we'll merge, but it's not something we maintain.

The difficult part of compiling CuraEngine is the linking with libArcus, which handles communication with Cura's front-end. This can be disabled though in the CMake variables, which makes compiling CuraEngine as easy as just cmake . && mingw32-make. However you can only call CuraEngine from a command line then. It won't work with the Cura interface.

The broad steps to using a self-compiled CuraEngine would be:

• Compile and install libArcus with MinGW.
• Compile CuraEngine with MinGW, making sure that the CMake step finds libArcus. Use the libArachne_rebased branch of the CuraEngine repository to get the Arachne edition.
• Drop in the new CuraEngine.exe in the Cura installation folder.
• Also take the new fdmprinter.def.json from the libArachne_rebased branch of the Cura repository to get the new/changed settings.

For more complete steps I'll refer to our run-from-source instructions here: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Windows

[discip]

@Ghostkeeper
Good afternoon,
first: Thank you for reacting to my post at all! 😃
My second thought, regarding the complexity of the process you described: 🤯
Is it possible for you to share the CuraEngine.exe, since you are using it and it only takes around 6MB?

As we are on it:
Am I right, assuming that it will work, if I just put the latest CuraEngine.exe into the latest Cura 4.11 installation folder?

thanks in advance
kind regards

[Ghostkeeper]

I can't since I'm working on Linux and my CuraEngine wouldn't run on your computer. But @konskarm or @rburema might.

Am I right, assuming that it will work, if I just put the latest CuraEngine.exe into the latest Cura 4.11 installation folder?

Not out of the box, since Arachne also introduced new settings. You'll also need to install the updated settings list, this file: https://github.com/Ultimaker/Cura/blob/libArachne_rebased/resources/definitions/fdmprinter.def.json

If you install that into the 4.11 installation folder too, I expect it'd work. No guarantees.

[discip]

Good afternoon @konskarm & @rburema,
my I dare to ask, if you would provide the CuraEngine.exe?

@Ghostkeeper
Thanks a lot, I will try as soon as I am able to. 😁

[KoenVanduffel]

I have been using the Arachme engine since April as my main slicer and apart for a few quirks (mainly in bridge settings the slicer locks up sometimes) I am very happy with the variable line width results. I have a few examples where Cura 4.9 and 4.10 make mistakes which Arachme surely doesn't. The main Cura has moved on and attracted a few nice features as well so I am drawn between both.

Is the Arachme engine going to be integrated in the newer Cura versions any time soon or the new things like surface settings going to be ported to the Arachme engine?

[Rijaspb]

https://www.rijasexports.com/

[Anisotropic]

Hi. Any updates on the new public Arachne engine version?

[rburema]

We're aiming for within the next 2 weeks, probably close to (but definitely after) the 4.12-beta.

So please don't confuse those two ;-)

[rburema]

The new BETA that is, whatever we end up calling it (probably beta-2 or some such). Merge with a mainline version is planned for the first half of 2022 currently.

[yhira1023]

I am very much looking forward to next version!

[Micke-71]

I tried Arachne for the first time with a print of a threaded cap for a coolant can. Bottom 5mm was a charm. But after that it is a 5mm cylindrical tubing before threads start.

The slice looks nice all the way. But from silky smooth circular movements the printer start stuttering badly and the print quality went down badly.

A solid cylinder prints nice. A walled cylinder (tube) with same line width is stuttering and the threaded part with variable line width is also stuttering.

The solid bottom moved smooth in 200mm/s but the problem area was stuttering even with 35mm/s

The confusing part is before the thread begins. Both the solid bottom and the “tube” is making exactly same movement except the line bottom layer. I can’t understand why it should start stuttering so badly.

12 cylindrical lines, those first 25 layers with bottom pattern is running smooth. Next 25 layers with same cylindrical but without the bottom pattern….. ???

[rburema]

Is there anything visible in the preview? It might be that it's alternating between n and n+1 walls higher up, due to cylinders never resulting in true circles, or even the same approximate polygons, because of the nature of triangle-meshes.

[Ghostkeeper]

Maybe it's hitting the limit of processing speed for the printer? If you step through the horizontal progress bar in layer view, does it make smaller steps in the part that was stuttering?

[CCS86]

Maybe it's hitting the limit of processing speed for the printer? If you step through the horizontal progress bar in layer view, does it make smaller steps in the part that was stuttering?

It seems unlikely at the 35mm/s he describes. The issue I reported a while back, seems more likely: #8321

[BagelOrb]

Segments per segment is separate from mm per second. Irrespective of the speed, the number of segments may be too high.

[jszymon]

You may want to try arcwelder plugin. It will replace small segments with longer arcs.

[CCS86]

Of course it is still possible to exceed a controllers segments/sec at lower print speeds, it is just a lot less likely. They are not completely "separate" as you say. They are directly related. You would need a pretty incredible segment density to exceed a controller queue at 35 mm/s. Path discontinuities, like I reported in the linked issue I submitted can easily cause slowdowns, even at slow speeds.

…

On Thu, Oct 21, 2021, 11:18 AM Tim Kuipers ***@***.***> wrote: Segments per segment is separate from mm per second. Irrespective of the speed, the number of segments may be too high. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9388 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC64756CR7GTT3QBI764243UIA4NLANCNFSM4ZB3IVDQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[BagelOrb]

Spiralize outer contour produces 100% dense parts for me O_O


arachne_spiralize_problem.3mf.renamed.zip

[BagelOrb]

Probably related to some of the other settings which were also changed, like the wall line widths. Very weird tho.

[Vandresc]

Yes, it is a known issue, we have a ticket on our backlog.

[BagelOrb]

Spiralize has all-round problems - as listed at the top of this thread:

Spiralize could generate both inner and outer surfaces.
Bottom layers of a spiralized model with surface mode enabled, looks like inner walls.
Last bottom layer might disappear for a spiralized model.
Stringing when spiralized is enabled

However, I thought this one was not listed, so I just put it here as well...

[Nitrofpv]

Hi guys

Could it be that the "Flow Rate Compensation" option is very bad for a printer with a Klipper with perfectly coordinated "Pressure advance"?
How do I turn this off at Cura?
What else should you watch out for with the use of Klippers?

[BagelOrb]

What I did to test the backpressure compensation was print a gcode width varying line widths. The variable width is achieved by splitting the varying width segments up into small pieces up to a resolution which the firmware can still handle.
Then print a grid of these prints with varying setings for the backpressure compensation. (Note that the bed leveling has to be supremely good)
Compare a scan of these with the intended line widths to see which backpressure compensation setting is best.
A similar procedure could be adapted for backpressure compensation in Klipper.

However, this would only test the required backpressure compensation for one speed value. It's unclear whether the same backpressure compensation value would also hold for other speeds, or in general how the interaction between width-based pressure and speed-based pressure relate to each other. Intuitively, a line of twice the nozzle size is hindered by back pressure more at higher speeds than at lower speeds.

I don't totally get how disabling flow equalization solves the problem.

It doesn't, but I don't see how enabling flow equalization would help either. Any benefit of flow equalization is totally counteracted by linear advance. The extra flow equalization above 100% would only result in extra linear advance; Cura can't use the speeds to control the flow rates. Having flow equalization disabled should be the baseline, so we should keep it turned off for firmwares with linear advance.

[Nitrofpv]

A line test is a good idea.
For a line test, however, I don't like printing directly on the bed.
Variant 1: Test on a continuously smoothed surface.
(Although I don't know if and how this works with Cura, see pictures)
Variant 2: For many tests, I prefer a wall thickness using the vase mode.
As a result, I see and feel the connection between many other parameters (see picture).

[BagelOrb]

I don't know what vase mode has to do with it. Perhaps you can get ironing to work under some line line test by making those separate objects.

[Nitrofpv]

I am trying to draw a wall (possibly spiraling) in which the whole range of line widths comes to light.
I would like to print this up in order to test the variable flow and to adjust measurements and parameters.
I drew two wedges (0 - 2mm and 0.4 - 0.6mm)
However, only 3 different line widths are output for the large wedge and 1 line width for the narrow wedge.
I'm doing something wrong.
See 3D files and images.

Linie_Variabel_2.zip

[Ghostkeeper]

However, only 3 different line widths are output for the large wedge and 1 line width for the narrow wedge.
I'm doing something wrong.

No, this was actually an open bug (or feature gap maybe) at the time of release. I fixed that 9 days ago in Ultimaker/CuraEngine#1548.

[Nitrofpv]

Hi guys
I can no longer find the setting (Arachne engine beta2) so that the first layer of a bridge runs parallel, see Figure 1.
Has this attitude disappeared, or do I have Alzheimer's disease and no longer know where it is?
I only find settings like in picture 2.

[Ghostkeeper]

There's a separate thread for beta 2, by the way.

The setting you're looking for is called Enable Bridge Settings, or "Brückeneinstellungen aktivieren" in German. Pay attention in particular to the Bridge Skin Support Threshold setting as well ("Schwellenwert Stützstruktur Brücken-Außenhaut") to determine where bridging applies.

[Valiance]

I recently came into a use for gears. Plastic was fine, PLA even. I thought to myself... I bet I could print these. Well, I can. But, structural integrity is lacking due to the way the gears are sliced. It seems the 'normal' way to slice them leaves an easily fracturable fault point in the outer lines of the gear. I asked myself, can we make these outer lines vertical? Like spokes in a wheel so the teeth have more integrity in the long run. Can Arachne do this?

[rburema]

Hi! This is an old thread. What we called 'Arachne' has been the standard way of slicing things in Cura since 5.0.0

Please make a feature-request if there's something you feel is missing in Cura.