Recovery from a disaster, new install, can I salvage settings from the old install?

JoeMickley

My current Win10 OS ate itself, unstable, mostly unusable. Runs, but not at all well. I am putting up new hardware and a new system. I will download the latest Repetier-Host, then comes the hard part. My current installation has much tweaking and adjusting of settings to accommodate my 3D printers needs, likes, and dislikes. Is there a config or control file I can copy over from the current install to the new install that will bring in all of these settings?

I do not look forward to the process of opening every menu and submenu on the current setup and then trying to change entries in the new install to match. (Also not sure I would live that long. There are a LOT of menus and submenus. I miss even one and it's a mess.)

Any/all advice welcome. Any volunteer to do this job also welcome.

Repetier

Host settings are all in registry in HKCU/Software/repetier or repetierhost not sure. You should also backup the work directory and your slicer directories. Restoring these should give you back all settings. COM ports will likely be different in numbering after reinstall.

JoeMickley

What do I need to do to get the registry info from the current machine to the new machine? I'm not sure I want to plow thru the current registry and copy things by hand.

Note that this is not a restore on the same machine but a move to new H/W entirely. Can I simply copy all of the directories for Repetier over to the new H/W and skip an install?

Can I copy/paste out of the registry into a temp file, move the temp file to the new machine, then copy/paste into the target registry. I have some experience with registry editing but not on that level.

Repetier

The windows software regedit.exe (use run program in windows to start) can export a directory of the registry and also import backups made from this.

You need to first install new host on new machine so software it self is correctly registered. Then you can overwrite settings by importing the registry. But note that you need to be same user using same paths as on old machine or some settings might point to folders that do not exist.

JoeMickley

Thank you for that additional guidance. I will chug thru that and see how it goes. If nothing else, the registry entries will give me guidance on any parameters I might otherwise miss.

My plan is to create a very simple 3D part, run it thru the existing Repetier installation and generate a Gcode file, then do the same on the new install. The Gcode files are readable ASCII, so I can do a line by line compare. If I find discrepancies, I can work back and determine the setup error. Validation occurs when the 2 files match exactly.

Repetier

Good plan. But don't forget to copy also the slicer configs files or you will get a difference.

JoeMickley

Exported the Repetier block from the old machine registry, but when I attempted to import it into the new machine disaster struck. The import process thoroughly corrupted the registry. I had created a restore point just prior to the import, but even a restore from that save failed. Ultimately. I had to do a complete drive restore (which, fortunately I had created also just prior to the registry update attempt) to get back to the pre-registry update point.

I have gone thru the existing (old) install and taken screenshots of all of the setup pages and will use those to manually load the new install with the correct values. My plan remains in place on the method to validate the setup. I am extremely fluent in Gcode and at least moderately understand the relationships between Repetier settings and the resultant Gcode. If I run into an issue on reverse engineering from Gcode to settings I will return here for further counsel.

I truly like Repetier. It is superior to any other product I have examined. It works well and gives me no problems. The features are extensive and useful. In spite of this difficulty I remain an advocate for this program.

Editorial comment, feel free to use or ignore:
In my opinion the use of the registry to store user settings is a poor choice. There are any number of programs that store user settings in .xml files, usually in the root directory of the program or the associated data subdirectories. This provides excellent portability to anothr location as well as allowing a user to edit them to make changes. There are other file formats as well, but the portability remains when that approach is used. {I recognize that Repetier is a mature package, so that may not be possible, but you may wish to consider that approach for future products.

Repetier

Did you export the complete registry of only the repetier subfolder. Later is the correct way as the first will surely damage your windows including so many settings.

We in deed learned from the registry problem and our lastet product Repetier-Server just stores everything in one folder, so we can just backup the folder. This is also much better portable across the different os. Regarding host it is in deed to late as it is hard coded in many places and probably even 3rd party plugins some are using.

JoeMickley

Exported only the Repetier block. I exported it both in the native registry format and as text. I had looked at the text and indeed it got only that block. It also appeared to match what I saw on the screen with regedit. The process itself appeared simple. Export, then import. Dropdown menu choices in regedit. No error messages, no lockups, it just trundled along. When it was done, I attempted to look at the block in the new machine. I got absolutely NOTHING that looked like the original entry. When I tried System Restore it simply died when attempting to back out to the last saved configuration. Ended up wiping the HD to zero and doing an image restore from an external backup.

I did a little research, but the answers are unclear. The versions of windows on the 2 machines are different, so I suspect (without proof) that the internal registry structures are different.

When I am finished updating the new copy manually and have the new/old Gcode results aligned, I am going to export that new registry block as text and just do a compare visually. (No real use for that, just satisfying my curiosity.)

I agree, host is past any point where it could be changed. It is still a great product.

JoeMickley

I am comparing a text saved section of the registry between the old and new installation. That has been extremely useful to me in finding errors in the setup parameters.

I am stymied on one entry for which I have an old/new mismatch and for which I am unable to determine where in Repetier setup the data is set.

In the registry at:
Repetier\Slicers\cura\CuraEngine\default, Value 5, Name: speed, Type: REG_SIZ
I have an old/new data value mismatch.

Can you advise what screen and parameter name in Repetier setup controls this value?

JoeMickley

Disregard previous post. Identified and fixed. (Parameter is controlled by an uncalibrated slider in Cura window.) Also did not solve my Gcode mismatch probelm, so we will move on to that.

When I compare old and new Gcode files I find:
All X, Y, Z positions match perfectly.
All feedrates (F term) match perfectly.
All S terms match perfectly.
All block sizes, block identifiers, etc, match perfectly.
The line count matches (that is, a line of Gcode in the new file is in exactly the same place vertically from the start of the file as in the old (baseline) file.)

The filament feed is low by about 9% in the new file compared to the old file. The E term is cumulative, but it shows up in the very first print line, then degrades by the same proportion as the part generation proceeds. I copied the CuraEngline parts of the Repetier log out form old and new machine. The logs match perfectly except at the end where the total filament used is reported. The new machine generation report is about 9% lower than the old report. That is consistent with what I see in the incremental feed values.

I believe that this feedrate is determined within Cura but depends on some parameter sent over from Repetier when Cura is launched. Cura uses an .ini file to control its configuration, but I copied over the old .ini into the appropriate Cura directory.

Any thoughts on this? Right now, the output will underfeed filament into the part by 9%.

Feel free to correct my understanding of the process.

JoeMickley

And now, disregard 2nd post as well. All is well, last gremlin found and killed, old and new Gcode files match exactly.

As it turns out, Cura has 2 .ini files, 1 for print and 1 for filament. The old/new .ini's in filament were different. Copied the old .ini file into the new machine and the feedrate problem was gone.

Back to business.