Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.7.0] Glitch Causing Slowdowns in Circular Perimeters #8321

Closed
CCS86 opened this issue Sep 4, 2020 · 223 comments
Closed

[4.7.0] Glitch Causing Slowdowns in Circular Perimeters #8321

CCS86 opened this issue Sep 4, 2020 · 223 comments
Labels
Type: Bug The code does not produce the intended behavior.

Comments

@CCS86
Copy link

CCS86 commented Sep 4, 2020

4.7.0
Win 10

The slicing engine seems to be struggling with circular perimeters. 99% of the code is fine, but there are random slowdowns during printing at 70 mm/s on a Duet Maestro, which should have plenty of horsepower.

I first noticed these random artifacts (typical slow down bulges) in a print. So, I ran the gcode through gcodeanalyzer and it is actually showing these areas:

image

I saved the project file: Slowdown.3mf.txt

Then I loaded that project into 4.6.2, saved the gcode, and ran through the analyzer. It also shows some of these slowdown areas (and some oddly long ones), but scanning through all the code, there are FAR fewer of them. Here is the same layer in 4.6.2:

image

I tried many combinations of 'maximum resolution' and 'maximum deviation', and interestingly with 4.6.2, bringing maximum resolution down to 0.1mm eliminated most of these spots. The behavior in 4.7.0 is not the same, and it saw no improvement.

Here are the gcode files:
4.6.2.gcode.txt
4.7.0.gcode.txt

@CCS86 CCS86 added the Type: Bug The code does not produce the intended behavior. label Sep 4, 2020
@CCS86
Copy link
Author

CCS86 commented Sep 4, 2020

image

@swademc95
Copy link

swademc95 commented Sep 5, 2020

I have this issue as well. Only noticed after upgrading to 4.7.0. Even in places where the curve appears smooth, the printer jitters around the contours causing a significant reduction in speed and a lot of vibration. Only the inner walls seem to be affected.
Nice-ish Wall
Weird Wall 2
Weird Wall

@CCS86
Copy link
Author

CCS86 commented Sep 5, 2020

Wow, those are some big discontinuities!

@CCS86
Copy link
Author

CCS86 commented Sep 5, 2020

I know this is off-topic from the original issue here, but if you guys are rewriting this portion of the code, is there anything that can be done about this tendancy?

image

When the model has small holes, and you use a relatively large number of perimeters, each perimeter becomes progressively lower resolution. I can see that it it simply doing offsets on the inner perimeter, and it may be much more complicated to maintain the same segment length, while moving outwards.

Let me know if I should make this request via a new issue.

@dominik59
Copy link

dominik59 commented Sep 6, 2020

I have got the same problem.
I have reflashed firmware, change junction deviation to jerk and so on and have not noticed improvement. When i tried IdeaMaker problem has dissapeared.
IMG_20200906_150121__01
Green tickc are pointing model printed with previous cura version (4.6.2), red arrows are pointing models printed with newest software.

P.S. Cura 4.7.0 stable, Linux Mint 20

@ClockeNessMnstr
Copy link

ClockeNessMnstr commented Sep 6, 2020

Yep, CURA can't slice curves? I thought I was going crazy.

Here it is at 30mm/s target (print speed = 30, speed setting = 60...)

BROKEN_CURA_BENCHY

Here it is at 60mm/s target.

BROKEN_CURA_BENCHY_60

actual print. I forget the settings for this but the speed was at least 60mm/s, possibly set higher.
There could be two issues here. The lines you see running up the bow primarily in the z-axis do not show up based on infill, rather appear differently based on speed? looks like some sort of ghosting of the front of the bow but you can see the printer changing speed and causing the pattern.
The rough texture looks to match the gcode issues in different layers of the shell.

MVIMG_20200906_130453-01

@louisferreira
Copy link

louisferreira commented Sep 6, 2020

