Recovery from a disaster, new install, can I salvage settings from the old install?
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.
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.
Comments
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.
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.
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.
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.
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.
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.
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?
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.
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.