Cura overwrites existing G-code without warning and option for new name.

[Bertho]

With all the fantastic improvements and the continuing support and features being added, there is one simple option that has not been corrected yet:

Cura is the only program that I can think of that overwrites a previous saved file without any warnings and an option to save under a new name.

To properly document different settings and being able to go back to a previous version, that previous file needs to be available. I know, it can be done manually but it is not normally required and too many errors happen, and in a flash the previous version is gone.

Please add this standard option. It has been requested at least since last summer. Thanks in advance, Bertho

[daid]

https://groups.google.com/forum/#!topic/ultimaker/7-73A0Nvjg0

[Intrinsically-Sublime]

I read the google group and it is really two sided but I have to agree with the request. Maybe it should just be a prepare and save as button that is totally separate as to not screw up anyone's elses work flow.

The why. I name all my files similar like Extruder_upper.stl Extruder_lower.stl so when you look through the files they are all grouped together as one would expect. But when I slice and save the gcode on an SD card and view them on the LCD they all just show up as Extrude.1.gco Extrude.2.gco and have no way to know what they actually are. So I would like to use Save as to rename the file even if I am saving over the original and do not want multiple copies. Like Up_ext.gcode and Dwn_ext.gcode this way I can see the names and know what they are from the LCD. With the current prepare print you end up not using the save to SD card option and instead saving where the STL is and then copying and renaming the files which is not better for a work flow in anyway.

[daid]

For the "multiple files with same name", I recommend updating to a newer firmware. I'm releasing a new firmware with the next version of Cura. Features long filenames, up to 19 characters.

[Intrinsically-Sublime]

Can you give me the commit info on that change as my custom version of Marlin for Tantillus users was branched almost a year ago and I don't want 99% of what has been changed since so I will not be merging the newer version.

EDIT: Also Tantillus uses a 16x2 LCD so unless you have implemented Sailfishes scrolling names your new 19 character version would not help much.

[daid]

Then you would have 16 character filenames, which is a lot better then the current 8 (but usually 6 due to ~1)

You'll have to search back in the sdfile files for the first commit done by me.

(I am currious about what you don't want in changes, and why)

[Intrinsically-Sublime]

All Tantillus needs form Marlin is the gcode interpreter with look ahead. The rest is just wasting space. We do not use any of the special features like auto temp. Also: No PID just bang bang, No EEprom, No Advance. Just a simple gcode interpreter with look ahead. Tantillus does not need them nor do its users use them, they just makes it harder to use and do not improve the results. To tune Tantillus you only set the steps per mm on E and that is it. I have the people actually update their copy of Marlin and re-upload it so 1) So they have some clue on how to do it 2) Have a copy of their current settings. My latest version of Marlin that I lost to a harddrive failure had almost no LCD menu features that resembled Marlins defaults. Just a couple of things like tuning E during the calibration period and a few settings to live tune the machine speed and temps. Plus the obvious SD card access. The default LCD menus in Marlin only serve to confuse even the most veteran RepRapper.

[daid]

Autotemp doesn't get compiled by default. PID can be turned off (but does improve prints). EEPROM can be turned off, advance is off by default (and might not even work). (and when I say "off", I mean, doesn't get compiled into the code) A simple fork with changed config does wonders, as I did for Ultimaker: https://github.com/Ultimaker/Marlin

The new LCD code should make it easy to customize the LCD menus. But many of the strings used currently are for 20 width character displays. I'm not that happy with the current menus myself (and I already removed a few of the really odd-ball options, like "autorun" and "set origin"). So I'm all for making something that makes more sense.

[daid]

Also, I'm working slowly on electronics based on the Arduino Nano v3. Which only has 30k flash, and 2k ram. So I will need to add a "LEAN_AND_LEAN" option anyhow, else it will never fit.

[Intrinsically-Sublime]

I used PID from the very start with Teacup and then on Marlin and when I finally turned it off I had vast print improvements. The PID can not react fast enough for speed changes, I assume that is one of the reasons you have cura configured to only have one speed. PID works by averaging over time and thus means it does not react as fast as needed when you start pushing a lot of filament through the hot end and it cools off. With Bang Bang it can turn on full and stay there until the machine slows back down and then it goes back to on/off to maintain the temp. For this to work well you must have a heater block that has a decent thermal mass and good insulation on it. And remember my prints are some of the very best of the best http://www.tantillus.org/Images/Devil_01.jpg http://www.tantillus.org/Images/Frog_02.jpg

Unfortunately because of the LCD size and requirements to have a simple menu I can not just have a custom config file. I had to change a lot of code in the LCD section to get things to work properly on a 16x2 screen. The version I lost in the drive failure and I'm running on all of my machines had a lot of changes in the menus and the config file. I see zero reason to have all the advanced config settings for PID in the main config. Also the main settings that need to be adjusted should be at the top of the file. So my last version was quite different from the current Marlin..

I am all for a stripped down Marlin as you suggest. As I get more confident with programming I will most likely get into stripping Marlin down to its basics. But it may be a better idea to take Teacup and add look-ahead. Teacup runs really well and if it had Look-ahead I would still be using it. I know that I2C2 uses Teacup and grbl combined but they stripped out all the Atmega code and replaced it with ARM code.

[daid]

If the PID is not reacting fast enough, then it's not properly configured (which wouldn't be a huge shock really). You want a pretty large P value. (PID off acts the same as a P:inf, I:0, D:0)

I agree on the PID settings, and a lot of other settings should be deep buried in the menus instead of in the front as they are now. There is also the odd "prepare turns into tune during SD printing" where the tune menu has a few settings duplicated and the tune menu has settings not in the other menus.

When I look at the Marlin code, the look-ahead code seems to be the only part which is developed. The rest is thrown together. My new UltraLCD.cpp code is an improvement. But the GCode parse is still a mess, as well random half implemented features.

[Intrinsically-Sublime]

Agree with almost everything you say. But I do not believe PID will ever work regardless of the settings. Its entire purpose is to precalculate the the required PWM to maintain the current temp. So when you have a sudden change in required temp it takes a few reading before it decides to increase the temp. If it is set in a way that it reacts right away to the needs it is then working in Bang Bang mode regardless of being called PID. PID is designed to maintain temperatures not to deal with sudden changes. This may also be why you guys print at such a high temperature 220c for PLA. I print anywhere from 165c to 210c but on average at 190c and yet print at the same speeds or faster then the defaults in Cura. I know a lot of people have claimed that PID works better but where is the evidence? Have you actually done any testing yourself to confirm? But again the hotend has a lot to do with it. Tantillus uses J-heads with 7+ layers of Kapton as insulation.

[Intrinsically-Sublime]

I have searched through your Marlin branch and can not find the commit you made to increase the SD name width. The only commit you ever made to SD file had nothing to do with the LCD.

[daid]

I have commit rights on the ErikZalm fork these days. But it's this commit: https://github.com/ErikZalm/Marlin/commit/b69e75c89a0be970b2742cd8bff603baf824d7a9 Adds the long filename support.

[Intrinsically-Sublime]

Well that explains why I could not find it. Thanks for all your work and finding this for me.