So I installed 4.7.0 along side 4.6.2 and set both instances to be exactly the same on all settings using CHEPS 0.2 profile, and I noticed a big difference in the prints. Firstly the GCode for 4.7 was twice the size of 4.6. And the print quality was distinctly different as shown - 4.6 on the left (2hr 2min), 4.7 on the right (2hrs 35min). There was also a noticeable difference in the sound the steppers made... 4.7 seemed to jitter a lot more round curves, whilst 4.6 seemed to be smoother in the same places.
So for now, I'm sticking to 4.6.2 until 4.7.x can do at least the same output as 4.6.2
I'd be interested to see if anyone else can do the same test and get similar results on their printer.
Hardware:
Ender 5+
Stock board + firmware
Capri bowden
metal extruder
Luke's hot end fix
Octoprint
Filament:
YOYI Silk PLA 1.75
benchys
GCode

@rburema
Copy link
Member

rburema commented Sep 6, 2020

Possibly caused by Ultimaker/CuraEngine#1214 and the related #7385

Depending on whether you're using stock profiles or external ones, please try 4.7.0 with the 'Maximum Deviation' set to half that of 4.6.x -- If this happens with stock profiles that come with Cura, there's something quite wrong. Otherwise the setting should be changed.

@swademc95
Copy link

swademc95 commented Sep 6, 2020

Deviation settings was the first place I went after noticing the stuttering and slowdown. Thoroughly testing those settings through a range of values did not improve results once I was looking in the right place (at the plotted g-code)

@jellespijker
Copy link
Member

jellespijker commented Sep 6, 2020

@rburema #7385 is in my mind the likely cull-print compared to the simplify function executed on a circle

@rburema
Copy link
Member

rburema commented Sep 6, 2020

@swademc95 Thanks for the reply. This is bad news :-/

@jellespijker Yes, that's the second PR I mention in my comment (because they are related, and from the same JIRA ticket: CURA-7282). So I'm a bit confused: Are you agreeing or did you mean another PR?

@jellespijker
Copy link
Member

jellespijker commented Sep 6, 2020

@rburema I should have done more then hoover over the link. Once again I agree with you completely. I meant an other ticket but I can't remember the number and title anymore. I gonna look into it tomorrow.

Curious why it wasn't caught with the statistics that we run on the build server over certain models, especially the increase in file size as @louisferreira mentioned.

Time to double the effort for in GHermeneus toolbox ;-)

@swademc95
Copy link

swademc95 commented Sep 6, 2020

Top surface layers also seem to be affected. Here is a comparison of the same part, same settings in 4.6.2 vs 4.7.0. In 4.7.0 there are strange pointy artifacts.
image
image

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Sep 7, 2020

When the model has small holes, and you use a relatively large number of perimeters, each perimeter becomes progressively lower resolution. I can see that it it simply doing offsets on the inner perimeter, and it may be much more complicated to maintain the same segment length, while moving outwards.

Even if the original circle was higher resolution, you wouldn't want it to do anything about it, because that would cause the vertices of the approximated circle to misalign, causing the surrounding wall to overlap the lower-resolution wall in some places, and to leave gaps in other places.

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Sep 7, 2020

Does anyone have a project file that reproduces the pointy corners? I'm not seeing them.
image

I do see the problems when slicing Benchy though. It's not caused by the Wall Overlap Compensation. Looks like it's creating micron-length line segments:

G1 X135.471 Y100.024 E904.85643
G1 X135.863 Y100.367 E904.85888
G1 X135.864 Y100.366 E904.85889  ; 1.4um line segment!
G1 X136.229 Y100.7 E904.86122
G1 X136.228 Y100.701 E904.86122
G1 X136.601 Y101.055 E904.86364
G1 X136.602 Y101.054 E904.86365  ; 1.4um line segment!
G1 X136.961 Y101.408 E904.86602

@nallath
Copy link
Member

nallath commented Sep 8, 2020

@swademc95 Could you share the project file that causes those issues for you? It would help us a lot to debug / fix this issue.

@KalCorp
Copy link

KalCorp commented Sep 8, 2020

Note: I have same issue with 4.7/4.7.1 and 4.6.2 is ok. New Ender 5 Plus

@Zogar89
Copy link

Zogar89 commented Sep 9, 2020

I also experienced freeze issues with the new version. I have solved it by putting the following settings in the resolution:
Maximum Resolution 0.5mm, Maximum Travel Resolution 1.6mm, Maximum Deviation 0.3.
Much higher values than in version 4.6 but now I can print the circles much faster without stopping and the curves are still smooth!
Artillery x1, 8 bit board Mks Gen L clone. 50mm/s exterior perimeters. Host by Repetier Server.

