Management eeprom as in Repetier Host
It is known that Repetier Server uses an XML file when exporting the content of the eprom.
I use MK4duo as firmware, and often the xml plugin for eeprom management is updated, and when I go to import a previously saved xml eeprom I find many wrong imported parameters, something that doesn't happen with the host because it doesn't use logical positions but simple gcode commands.
A simple example, msteps exported with the Host:
M350 X64
M350 Y64
M350 Z64
M350 T0 E32
M350 T1 E32
I do not intend to replace the current standard, but to have also the possibility of import/export in the "gcode" format that creates the Host.
Marco
I use MK4duo as firmware, and often the xml plugin for eeprom management is updated, and when I go to import a previously saved xml eeprom I find many wrong imported parameters, something that doesn't happen with the host because it doesn't use logical positions but simple gcode commands.
A simple example, msteps exported with the Host:
M350 X64
M350 Y64
M350 Z64
M350 T0 E32
M350 T1 E32
And here with the Server:
<epr pos="421" type="2" value="64">X driver microstep [ms]</epr>
<epr pos="422" type="2" value="64">Y driver microstep [ms]</epr>
<epr pos="423" type="2" value="64">Z driver microstep [ms]</epr>
<epr pos="424" type="2" value="32">E0 driver microstep [ms]</epr>
<epr pos="425" type="2" value="32">E1 driver microstep [ms]</epr>
<epr pos="421" type="2" value="64">X driver microstep [ms]</epr>
<epr pos="422" type="2" value="64">Y driver microstep [ms]</epr>
<epr pos="423" type="2" value="64">Z driver microstep [ms]</epr>
<epr pos="424" type="2" value="32">E0 driver microstep [ms]</epr>
<epr pos="425" type="2" value="32">E1 driver microstep [ms]</epr>
If the MK4duo xml plugin has updates some positions (called "epr pos") change, and fails to import those values, writing them elsewhere, with its disastrous result.
I therefore ask you to implement an eeprom management like in the Host, more convenient and never wrong in any case.I do not intend to replace the current standard, but to have also the possibility of import/export in the "gcode" format that creates the Host.
Marco
Comments
Also I do not have any eeprom file having 425 entries. So I guess that is something self build. Important fact is that "pos" is the position in the eeprom describing file. So it is essential that on updates you add new entries to the end so old mappings do not get suddenly mapped to different values.
When mapping to values the detect rule is applied. If a firmware changes format, you would need to extend the detect rule to catch old and new format.
If these 2 rules are followed the assignments to new updated firmwares should always be correct, or I did not understand the problem you are describing.
https://github.com/MKFirmware/MK4duo/blob/master/MK4duo/plugin Repetier/RRFirmwares/marlineeprom.xml
I think the best solution would be to add a pos value 10000+ to entry tags. If present we will use these instead of position in list, then you can add them anywhere as long as you assign a new pos number.
Being such special I should also add a mk4duo firmware with own eeprom table in the default setup. Starting with marlin.xml as copy but guess it will soon change to fit better to mods.
Is it so complicated to insert it as an option in the Server?
So we will see with what I come up as final solution that solves all my problems mentioned:-)
Exporting the MK4duo eeprom to the "X Diagonal Rod Adj." section as you can see a value of "0.6" is saved even if the original was "0.600".
When you go to import the eeprom the Server reports this value as different (in green), even iwe know that it is still good.
<epr pos="402" type="3" value="0.6">X Diagonal Rod Adj. [unit]</epr>
<epr pos="403" type="3" value="-0.200">Y Diagonal Rod Adj. [unit]</epr>
<epr pos="404" type="3" value="0.650">Z Diagonal Rod Adj. [unit]</epr>
The normal web gui treats values as strings only marking it changed if value string has a difference. Internally values are also handled as string. Currently don't see where else the 0 could get omitted. But touch screen does not have an export function and the simplification looks like it got converted to number and back omitting the 0 in conversion.
So can you provide more information on steps to reproduce including when you see what value where.