If you are running UBL and have a well tuned mesh, you can make a backup copy of it on your computer.
This is necessary if you generated the mesh with a previous RCBugFix and want to transition to a current RCBugFix.
This should be the only time this is necessary. Firmware revisions should just be a "Load and Go" in the future.
This should be added to the Marlin Documentation. Is documentation for UBL in the works?
without starting a new thread, is there information on the easiest way to update from one revision to the next. Is there a way you can just load in the changes to a .ino file and then load away?
This should be added to the Marlin Documentation. Is documentation for UBL in the works?
Currently, most of the documentation is at the start of the G29 and G26 file. You should be able to figure things out from that. If not, just ask.... Hopefully, somebody with good documentation skills will jump in and help out. This isn't something that needs to be in the permanent documentation. This is just a one time hiccup.
without starting a new thread, is there information on the easiest way to update from one revision to the next. Is there a way you can just load in the changes to a .ino file and then load away?
That is what that post was about. Unfortunately, we lost forward compatibility between versions. But this is a one time event. If you load your mesh, and do a G29 S-1 that will save your mesh to slot -1. Well, slot -1 doesn't exist. So the code is smart enough to know that it should dump the mesh to your host computer in a form that it can be feed back in later.
Take that output and cut and paste it to a file. Then update your firmware. Do a G28. And then 'Print' this file to it. You can do a G29 O to verify the new firmware was able to digest what you fed it. Don't do a save (G29 S1) until you visually confirm and like what it says your mesh is. Because once you do a save it will step on the old data.
Oooops... Sorry Wookie, I edited your post by accident... But the answer is here:
Thanks. Although I actually meant everything g else. Like delta settings and feedrate etc. Things that possibly are not in eeprom
No. All of that is OK. It was only UBL's EEPROM area that had its storage locations altered. UBL stores its stuff at the very end of the EEPROM and works towards the front. All of the other Configuration.h settings start at front of the EEPROM (actually... 0x100) and work towards the end.
It is only the UBL Mesh Data that needs to be migrated or rebuilt.
Sorry Roxy, i still think there is a miscommunication.
Im talking about things that is in the configuration.h, like feedrate and all that stuff. Lets say im on RC8, and I want to test RCbugfix. Is there a way that I can migrate all the alterations I have already made to my config, which would be things like homing feedrate, delta rod length z offsets, etc, into a new fresh copy of marlin. Is there some sort of configurator or something. Or do i need to go through Config.h and adjust each setting manually again?
Is there a way that I can migrate all the alterations I have already made to my config, which would be things like homing feedrate, delta rod length z offsets, etc, into a new fresh copy of marlin. Is there some sort of configurator or something.
There is a converter in development, but I can't find the link at the moment. Meanwhile, you can use a diff tool, such as the popular "diff" plugin available for Notepad++ to compare your configuration changes to the new default configurations and apply those changes.
Link yo the tool: https://github.com/cabbagecreek/Marlin3DprinterTool/tree/master/Marlin3DprinterTool
Regards/Saludos,
Ernesto.
On 5 Apr 2017, 05:51 +0800, Scott Lahteine notifications@github.com, wrote:
>
Is there a way that I can migrate all the alterations I have already made to my config, which would be things like homing feedrate, delta rod length z offsets, etc, into a new fresh copy of marlin. Is there some sort of configurator or something.
There is a converter in development, but I can't find the link at the moment. Meanwhile, you can use a diff tool, such as the popular "diff" plugin available for Notepad++ to compare your configuration changes to the new default configurations and apply those changes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6231#issuecomment-291642782), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPb1n-g_Y_a5R9YpPyiDHTDasB0PkLks5rsrtvgaJpZM4Mxq-g).
Thanks for the link, but that tool doesn't help me. I cant even figure out how to load it.
I dont need a configurator to setup marlin. I meant a configurator that finds the difference from an old version of marlin, to a new, But i guess its just notepad++ diff thing that i need to do
That is exactly what that tool does, but do whatever you want.
On 5 Apr 2017, 06:30 +0800, wookie666 notifications@github.com, wrote:
>
Thanks for the link, but that tool doesn't help me. I cant even figure out how to load it.
I dont need a configurator to setup marlin. I meant a configurator that finds the difference from an old version of marlin, to a new, But i guess its just notepad++ diff thing that i need to do—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6231#issuecomment-291654340), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPb3wH3_UNGppKPdxZwuaYeede8Sm-ks5rssSJgaJpZM4Mxq-g).
Great, can you possibly explain to me how to even load it up then?
also i go to www.marlin3dprinter.se and there is no website.
G29 O does nothing for me, is this still valid?
do a G29 S-1
save the output of the M420's. run that as gcode to reload the info
Thanks, that works but what should G29 O do and is it still required in marlin 1.1.5?
'O' doesn't exist any more. The 'G' option doesn't exist any more either. 'M' is gone...
The good news is they moved to non-gcode control letters.
How is this done now?
I want to be able to export ubl data, then import it after update?
The mesh data is saved at the end of the EEPROM. So even with a firmware change where the configuration data has changed... You can load the mesh. (This assumes your mesh dimensions are the same)
The other option is to do a G29 S -1 and it will generate a small GCode file that can be fed back to the updated firmware and that will reconstruct the mesh.
Thanks @Roxy-3D - it worked wonderfully. Such a time saver.
I used G29 S-1, so firmware outputs list to terminal.
I copied the data (select and copy) then paste to notepad++ file named mesh.gcode
striped out all but M421 commands.
G33 A C 0.138 P4 V2
SD card with mesh.gcode > print from SD card
G29 S1
G29 A
M500
M851 z-1.65
G33 P1
M500
The other option is to do a G29 S -1 and it will generate a small GCode file that can be fed back to the updated firmware and that will reconstruct the mesh.
i didnt realize G29 S-1 made the file also, even better.
@Roxy-3D I donated $100 to Scott L.
How can I also donate to you for all work and help??
I'm good! But Thank You for the thought!
Is there a reason that this doesnt work anymore? When I do a G29 S -1 nothing happens.
I use Bugfix 2.0
It should work... It is supposed to work... If it doesn't work, some small regression has crept into the code and we need to find it. (I'll try to remember to take a look at it later today when I'm back. But I don't have a machine to test on so maybe somebody else can take a quick look at what is happening.)
@jvdbrg — See what M420
says, and also see what M420 V
says.
I was stumbled that after a M420
and a M420 V
, G29 S-1
worked.
But than I realized that now I was using in the mesh slot 2. Switching back to the mesh in slot 1 re-introduced the problem of the mesh code not beïng produced.
After A M420
I've found the problem. The mesh was invalid because it wasn't fully populated. This results in marlin only displaying a ok instead of a mesh code.
So my problem is solved, but maybe it would be nice if Marlin produces an error message of some kind.
One answer might be to add the mesh validity status to the G29 W(hat) command. That might not be the best answer.
The mesh was invalid because it wasn't fully populated.
Should be simple enough to output a "mesh invalid" error when trying to enable an incomplete or invalid mesh. Due to recent changes the G29 W
option is only available when UBL debugging is intentionally enabled.
Been a while since I tried this.
Now on Marlin 2.0, download 5 days ago. LPC1768, skr v1.3 bigtreetech, 2208's.
Delta with ubl activated, mesh tweaked for nice 1st layer. Bed doesnt move. So once I have a good mesh I dont have to do bed leveling b4 every print.
Of course I'm tweaking lots of settings and trying different features etc,
G29 S-1 displays nothing??
How save mesh data between firmware flashes, especially if i have to initialize eeprom
With UBL, use G29 S<slot>
to save the mesh, and G29 L<slot>
to reload the mesh at the start of your print. For example G29 S0
and G29 L0
to save/load the mesh from the first slot.
This should survive firmware upgrades and EEPROM initialization (i.e. M502/M500).
If you need more help, please join the Discord channel. Github should not be used for support/configuration questions, only for actual bugs/development. Thank you.
Thanks for the response. I'm asking about missing functionality, something I was able to do b4, not support??
There used to be a way to save mesh data.
What if I want to be sure I'm on a totally new install of marlin, no old corrupt values?
Or I swap a faulty main board for same model
or what if whatever happens???
need a way to save mesh bed leveling data like b4.
Ah - I misunderstood. G29 S0
will save the mesh such that M502
won't overwrite it, but won't help if you replace the board.
However, G29 S-1
works for me. Did you load the mesh with G29 L0
before trying G29 S-1
?
For example G29 S0 and G29 L0 to save/load the mesh from the first slot.
This should survive firmware upgrades and EEPROM initialization (i.e. M502/M500).
EEPROM Slot 0 and 1 should always exist. But if we get too many configuration options saved in EEPROM, the higher slot numbers could become unavailable. They might not be preserved across firmware versions. But really... 3 or 4 slots will be available (even for big mesh's like 12 x 12). You probably don't need to worry about that.
And "Yes!", G29 S -1 will print your mesh in a form you can save it to your computer to be reloaded later or on a different board (on a different printer).
ok thanks for responding Roxy-3D.
This is my output from G29 S-1, just after a print finishes:
Recv: X:0.00 Y:0.00 Z:297.69 E:0.00 Count A:39872 B:39872 C:39872
Recv: ok P31 B2
Send: G90
Recv: ok P31 B3
[...]
Send: G29 S-1
Recv: ok P31 B3
[...]
Since it works for the two of you I'll try to figure why it isnt working for me.
This is output from G29 T:
Send: G29 T
Recv:
Recv: Bed Topography Report:
Recv:
Recv: ( -90, 90) ( 90, 90)
Recv: 0 1 2 3 4 5 6 7 8 9 10 11
Recv: 11 | . . . -0.805 -0.500 -0.505 -0.500 -0.500 -0.500 . . .
Recv: |
Recv: 10 | . . -1.000 -1.205 -0.800 -0.505 -0.500 -0.500 -1.000 -1.000 . .
Recv: |
Recv: 9 | . -1.000 -1.000 -1.105 -0.805 -0.500 -1.000 -1.000 -1.005 -1.000 -0.500 .
Recv: |
Recv: 8 | -1.200 -1.200 -1.200 -1.005 -1.200 -1.300 -1.070 -1.100 -1.000 -1.000 -1.005 -0.505
Recv: |
Recv: 7 | -1.100 -1.200 -1.100 -1.200 -1.300 -1.205 -1.105 -1.005 -1.300 -1.100 -1.000 -0.995
Recv: |
Recv: 6 | -1.305 -1.305 -1.205 -1.200 -1.300 -1.100 -1.200 -1.200 -1.195 -1.000 -1.100 -1.000
Recv: |
Recv: 5 | -1.300 -1.301 -1.000 -1.200 -1.300 -1.250 -1.100 -1.250 -1.200 -1.200 -1.200 -1.005
Recv: |
Recv: 4 | -1.300 -1.000 -1.000 -1.200 -1.300 -1.220 -1.250 -1.100 -1.000 -1.100 -1.100 -1.005
Recv: |
Recv: 3 | -0.400 -1.000 -0.805 -0.500 -1.200 -1.200 [-1.000] -1.000 -0.505 -1.200 -0.795 -0.500
Recv: |
Recv: 2 | . -0.200 -0.500 -0.800 +0.007 0.000 -0.805 -0.800 -1.000 -1.100 0.000 .
Recv: |
Recv: 1 | . . -0.200 -0.300 0.000 0.000 -0.495 -0.505 -0.500 -1.100 . .
Recv: |
Recv: 0 | . . . -0.200 0.000 0.000 -0.500 -0.510 -0.400 . . .
Recv: 0 1 2 3 4 5 6 7 8 9 10 11
Recv: ( -90, -90) ( 90, -90)
Recv:
Recv: ok P31 B3
Is this G29 S-1 actual now? This command is not working. I use Marlin 2.0.
G29 T
Bed Topography Report:
( -106,106) (106,106)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
14 | . . . . . . . +0.055 . . . . . . .
|
13 | . . . . +0.009 +0.017 +0.026 +0.030 -0.008 -0.066 -0.132 . . . .
|
12 | . . . -0.033 +0.007 +0.011 -0.001 -0.013 -0.045 -0.068 -0.108 -0.163 . . .
|
11 | . . -0.106 -0.073 -0.031 -0.005 -0.015 -0.055 -0.055 -0.070 -0.101 -0.151 -0.188 . .
|
10 | . -0.154 -0.097 -0.095 -0.080 -0.056 -0.044 -0.057 -0.066 -0.093 -0.126 -0.169 -0.187 -0.250 .
|
9 | . -0.129 -0.082 -0.083 -0.074 -0.095 -0.071 -0.054 -0.074 -0.111 -0.118 -0.162 -0.151 -0.209 .
|
8 | . -0.122 -0.067 -0.058 -0.067 -0.088 -0.077 -0.036 -0.038 -0.101 -0.120 -0.127 -0.106 -0.167 .
|
7 | -0.154 -0.107 -0.065 -0.056 -0.057 -0.037 -0.038 [-0.045] -0.058 -0.046 -0.109 -0.119 -0.107 -0.143 -0.168
|
6 | . -0.117 -0.069 -0.052 -0.045 -0.043 -0.079 -0.096 -0.085 -0.075 -0.098 -0.108 -0.082 -0.125 .
|
5 | . -0.152 -0.081 -0.064 -0.052 -0.046 -0.035 -0.111 -0.123 -0.082 -0.082 -0.115 -0.088 -0.103 .
|
4 | . -0.152 -0.108 -0.056 -0.044 -0.043 -0.073 -0.106 -0.108 -0.080 -0.072 -0.066 -0.083 -0.082 .
|
3 | . . -0.126 -0.088 -0.052 -0.057 -0.070 -0.105 -0.127 -0.095 -0.043 -0.073 -0.094 . .
|
2 | . . . -0.118 -0.072 -0.059 -0.058 -0.099 -0.105 -0.075 -0.066 -0.067 . . .
|
1 | . . . . -0.108 -0.077 -0.111 -0.148 -0.152 -0.095 -0.061 . . . .
|
0 | . . . . . . . -0.187 . . . . . . .
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
( -106, -106) (106, -106)
ok
G29 S-1
ok
G29 S-1
will only work if the mesh is valid. Your mesh has a lot of unfilled points (shown by '.' in the mesh above). Use G29 P3
repeatedly until all points have values, then the G29 S-1
should work.
Is this a delta? If so, it looks like there may be some work that needs to be done to allow saying that points are "not applicable" as opposed to "invalid" to avoid this in the future. But in the meantime filling the invalid points shouldn't hurt anything. You could also use M421
to explicitly set the "not applicable" points to 0 which should also work.
thank you! you saved me a lot of time 👍
@Roxy-3D Does it perhaps make sense for unified_bed_leveling::invalidate()
to set points outside the delta printable radius to 0.0 instead of NAN to help avoid this problem?
We already discussed another option I'll be working on probably next week.
Does it perhaps make sense for unified_bed_leveling::invalidate() to set points outside the delta printable radius to 0.0 instead of NAN to help avoid this problem?
At a minimum... There are corner cases where this idea doesn't work. For example, consider a Delta printer. The bed is circular. But the mesh is square. Some of the mesh points are outside of the usable bed area.
Those points that are off the bed are used in the Z-Height correction calculations. Setting them to 0.00 mm is probably not an ideal solution. And in fact, most Delta's have a 'Cup & Bowl' problem. The edge of the printable area tends to be either raised or lowered compared to the rest of the bed. Setting the mesh points off the bed to 0.00mm is almost certainly not the 'right' answer.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I'm good! But Thank You for the thought!