@dominik59
Copy link

dominik59 commented Sep 9, 2020

@Zogar89 Unfortunately your suggestion solves one problem but unfortunately introduce another one. I have printed benchy model using 4.7.1 cura with your settings, but details are now gone. I have also noticed that 4.7.1 cura do something strange with the seam. On the first picture i marked side of doors which looks scattered, but 4.6.2 version of cura have printed that without problems. P.S. I have set manual seam position to (0x,0y - Left front) in both models. I have also noticed that with your settings some small cracks appeared at front bottom side of benchy (hull). Anyway thanks for your advice.

IMG_20200909_134835__01
IMG_20200909_135024__01
IMG_20200909_134811__01

@skarasov
Copy link

skarasov commented Sep 9, 2020

123
With CompensateWallOverlap - little gaps appears.

stl2.zip

@jakeface1
Copy link

jakeface1 commented Sep 10, 2020

I'm having the exact same issue, benchy's all have artifacts on the front of the print, any straight line is fine. I spent about 2 days trying to fix this problem. Luckily I found this linked from reddit.

@nallath
Copy link
Member

nallath commented Sep 10, 2020

I've wrote a quick script to check the number of line segments that are below a certain length.

As per the g-codes provided by @CCS86

4.7.0

Line length Num segments
1 92578
0.5 33291
0.1 5472
0.05 2219
0.01 727
0.005 611
0.001 32

4.6.2

Line length Num segments
1 56244
0.5 5669
0.1 685
0.05 32
0.01 32
0.005 32
0.001 32

4.7 with overlap compensation

Line length Num segments
1 105925
0.5 45219
0.1 12877
0.05 8717
0.01 768
0.005 616
0.001 33

So there is quite a lot going on in the much smaller lines. 4.6.2 only had 32 line segments below 0.05, whereas 4.7.0 has 2219 line segments below 0.05.

