DBMandrake

Thanks for explaining what's happening. Personally I would still class it as a bug - why have profile settings to set the 1st layer speeds (which should be maximum speeds) if they are just going to be ignored by another setting and be greatly exceeded ? Anyone trying to troubleshoot this issue is going to look at their first layer speeds being set to for example 35 but see the printer is printing at more than twice that speed and consider it to be a bug. Like you I don't like the sound of the compromise of disabling flow equalisation so I'm probably just going to stay with 5.4 for now until I hear something more about this issue. Maybe I'll check back in another couple of versions to see if the issue is still there...

You're assuming that gradient is linear - with nothing to say one way or the other I would not make that assumption. Watching the printer print it is a lot faster than 67mm/sec I can say. No, I have not changed flow equalisation ratio - I've reverted to 5.4.0 using identical profiles and overrides and the problem is resolved. Flow equalisation ratio is set to the default of 100% in both cases. Edit: Forgot to note - I'm printing using Klipper, and Klipperscreen dynamically reports the movement speed was around 80-120mm/sec during extrusion of the first layer lines indicated in green which should have been extruded at no more than 35mm/sec according to settings in the profile. I can't see how this is anything other than a bug where the initial layer speed settings in the profile are not being honoured.

Ok I tried updating to 5.6.0 - no improvement. I then migrated my 5.5.0 configurations and profiles manually back into my 5.4.0 installation which was still there, and the problem is resolved: First layer line speeds are all blue so around 35mm/sec, using the exact same profiles and overrides. This definitely seems to be a bug or change introduced in 5.5.0 and would explain some difficulties I've had recently with prints with fine details on the first layer - some of the first layer lines are being printed as much as 3 to 4 times too fast. I've attached the 3mf file exported from Cura 5.4.0 below, hopefully someone can compare this to the previous 3mf file exported from 5.5.0 to help figure out this problem as it looks like I'll be staying on 5.4.0 for now. SSPK_christmas-5.4.0.3mf

Same problem here with Cura 5.5.0. Overall print speed is set to 200mm/s, initial layer print speed is set to 35mm/s in the profile however some of the lines in the first layer are printing at well over 100mm/s and as a result are not sticking to the bed, with the filament being dragged across the bed causing corner cuts and blobbing. It can be seen in the print speed view as well, below: The blue lines are at the correct speed, the green lines are much much faster, to the eye when printing it looks like maybe 100mm/sec or so. I am going to try updating to 5.6.0, if that doesn't help reverting to 5.4.0 as I see someone in the thread reports they don't have this issue in 5.4.0 and I only fairly recently went from 5.4.0 to 5.5.0 myself. SSPK_christmas.3mf

Hi, I'm quite new to 3d Printing myself but I have a Weefun Tina2 (which is a rebadged Weedo Tina2) and mine came with the following software on SD card: Wiibuilder 2.1.6.0 Cura 4.10.0 The version of Cura 4.10.0 seems to be customised to include definitions for this printer which don't exist in a vanilla install of Cura. While the provided version of Cura seems to work fine, I wanted to try the Arachne engine on later versions. I was able to successfully transfer the definitions over to a fresh installation of Cura 5.2.1 and for the most part it seems to work OK, however some of the default profiles differ a little as well - for example the profiles provided in their version of Cura 4.10.0 specify a first layer temperature of 215C and remaining layers 200C, while the defaults in 5.2.1 have 200C for both. I'm not sure which files in their default install define this or whether it would be appropriate to overwrite the profile files in the new version anyway, so I just changed it manually and saved it in my own custom profiles. I've attached (hopefully) a zip file with the definitions - I've included all the Weedo related files including other Weedo models as I don't know for sure how many of them are needed. In the zip file files within the definitions folder should be copied to C:\Program Files\Ultimaker Cura 5.2.1\share\cura\resources\definitions and files in the extruders folder copied to C:\Program Files\Ultimaker Cura 5.2.1\share\cura\resources\extruders. (or equivalent if you're installed to a different location) In both cases, if any file already exists I'd suggest saying no to replacing it. In my case one of the files for the Weedo x40 already existed so I chose not to replace it. (I don't have that printer anyway) I am currently successfully slicing using Cura 5.2.1, I then save the generated gcode to disk and use the provided Wiibuilder app only to upload the file over WiFi. (just open the gcode file and then go directly to uploading it) This needs an SD card in the printer to work as it just seems to upload it to the SD card then print it from there. I have found the Weedo provided G-code start and stop files are somewhat "sub-optimal" - in particular after the automatic bed levelling is done it leaves the extruder over the middle of the print area while it heats up to full temperature so any leakage as the extruder heats up can end up landing in the middle of the print area, so I find I sometimes have to quickly grab the leakage and pull it from the tip shortly before the target temperature is reached. I spent quite a while modifying the start g-code trying to work around this - I changed it to bring the nozzle to the front left so that any leakage would come down just off the corner of the build plate, and then to come down and draw a horizontal line from left to right at the front edge of the plate to "wipe" the nozzle clean. This actually worked quite well but I ran into bugs (?) with the g-code processing in the printer where on specific files it sometimes ignores the M109 S215 command and starts trying to print at the 150C pre-heat, and also skips some of the moves immediately after the M109 command. I've spent quite a few hours debugging this problem and my conclusion is the M109 command is buggy and does not always function properly depending on which commands follow it later in the print job... so I have gone back to the original simpler start G-code provided by Weedo which doesn't seem to trigger this bug. I've also noticed bugs in the handling of the end G-code - even with the default one provided, depending on the specific print job the printing will sometimes just end abruptly without turning the heating element off, returning the extruder to the home position and sliding the bed to the front as it should - if you don't catch this and manually home the extruder soon after it stops you'll end up with a big lump on the top of your print that you'll have to slice off. Annoying. Maybe someone who is a whiz with g-code can have a look at my custom g-code vs the provided code in another thread and work out why some of my modifications don't always work... (one trigger seems to be if the 150C preheat set by M104 is already reached before the M109 S215 command is executed, M109 and some of the following commands are skipped entirely) Weedo Cura Definitions.zip