Persist G92 and G43.1

[dshaded]

This patch addresses issue #623 . It adds EEPROM persistence to G92 and G43.1 parameters, reduces flash consumption by approximately 150 bytes but increases RAM consumption by 8 bytes.

[cri-s]

Just my 2 cents, G92 need to be reset inside mc_reset and when you really store G92 inside eeprom, you need to increase eeproms cycle counts. This is especially true for arm targets where eeprom is only simulated using flash memory. Further i'm caching the coordinates into ram because if axis go up, with higher speed serial transmission, the eeprom or flash writing looses characters. As i use intel style checksum with the $Hhh at the end of line, . In order to cover serial transmission errors, the problem occurs as the $ char itself is sometime lost and then the sending gui don't realize that it needs retransmit several lines. 2019-03-18 9:24 GMT+01:00, Denis Vygovskiy <notifications@github.com>:

…

This patch addresses issue #623 . It adds EEPROM persistence to G92 and G43.1 parameters, reduces flash consumption by approximately 150 bytes but increases RAM consumption by 8 bytes. You can view, comment on, or merge this pull request online at: #624 -- Commit Summary -- * Persist G92 and G43.1 -- File Changes -- M grbl/gcode.c (20) M grbl/gcode.h (2) M grbl/report.c (26) M grbl/settings.h (5) -- Patch Links -- https://github.com/gnea/grbl/pull/624.patch https://github.com/gnea/grbl/pull/624.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #624

[dshaded]

I have looked through mc_reset code and didn't see anything that messes up with coordinate systems. Why do you think it should reset G92?
And by cycle counts you mean increasing number of physical writes to eeprom? That's absolutely ok for avr's. And simulating eeprom with flash is kind of a desperate measure when you can't use external eeprom or battery-backed memory domain. And when you can't use G92 or G43.1 to set TLO because they are lost on every controller reset you usually use G54-59 corrections for that purpose, at least with bCNC.
Not sure about caching coordinates into ram as I don't see any issues with character loss and ram constraints are really tight on 328p.

[cri-s]

It was my failt. G92 need to be reset at power cycle as defined by gcode standard. So it should be reset at main.c or better settings_init. mc_reset was my wrong thinking as i erroreneous beliewed it should reset at M2/M30/M60 that all call mc_reset. I would suggest annother approach, maybe you could try it.I make a small PR. Just to be sure, you want G92 and G43.1 to be persistent and it should be reset on power cycle, correct. Are other variables that need the same thing ? 2019-03-19 2:39 GMT+01:00, Denis Vygovskiy <notifications@github.com>:

…

I have looked through mc_reset code and didn't see anything that messes up with coordinate systems. Why do you think it should reset G92? And by cycle counts you mean increasing number of physical writes to eeprom? That's absolutely ok for avr's. And simulating eeprom with flash is kind of a desperate measure when you can't use external eeprom or battery-backed memory domain. And when you can't use G92 or G43.1 to set TLO because they are lost on every controller reset you usually use G54-59 corrections for that purpose, at least with bCNC. Not sure about caching coordinates into ram as I don't see any issues with character loss and ram constraints are really tight on 328p. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #624 (comment)

[dshaded]

Sorry @cri-s but your changes are exactly opposite to what I'd like to achieve.