Cura 5.7.0 new update faulty

[IamPAllen2 0]

I installed Cura 5.7.0 today and when I tried to print the PLA was not sticking to the  bed plate. I have an Ender 3 V3 SE and it was working perfectly. Not it will not take any PLA on hte bed plate. I thought it was a settinbg on my printer so I done various bed and nozzle heat settings and also bed levellingh and Z off-set. I finally tried to print with Creality Print (even though I dont like it much) and the PLA was sticking to my bed plate. I thought hte update had something to do with it and I uninstalled 5.7.0 and reinstated 5.6.0 and I am back to printing. I have lost a fair bit of PLA with all of the failed prints from nopt sticking to the bed plate.

I like Cura because it helped me learn how to 3d print. 

[GregValiant 1,415]

Nothing really changed between 5.6 and 5.7 as far as what's happening on the first couple of layers.

Use 5.6 and load something small (calibration cube or a benchy) and set Cura up like you always do.

Use the "File | Save Project" command to create a special 3mf file.

Start 5.7 and open that 3mf file.  The settings from 5.6 will show up in 5.7.

There are a couple of plugins that can affect the first layer.  One is "Z Offset Plugin".

If a Creality owner submitted a change to the printer definition file and the ABL settings changed then your first layer height might be too tall and the extrusions aren't getting pressed down like they should.

 

I think @Slashee_the_Cow has a printer like that.  She may know what the possible problems are.

There are a lot of causes for what you have happening.  It's very unlikely that it's a problem in the Cura code.

 

You should probably create a second project file but from 5.7.0 and post that one here so there is something to work with.

[Slashee_the_Cow 493]

9 hours ago, GregValiant said:

I think @Slashee_the_Cow has a printer like that.

Like that? You should know me better by now. I have a printer that is exactly that.

 

...not that it necessarily helps here. I can print from Cura 5.7 fine. When a Cura version first runs, it copies the configuration folder from the most recent version. Although my situation may differ in that I use a custom machine definition file, not rely on the one included in Cura.

--- suggested fix be here ---

If it printed fine in 5.6, then install 5.7 if it isn't already (they install side by side fine), then go to the Cura configuration folder (in Cura go to Help > Show Configuration Folder) and then go up one folder so you're in the folder with all the different versions and delete the folder for 5.7.

 

Copy the printer's definition file from 5.6 - default location in Windows is C:\Program Files\UltiMaker Cura 5.6.0\share\cura\resources\definitions\creality_ender3v3se.def.json then go to the folder for 5.7 (just change the 6 in the folder name to a 7) and paste it over the definition file that came with 5.7.

 

If that doesn't work, come back and I'll start playing a bit more hardball.

 

--- technical complaining be here --- (you don't have to read this if you don't want but I know at least @GregValiant will be interested)

Turns out the definition has changed between 5.6 and 5.7:

I don't think I've ever seen a machine_head_with_fans_polygon definition of more than 4 points before. Looks like someone must have been trying to be very precise:

Although the change in the startup gcode is what I'm more worried about:

5.6:

M220 S100 ;Reset Feedrate
M221 S100 ;Reset Flowrate
G28 ;Home
M420 S1; Enable mesh leveling
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position
M109 S[material_print_temperature_layer_0]
G1 X10.1 Y145.0 Z0.28 F1500.0 E15 ;Draw the first line
G1 X10.4 Y145.0 Z0.28 F5000.0 ;Move to side a little
G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G92 E0  ;Reset Extruder
G1 E-1.0000 F1800 ;Retract a bit
G1 Z2.0 F3000 ;Move Z Axis up
G1 E0.0000 F1800

 

5.7:

M220 S100 ;Reset Feedrate
M221 S100 ;Reset Flowrate
G28 ;Home
M420 S1; Use saved mesh leveling data
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
G1 X-3 Y20 Z0.28 F5000.0 ;Move to start position
M190 S{material_bed_temperature_layer_0} ; Set bed temperature and wait
M109 S{material_print_temperature_layer_0} ; Set hotend temperature and wait
G1 X-3 Y100.0 Z0.28 F1500.0 E15 ;Draw the first line
G1 X-2 Y100.0 Z0.28 F5000.0 ;Move to side a little
G1 X-2 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G92 E0 ;Reset Extruder
G1 E-1.0000 F1800 ;Retract a bit
G1 Z2.0 F3000 ;Move Z Axis up
G1 E0.0000 F1800

 