The overlap compensation is making the problem a slight bit worse, but I think it should be considered a seperate issue (it could very well be that it's just amplifying the original issue)

@nallath
Copy link
Member

nallath commented Sep 10, 2020

Okay, I think I've found the solution here. It's still pending what the other developers think of it, but it fixes it for the cases that I've tested it.

Could we interest some people in testing this fix once it's reviewed?

@dominik59
Copy link

dominik59 commented Sep 10, 2020

@nallath Sure

uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Nov 20, 2020
In Cura version 4.7 a bug regarding slowdowns in circular perimeters was
introduced (or at list gets triggered much more easily than in earlier
versions):
Ultimaker/Cura#8321

This issue makes v4.7.x hardly usable.
Sticking to v4.5 has become quite "tricky" to say the least, due to
the massive python-induced dependency hell and lots of dependencies
being too new and/or incompatible for the 4.5 version.

Version 4.8 has been released on November 10 that fixes this glitch in
the simplification algorithm. The issue is still open, but is considered
to be solved with 4.8 and changed default settings for Maximum resolution
and Maximum Deviation.

From the Changelog of 4.8:
Fixed under-simplification (blobs, zits) on some printer models. An oversight
in 4.6.x resulted in an oversimplification (smoothing) of models.
The attempted fix in 4.7.x overcompensated, which gave difficulty
(zits, blobs) for some printer models when the resulting gcode became
too intricate. This is now fixed, though some profiles might need
to be updated, since they where made against 4.6.x, and therefore may
rely on the over-simplification.

PR:			ports/251236
Submitted by:		Sebastian <sko@rostwald.de>


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@555795 35697150-7ecd-e111-bb59-0022644237b5
uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Nov 20, 2020
In Cura version 4.7 a bug regarding slowdowns in circular perimeters was
introduced (or at list gets triggered much more easily than in earlier
versions):
Ultimaker/Cura#8321

This issue makes v4.7.x hardly usable.
Sticking to v4.5 has become quite "tricky" to say the least, due to
the massive python-induced dependency hell and lots of dependencies
being too new and/or incompatible for the 4.5 version.

Version 4.8 has been released on November 10 that fixes this glitch in
the simplification algorithm. The issue is still open, but is considered
to be solved with 4.8 and changed default settings for Maximum resolution
and Maximum Deviation.

From the Changelog of 4.8:
Fixed under-simplification (blobs, zits) on some printer models. An oversight
in 4.6.x resulted in an oversimplification (smoothing) of models.
The attempted fix in 4.7.x overcompensated, which gave difficulty
(zits, blobs) for some printer models when the resulting gcode became
too intricate. This is now fixed, though some profiles might need
to be updated, since they where made against 4.6.x, and therefore may
rely on the over-simplification.

PR:			ports/251236
Submitted by:		Sebastian <sko@rostwald.de>
Jehops pushed a commit to Jehops/freebsd-ports-legacy that referenced this issue Nov 21, 2020
In Cura version 4.7 a bug regarding slowdowns in circular perimeters was
introduced (or at list gets triggered much more easily than in earlier
versions):
Ultimaker/Cura#8321

This issue makes v4.7.x hardly usable.
Sticking to v4.5 has become quite "tricky" to say the least, due to
the massive python-induced dependency hell and lots of dependencies
being too new and/or incompatible for the 4.5 version.

Version 4.8 has been released on November 10 that fixes this glitch in
the simplification algorithm. The issue is still open, but is considered
to be solved with 4.8 and changed default settings for Maximum resolution
and Maximum Deviation.

From the Changelog of 4.8:
Fixed under-simplification (blobs, zits) on some printer models. An oversight
in 4.6.x resulted in an oversimplification (smoothing) of models.
The attempted fix in 4.7.x overcompensated, which gave difficulty
(zits, blobs) for some printer models when the resulting gcode became
too intricate. This is now fixed, though some profiles might need
to be updated, since they where made against 4.6.x, and therefore may
rely on the over-simplification.

PR:			ports/251236
Submitted by:		Sebastian <sko@rostwald.de>


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@555795 35697150-7ecd-e111-bb59-0022644237b5
@bill-orange
Copy link

bill-orange commented Nov 22, 2020

I was concerned about loss of detail with version 4.8 with the Mesh Fixes settings that appear to be commonly used. It appears I have nothing to fear. This test print has 3 mm threads. It was printed with a Tronxy X3A fitted with an generic Ender3 hot end (0.4 mm nozzle). Layer height was 0.06mm at 40 mm/sec. Max. resolution was 0.25 mm. Max Deviation was 0.025. These setting appear pretty good for "Ender3-like" machines.

IMG_0247

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Nov 26, 2020

We currently consider this to be fixed. We've heard good things from Creality users on here and Reddit. I think if there are new issues (and not just "I'm getting blips, Cura must be wrong") then we're better off analysing those with clear reproduction steps in a new issue. The original problems in this issue have been resolved.

@tablatronix
Copy link

tablatronix commented Nov 26, 2020

related #6676 ?

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Nov 26, 2020

Somewhat related because they are both buffer underruns. The symptom is the same and the fix for this can cause the problem to disappear there.

@swademc95
Copy link

swademc95 commented Mar 25, 2021

PXL_20210325_091047364
PXL_20210325_091112812
Fusion 360 slicer vs Cura 4.8 with similar settings derived from default profiles. At this point I give up on Cura altogether. This problem is still not fixed.

@nallath
Copy link
Member

nallath commented Mar 25, 2021

@swademc95 Well, you never did share that project file where you had this issue, so we've been unable to check what is causing it in your case. Since all other users did report that the issue was resolved, we closed it.

If you could share the project file we can have a look at it and figure out what is different about your case.

Also note that it's almost impossible to have "similar" settings between slicers. The underlying algorithms are simply too different for there to be any meaningful way to have the same settings.

@swademc95
Copy link

swademc95 commented Mar 27, 2021

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.

Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.

I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.

This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.

image

@colatuttorf
Copy link

colatuttorf commented Mar 27, 2021

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.

Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.

I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.

This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.

image

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

@swademc95
Copy link

swademc95 commented Mar 28, 2021

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.
Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.
I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.
This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.
image

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

I have been advised that the Cura Arachne engine beta is meant to resolve this issue. I will test that soon.

@nallath
Copy link
Member

nallath commented Mar 29, 2021

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

It is a different issue and one that is also very hard to solve. We actually had to re-write large parts of the slicing algorithm to fix it, which resulted in the Arachne Beta that is currently available. It's not completely done just yet, but we can always use more people testing it!

@CCS86
Copy link
Author

CCS86 commented Apr 7, 2021

This issue is much improved, but still not solved, unfortunately. I have repeated it in both 4.8 and 4.9 beta

https://www.gcodeanalyser.com/ does a great job of predicting these discontinuities:

image

I went hunting for these areas in Cura's own preview, and found them. They are indeed print moves, which are an order of magnitude smaller than the normal moves. They also appear to be non-continuous with the rest of the path. Even Cura preview shows a significant direction change induced by these moves, which explains why they cause the printer to slow down:

Cura-Discontinuity.mp4
Cura-Discontinuity2.mp4

O-ring coupler.3mf.zip
O-ring coupler 4.8.gcode.zip

@tablatronix
Copy link

tablatronix commented Apr 7, 2021

I export from fusion and have to make sure any discretized cylinder polys are symmetrical or else I have this issue. Seems to be hit or miss how 3 walls get sliced, but its not random.

@CCS86
Copy link
Author

CCS86 commented Apr 8, 2021

I export from fusion and have to make sure any discretized cylinder polys are symmetrical or else I have this issue. Seems to be hit or miss how 3 walls get sliced, but its not random.

I don't doubt that STL composition plays into this, at least sometimes. It's such a messy format, with a lot of variance between how different software translates them in and out.

In some cases, I see these slowdowns appear to start on an exterior surface, and get propagated inwards. But other times, the outer wall looks fine, and slowdowns only occur on deeper inner walls.

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Apr 13, 2021

Even if the STL contains tiny triangles (or just normal triangles but with a sharp tip), Cura is expected to filter out such tiny movements as long as it's allowed by the Maximum Resolution and Maximum Deviation settings. That is, it should filter out segments smaller than the Maximum Resolution, unless that causes the path to deviate further than the Maximum Deviation.

@kiler129
Copy link

kiler129 commented Oct 7, 2021

I don't think this issue should be solved - the newest version of Cura as of today (v4.11.0) still suffers from these artifacts. I tried to slice the standard dual-color benchy and I've got this:
Screen Shot 2021-10-07 at 6 39 42 PM
Screen Shot 2021-10-07 at 6 41 48 PM

Project file attached.
TLD_3DBenchy_-Dualprint-Hull_Box_Bridge_walls_Rod-holder_Chimney_v02-_3DBenchy.com.3mf.gz

@nallath
Copy link
Member

nallath commented Oct 8, 2021

@kiler129 Try setting your "merged meshes overlap" to 0

@Ghostkeeper
Copy link
Collaborator

Ghostkeeper commented Oct 13, 2021

To quote myself from earlier:

I think if there are new issues [...] then we're better off analysing those with clear reproduction steps in a new issue. The original problems in this issue have been resolved.

@lfrlucas
Copy link

lfrlucas commented Jul 31, 2022

This issue is much improved, but still not solved, unfortunately. I have repeated it in both 4.8 and 4.9 beta

https://www.gcodeanalyser.com/ does a great job of predicting these discontinuities:

image

I went hunting for these areas in Cura's own preview, and found them. They are indeed print moves, which are an order of magnitude smaller than the normal moves. They also appear to be non-continuous with the rest of the path. Even Cura preview shows a significant direction change induced by these moves, which explains why they cause the printer to slow down:
Cura-Discontinuity.mp4
Cura-Discontinuity2.mp4

O-ring coupler.3mf.zip O-ring coupler 4.8.gcode.zip

I'm using cura 4.13.1 and I'm experiencing exactly the same issue show in these videos. Took me hours to understand the cause of the defects in the curved walls. After finding this github issue, I confirmed the root case through the G-code analyser and I could see the exact same change of direction in cura preview mode. Is there any setting that can be tuned to avoid this behaviour? I'm wondering why don't we have more people complaining about this issue. At least with klipper the consequence on the printed objects is well visible.

@richfelker
Copy link

richfelker commented Aug 1, 2022

I think this issue should be fixed in Cura 5 as a result of Ultimaker/CuraEngine#1677

@lfrlucas
Copy link

lfrlucas commented Aug 1, 2022

Unfortunately the last version available on Ubuntu app store is still 4.13. I can't test yet. I hope version 5 will solve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests