Management eeprom as in Repetier Host

Marco67

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

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>

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

Repetier

Where does that mk4due plugin come from? I do not have that.

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.

Marco67

MK4duo has well over 400 entries, here the plugin:

https://github.com/MKFirmware/MK4duo/blob/master/MK4duo/plugin Repetier/RRFirmwares/marlineeprom.xml

Repetier

Looking into the history it becomes clear why it does not work over versions. New tests are added where they like them to build nice groups I guess. But that shifts positions that get exported so with every new xml old files are not working.

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.

Marco67

The best solution in my opinion is to use the same system of load/save the eeprom of the Host, using the gcode command instead a position and value, that never fails.
Is it so complicated to insert it as an option in the Server?

Repetier

At first it is incompatible to old system, so changing that is also causing problems. I have to check what server does. But I need a solution being backward compatible since I also need to do this for marlin eeprom. If it is soo complicated I can not say at the moment. Surely parsing will not work that way. Now repetier/marlin use the same format in server so I have a unified handling of them. In host I have 2 solutions depending on firmware. And when I add mk4duo even 3 different ones.
So we will see with what I come up as final solution that solves all my problems mentioned:-)

Marco67

I've now upgraded to 0.93.1, great work, especially on the eeprom import from different versions, perfect, thanks!

Repetier

Thanks. I now use the description which also should be unique to map it to entries. That way no modification is required.

Marco67

Hi Roland, I found a small almost irrelevant but boring problem in the latest Server version.
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.

"Y and Z Diagonal Rod Adj." instead they are exported correctly and this does not happen, even if as you can see Y has the value -0.200 and is saved that way, and not -0.2.

If the value of X is 0.601 it is exported correctly, with all the characters up to thousandths of a mm.

   
<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>

Repetier

Are you talking about the touch screen eeprom editor? There touched values are treated as numbers causing trailing .0 to be omitted making the value change. 
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.