It's a good thing I know Cura is so forgiving because otherwise I'd be amazed the code from 5.6 worked. How did either of these get approved?

• The code for 5.7 is telling it to move outside the build plate - for all I know how a Creality printer reacts to this could be the problem, especially since it's in moves which also have a Z value
• Someone's being naughty and using G1 for movement commands
• From 5.6: do replacement patterns work within square brackets and nobody told me or is it just a case of Cura being smart enough to prevent cold extrusion?
• From 5.6: they don't even try to heat the bed?!!?!!?!!?!?!?!?!?!???
• What's with the retraction then extrusion at the end, and why is it a magic number?
• Isn't it at least polite to make it clear you're using absolute positioning? Or if you're not, which would allow the negative X values, why are you wiping the nose next to the home position?
• 5.7 is really inefficient at heating. Wait until the bed is fully heated before you start heating the hot end?

[GregValiant 1,415]

@Slashee_the_Cow you go through more printers than anyone else.  I can't keep up.

 

With the Machine Depth and Width at 220 it might be able to get to a negative "X" location.  I can see someone trying to move the purge lines further to the left.  The 5.6 definition has the purge lines at X10 and that could interfere with large prints.

People submit pull requests to change printer definitions all the time.  UltiMaker can check some things regarding other manufacturers hardware but not all things (unless they bought one of every printer on the planet like Slashee does).

 

A definition change that includes someone's "personal preferences" is never a good idea because they are forcing that on the rest of the users.  Definitions should be generic and simply work.  If a user wants to customize it then that's their decision.  My own Startup Gcode is...complicated.  I doubt it's something that anyone else would want, but it works for me.

[jaysenodell 18]

On my e3s1p the default bed is 5mm shy of full all the way around. This x-3 may be intending to use that buffer to prime/purge while allowing full use of the configured space for printing? Problem is I’m smart enough to resize my bed to get all my space back so… that would be bad. 
 

only other thing I could imagine is if they set machine coordinates to offset 0 to the max size of the print. But I don’t see that. Or any transfer to an alternative coordinate workspace. 
 

Me thinks thou protest to much on the G0/G1 fiasco. While technically accurate the only real value is if you are setting travel speeds as a universal in G0 then not resetting speed with every move. Since cura insists on setting speed in every motion… I’m not sure it hurts anything other than our desire for adherence to the rules. All said, I agree. Cura output should FOLLOW THE RULES! 

Edited April 13 by jaysenodell

[GregValiant 1,415]

Ah, but the "Startup G-Code" isn't Cura output but rather someone's hand coded lines.

 

Cura always puts Z-hops in as G1 lines even though there is no E parameter.  Maybe because they are part of the Retraction settings.  Still, without an E parameter it seems that they should be G0 lines.  Off the top of my head that's the only instance I can think of where the "guideline" isn't followed.

 

"The code is more what you'd call ‘guidelines’ than actual rules." - Capt. Barbossa, Pirates of the Carribean

[Slashee_the_Cow 493]

1 hour ago, jaysenodell said:

On my e3s1p the default bed is 5mm shy of full all the way around. This x-3 may be intending to use that buffer to prime/purge while allowing full use of the configured space for printing? Problem is I’m smart enough to resize my bed to get all my space back so… that would be bad. 

Also true of the Ender-3 V1 and V2, except I think it's more like 10mm. The V3's plate has the room, but has physical blockers installed to prevent it being moved to those areas. Methinks Creality got sick of people not buying bigger, more expensive printers.

 

Regardless, the printer is likely to either ignore a command that goes outside the space it knows it has or just go as far left as it can go (0). Given my experiments with Z movements trying (and failing) to settle a discussion about whether it's a problem if a "Move Z Up When Done" script which uses relative positioning which would end up above the actual print height and therefore be bad, the E3V3SE will just to move to its endstop on that axis. In this case that would make it wipe its nose at X0 both times which is probably not great trying to extrude at the same height down something you've already done.

 

1 hour ago, GregValiant said:

@Slashee_the_Cow you go through more printers than anyone else.  I can't keep up.

It's not that many. I only managed to kill three printers in five months (none my fault) and then this one has been going for a little under 4 months now. And it's not really that hard: the first one was an Ender-3 V2 Neo. The last three (including this one) were/are Ender-3 V3 SE's.

 

1 hour ago, jaysenodell said:

While technically accurate the only real value is if you are setting travel speeds as a universal in G0 then not resetting speed with every move. Since cura insists on setting speed in every motion

No it doesn't. As a general rule, at least in my experience, only the first line where it starts a section it moves at a different speed (like a travel, or the print after the travel) has a feed rate value.

 

2 hours ago, GregValiant said:

My own Startup Gcode is...complicated.  I doubt it's something that anyone else would want, but it works for me.

Well I don't want it because you don't have the same printer as me. I doubt any other E3V3SE owner would want my startup gcode though.

 

2 hours ago, jaysenodell said:

only other thing I could imagine is if they set machine coordinates to offset 0 to the max size of the print. But I don’t see that. Or any transfer to an alternative coordinate workspace. 

Or any coordinate system being specified. Just because it uses absolute coordinates by default doesn't mean it's not nice to throw a G90 in the startup gcode to make it clear. Or fix it if someone manages to mess up their firmware and set it to relative by default.

 

2 hours ago, GregValiant said:

UltiMaker can check some things regarding other manufacturers hardware but not all things (unless they bought one of every printer on the planet like Slashee does).

If I had one of every printer on the planet, do you really think I'd be using an E3V3SE?

[Slashee_the_Cow 493]

I just remembered something. The print bed that comes with the E3V3SE literally has a line on it indicating where the nose wipe should be:

That line starts after the diagonal bit (it's the straight bit with the nose wipe symbol at the end). It starts at X0 Y20.

[IamPAllen2 0]

On 4/12/2024 at 6:52 PM, GregValiant said:

Nothing really changed between 5.6 and 5.7 as far as what's happening on the first couple of layers.

Use 5.6 and load something small (calibration cube or a benchy) and set Cura up like you always do.

Use the "File | Save Project" command to create a special 3mf file.

Start 5.7 and open that 3mf file.  The settings from 5.6 will show up in 5.7.

There are a couple of plugins that can affect the first layer.  One is "Z Offset Plugin".

If a Creality owner submitted a change to the printer definition file and the ABL settings changed then your first layer height might be too tall and the extrusions aren't getting pressed down like they should.

 

I think @Slashee_the_Cow has a printer like that.  She may know what the possible problems are.

There are a lot of causes for what you have happening.  It's very unlikely that it's a problem in the Cura code.

 

You should probably create a second project file but from 5.7.0 and post that one here so there is something to work with.

I uninstalled v5.7.0 and tried 5.6.0 and it is not doing as good as it was. I have done a z reset and it still doesn't print properly. Since 5.7.0 screwed something up, even 5.6.0 isn't making it better. Things I try to print either does not stick to the bed or if it does manage to start to stick, it doesn't last long before it gets caught up in the hot end and just makes a mess.. The top wipe and first strip and top clean work great as it should. The rest is not and miss. I have uninstalled 5.6.0 and reinstalled it and it still happens. I am thinking I have to flash the printer firmware to reset the printer. Nothing went wrong before 5.7.0 was installed on my laptop. 

[Slashee_the_Cow 493]

1 hour ago, IamPAllen2 said:

I am thinking I have to flash the printer firmware to reset the printer. Nothing went wrong before 5.7.0 was installed on my laptop. 

Try doing a factory reset of all the settings from the printer's control panel first.

 

Also try cleaning your print bed (can't hurt): I just spray it with some isopropyl alcohol and wipe that off.

 

I know it seems like a hell of a coincidence but nothing about 5.7 should have changed anything about the printer that would stick. If you could try and print something and post a photo we could have a look and see if it looks like any particular reasons things don't stick.

 

If you are going to reflash the firmware, remember: it will consider any firmware file which doesn't have the same name as the last firmware file installed newer.

[jaysenodell 18]

@Slashee_the_Cow, in octo, home x and y. Read the actual position of the head. On the e3s1p it’s -12,-12. 15 (Z wasn’t homed). The edge of the pei plate is right about -8. I can print down the edge fairly easily. Cura sees hardware 0 as 0 still leaving 16mm of plate unused. Cura took another 10mm off that. 
 

The e3s1p will gladly grand the belts past the upper and lower limits. You you have stepper shutoff switches?

[Slashee_the_Cow 493]

7 hours ago, jaysenodell said:

You you have stepper shutoff switches?

No, I have bits of metal and plastic which prevent it going past certain points:

 

Left: homing mechanical switch

 

Right: metal bit mounted to the gantry that goes completely around the frame

 

Rear: mechanical homing switch and metal surrounding wheel:

 

Front: The golden pins on the frame underneath the print bed collide with raised plastic bit at the front of the printer:

 

7 hours ago, jaysenodell said:

@Slashee_the_Cow, in octo, home x and y. Read the actual position of the head. On the e3s1p it’s -12,-12. 15 (Z wasn’t homed).

 

Send: G28
Recv: ok
Send: M114
Recv: X:134.25 Y:125.00 Z:10.00 E:0.00 Count X:10740 Y:10000 Z:4000

 

Time for what I love: Science... WITH A MACRO LENS!

Note 1: I'm not actually at macro distance i.e. 1:1 but at about 0.6x I'm closer than all my other lenses can get... except my other macro lens.

Note 2: There are three main things to blame for the awkward angles of these shots: too much effort to take my printer out of the tent, the size of the ring on my ring flash, and the physical length of the lens plus a mount adapter.

Note 3: Sorry if any of them are a little out of focus. You try holding a camera with a decent size macro lens, battery grip and ring flash still for a quarter of a second.

Note 4: I'm happy to provide full res versions to anyone who wants to see gory detail which hasn't been crushed by the forum. Just message me and ask. RAW versions available for an additional processing fee.

 

Anyway:

Send: G0 X0 Y0 Z0.2
Recv: ok
Send: M114
Recv: X:0.00 Y:0.00 Z:0.20 E:0.00 Count X:0 Y:0 Z:80

Key reference points for the X tests: the "Warning hot surface" marking

 

Okay, so the gcode does the first line of the wipe at X -3... can we go there?

Send: G0 X-3
Recv: ok
Send: M114
Recv: X:-3.00 Y:0.00 Z:0.20 E:0.00 Count X:-240 Y:0 Z:80

Yes we can. Can we go further?

Send: G0 X -5
Recv: ok
Send: M114
Recv: X:-5.00 Y:0.00 Z:0.20 E:0.00 Count X:-400 Y:0 Z:80

I actually had to redo these after the fan cable for the shroud got caught in one of the wheels on the X axis gantry and impeded its movements. Nobody's stopping me yet, apparently. Further?

Send: G0 X -10
Recv: ok
Send: M114
Recv: X:-10.00 Y:0.00 Z:0.20 E:0.00 Count X:-800 Y:0 Z:80

I think this is the definition of "pushing your luck". I will keep pushing in the name of science!

Send: G0 X-20
Recv: ok
Send: M114
Recv: X:-13.00 Y:0.00 Z:0.20 E:0.00 Count X:-1040 Y:0 Z:80

The finishing point! X-13! It's probably a bad place to try printing anyway. Can I push it in the other direction?

Send: G0 X225
Recv: ok
Send: M114
Recv: X:220.00 Y:0.00 Z:0.20 E:0.00 Count X:17600 Y:0 Z:173

Finishing point for +X: 220 Apparently not.

 

Now for Y axis testing. Here's our "starting position" picture as a reminder:

Key reference point for Y tests: text and fingerprint icon.

Those fingerprint icons are on tabs that stick out from the rest of the bed - it's not printable area.

At the back there's a couple of cutouts for screws which mean the absolute back isn't printable area either.

So let's start where we did last time. Except, you know, other direction.

Send: G0 X0 Y-3
Recv: ok
Send: M114
Recv: X:0.00 Y:-3.00 Z:0.20 E:0.00 Count X:0 Y:-240 Z:80

I haven't measured that text, but I'm not sure if that's actually a difference of 3mm. Only one thing to do: push it further!

Send: G0 Y-5
Recv: ok
Send: M114
Recv: X:0.00 Y:-5.00 Z:0.20 E:0.00 Count X:0 Y:-400 Z:80

Now it looks like we're making some progress. Further!

Send: G0 Y-10
Recv: ok
Send: M114
Recv: X:0.00 Y:-10.00 Z:0.20 E:0.00 Count X:0 Y:-800 Z:80

Now we're getting somewhere useless! The gods demand further.

Send: G0 Y -20
Recv: ok
Send: M114
Recv: X:0.00 Y:-15.00 Z:0.20 E:0.00 Count X:0 Y:-1200 Z:80
Recv: ok

We've apparently reached its limit: Y-15. You'd need to do pretty damn well with bridges to use it though. Oh well. Hit reverse!

Send: G0 Y225
Recv: ok
Send: M114
Recv: X:220.00 Y:225.00 Z:0.20 E:0.00 Count X:17600 Y:18000 Z:-9

Screw going to Y220 first for a photo at a reference point. The point is that we're making progress already. How much more progress can we make?

Send: G0 Y230
Recv: ok
Send: M114
Recv: X:220.00 Y:227.00 Z:0.20 E:0.00 Count X:17600 Y:18160 Z:-11

Up to Y227 apparently! But you'll run into those aforementioned screws at 225 anyway.

 

~~~~~ 🐄 Cownclusions: ~~~~~

• Just because you can go to X-3 doesn't necessarily mean it's something you should do in your startup gcode.
• I may have to go make a post which lowers every X and Y value by 3 and increase the bed size in Cura.
• My nozzle looks disgusting up close. I mean, everything does, but this especially.
• 5 Slashee points to whoever can tell me what the last type of filament I printed with was.
  • 500 Slashee points to whoever can tell me what I printed with it.
• Watch for the damn cables if you're just going to leave your shroud dangling.
  • Hey Creality, how about you don't make the screwholes on the inside black so that I might be able to find them next time I need to put this thing back on.
• I'm not sure what the point of the stopping measures (except +X) are given my results. But it's worth noting for the extreme -X values it was actually pushing up against the homing switch.
• Next time remind me to take the shroud off before I take a bunch of photos where you can't really see where the nozzle is and realise I should take the shroud off.
  • I'm reasonably sure taking the shroud off didn't affect any of the readings, letting it go where it wouldn't with it on.
• Given I can't manually level the bed at all, I'm wondering if I should be worried about the difference in Z height in different parts.
• No, I didn't try going out of bounds on both axes at once. And it's too late now, so don't ask. At least don't ask for photos, I might be willing to try it just moving the head around.
• Given the quality control on the startup gcode, I may have to put in a PR to make it wipe its nose at X-13.
• I never tested extruding at any of these positions. Getting close a nice, toasty hot end with expensive camera equipment is not my kind of science experiment.
  • If you can't figure out what would have happened yourself. why have you read this this far?

[GregValiant 1,415]

I doubt very much that it is a firmware issue.  I also doubt that Cura is to blame for the problems.  I look at almost all the bug reports on GitHub and this is the first time I have heard of this problem.  There are enough people using the same printer that if it was a problem with Cura, there would be numerous bug reports.  That hasn't happened.

 

PLA will usually stick.  One of the main "won't stick" problems is a contaminated build surface.  Dust, oil from fingers, chocolate smears, and other stuff on the build plate can keep the first layer from adhering.  If the "Initial Z gap" is too tall then the layer is effectively under-extruded and there just isn't enough squish.

Start by giving the build surface a good bath with dish detergent, but it back in place on the printer, and then wipe it down with 90% IsoPropyl Alcohol.

If it still doesn't want to stick I'd double check the Z Offset, then the E-step calibration, and if necessary start increasing the "Initial Layer Flow".

 

Cura itself doesn't put any firmware altering commands into the gcode.  Some StartUp Gcodes might contain those types of commands (usually M201 and M203 for Accel and Jerk).  In addition the "Z-offset" plugin can have an effect if you happen to have it enabled.

I have never seen an M500 command in any gcode file.  Without it, any firmware altering commands that might be there will revert to the firmware defaults when the printer is turned off.

 

 

 

 

 

[Slashee_the_Cow 493]

2 hours ago, GregValiant said:

I doubt very much that it is a firmware issue.

So do I, but the general rule with Enders is "if that doesn't fix it, try something else".

 

2 hours ago, GregValiant said:

I also doubt that Cura is to blame for the problems

I'll do you one better than Greg: I'll guarantee Cura isn't to blame.

 

2 hours ago, GregValiant said:

If it still doesn't want to stick I'd double check the Z Offset

The E3V3SE does auto z offset (it has force gauges under the build plate to measure the levelling probe). You can adjust it manually, but auto has never steered me wrong before.

 

Although that's another good thing to try: run the ABL program from the printer's control panel.

[jaysenodell 18]

@Slashee_the_Cow, G28 X Y then M114 will tell you the neg limits of XY (limit switch). 
 

My e3 has the same mechanical stops to prevent self disassembly. I was hoping for a limit switch style “far enough” set up to protect components. Probably need big dollar printers for that. Or I’ll build them into one. 
 

I really enjoy how you jump into all the details. When I grow up I hope to be that passionate about things. 

Edited April 14 by jaysenodell

[IamPAllen2 0]

13 hours ago, Slashee_the_Cow said:

Try doing a factory reset of all the settings from the printer's control panel first.

 

Also try cleaning your print bed (can't hurt): I just spray it with some isopropyl alcohol and wipe that off.

 

I know it seems like a hell of a coincidence but nothing about 5.7 should have changed anything about the printer that would stick. If you could try and print something and post a photo we could have a look and see if it looks like any particular reasons things don't stick.

 

If you are going to reflash the firmware, remember: it will consider any firmware file which doesn't have the same name as the last firmware file installed newer.

I have cleaned the bed with IPA and also went through the settings to revert back to factory settings. I am still having problems. I have my other laptop that I set back to factory before I bought the V3 SE and I have installed Cura 5.6.0 on it. There is not much on the laptop as I was tryin g to sell it, but I have copied some of my cura prints I designed on Thingiverse on to an external drive and will be putting them on the laptop. I have also installed Thingiverse and Tinkercad. If it works out perfectly as before, I will be using one laptop for the printer and this main one for other stuff. Will update when tested.

[Slashee_the_Cow 493]

I would say "this is why I make my own, custom printer definition", but no, it's actually because definitions didn't exist for either the E3V2 Neo (although that's basically the same as the regular E3V2 with a G29 thrown in) or the E3V3SE when I got them.

 

And looking at the stock profile for the E3V3SE... I'm pretty happy I made my own because it didn't suck to begin with and I question the wisdom of nose wiping at a negative distance, where it might be hitting the homing switch. Also it's always fun to have

G300 P200

G4 S10

at the end of my startup code so I can go have a look if it wiped its nose correctly.

[IamPAllen2 0]

My printer is printing perfect now while Cura 5.6.0 sliced and saved to external drive on my spare computer.

Even though I uninstalled 5.6.0 on this laptop and reinstalled it, there must have been a setting on here still that kept the 5.7.0 setting.

I will just have to get used to using two laptops unless I can find a way to completely uninstall 5.6.0 with everything pertaining to it on this laptop and do a fresh install. I have turned off auyo install updates on this cura 5.6.0 as the 5.7.0 was coming up telling me a new version was ready to download.

Cura must be like ebay and going backwards in their upgrades or just making things worse. probably employing school kids to do their programming like ebay does.

[Slashee_the_Cow 493]

37 minutes ago, IamPAllen2 said:

Even though I uninstalled 5.6.0 on this laptop and reinstalled it, there must have been a setting on here still that kept the 5.7.0 setting.

Each version of Cura stores has its own folder for preferences. In Windows just go to %APPDATA%\cura - the first time you run a new version, it will copy (just a plain copy) the preferences folder from the most recent previous version (i.e. 5.7 will copy 5.6, but 5.6 would copy 5.5).

 

Changes are never copied backwards. After having copied the preferences folder from the previous version, it will not touch it again. Ever. After the initial copy, changes are never copied forwards, either, the different versions act entirely separately; you can change preferences, add or remove printers, add a post-processing script in one and the other version will remain completely unchanged. The one exception is if you use an UltiMaker account to sync what plugins you have installed.

 

If you still want to try a clean install, follow the instructions in this support article.

 

37 minutes ago, IamPAllen2 said:

Cura must be like ebay and going backwards in their upgrades or just making things worse. probably employing school kids to do their programming like ebay does.

Please don't denigrate software developers. It's much harder than you'd think, especially with how a program like Cura is set out. There is no possible way that installing 5.7 will affect the gcode produced by 5.6, other than if you use an UltiMaker account to sync plugins and install/remove them, that change will propagate. 

 

Cura is an open source project and some of the developers are volunteers donating their spare time (just like people like me, @jaysenodell and @GregValiant are volunteering our time helping people on the forums). That doesn't mean anyone can slip some crappy code in either; all changes have to be approved by the senior developers. UltiMaker do have their own programmers working on Cura too, but by combining what UltiMaker wants with what the community can produce you get a program which is better suited to everyone.

[IamPAllen2 0]

12 minutes ago, Slashee_the_Cow said:

Each version of Cura stores has its own folder for preferences. In Windows just go to %APPDATA%\cura - the first time you run a new version, it will copy (just a plain copy) the preferences folder from the most recent previous version (i.e. 5.7 will copy 5.6, but 5.6 would copy 5.5).

 

Changes are never copied backwards. After having copied the preferences folder from the previous version, it will not touch it again. Ever. After the initial copy, changes are never copied forwards, either, the different versions act entirely separately; you can change preferences, add or remove printers, add a post-processing script in one and the other version will remain completely unchanged. The one exception is if you use an UltiMaker account to sync what plugins you have installed.

 

If you still want to try a clean install, follow the instructions in this support article.

 

Please don't denigrate software developers. It's much harder than you'd think, especially with how a program like Cura is set out. There is no possible way that installing 5.7 will affect the gcode produced by 5.6, other than if you use an UltiMaker account to sync plugins and install/remove them, that change will propagate. 

 

Cura is an open source project and some of the developers are volunteers donating their spare time (just like people like me, @jaysenodell and @GregValiant are volunteering our time helping people on the forums). That doesn't mean anyone can slip some crappy code in either; all changes have to be approved by the senior developers. UltiMaker do have their own programmers working on Cura too, but by combining what UltiMaker wants with what the community can produce you get a program which is better suited to everyone.

Well, something went wrong and altered my Cura 5.6.0 settings when 5.7.0 was in stalled. I looked through my computer and found a settingh to 'turn back 5.6.0 back to when it was fgirst installed. There are 2 settings of 5.6.0 so 5.7.0 must have altered one of them. When my printer has finished, I will trty cura on this laptop again to see if it prints properly andworks as it should.

Ifg I could find a slicer that works better and simple gfor an old man like me, I would use that. But as it is, I like Cura as it is easy to follow, especially for the Ender printers and for me to use.

But I would like to know how an update can ruin a perfectly useable running version when installing. Plus I dont sync with anything. I dont understand syncing.

It is frustrating when a perfectly working printer is useless with an update.

[Slashee_the_Cow 493]

1 minute ago, IamPAllen2 said:

Well, something went wrong and altered my Cura 5.6.0 settings when 5.7.0 was in stalled.

Your 5.6.0 settings would have remained completely unchanged. Settings in the slicer are not the only potential cause for problems printing.

 

Remember the first rule of science: correlation is not causation.

[IamPAllen2 0]

4 hours ago, Slashee_the_Cow said:

Your 5.6.0 settings would have remained completely unchanged. Settings in the slicer are not the only potential cause for problems printing.

 

Remember the first rule of science: correlation is not causation.

I managed to print perfectly from both of my laptops now. The setting back to 5.6.0 from a previuous date (the date I installed it) worked. The second setting was the date of the updated 5.7.0. I think as it was a newer version, when I uninstalled and reinstalled 5.6.0, it chose ht e newer version. All is running good now and I will not be updating any more in the future incase something else fails.

[Slashee_the_Cow 493]

Just to try and satisfy my curiosity, if you still have 5.7 installed on any computer, is there any chance you could set up a print in 5.6, save the project (File > Save Project), save the gcode, then open up that project in 5.7, save the gcode with a different filename, then post the project and both versions of the gcode so we can see what might be different and causing a problem?