[REQUEST] Improved axis accuracy about octoprint-bedlevelvisualizer HOT 52 CLOSED

just a short note here: if you read the bed dimensions from the Octo profile, what about scaling the Z axis relative to bed size: I (feel) the z-error representation is too dramatic, since it always scales to full range, even if the max error is very little.

from octoprint-bedlevelvisualizer.

duplicate of #20 I'm close to getting one that works for all.

from octoprint-bedlevelvisualizer.

I was trying to break up the issues.
1 issue for if data is displayed to user - cartesian or delta
1 issue for how data is displayed for delta user

from octoprint-bedlevelvisualizer.

I understand now. Correct, display at all vs display as round surface for delta.

from octoprint-bedlevelvisualizer.

General for delta, not just mine.
Pull data from Topography Report
(0,9) (9,9)
(-98,98) min (98,98) max
that will have actual ranges
-(1/2min) x(0) +(1/2max)
-(1/2min) y(0) +(1/2max)

what do you think?

Let's keep them separate. Here's your last post relative to the graphing issue. I don't quite understand what you mean. I'm not really great with the Math involved with this. I do think I can get it to work once we can get the data in a format that plotly can interpret. May have to use a different type of 3d graph like a 3D scatter plot.

https://plot.ly/javascript/3d-scatter-plots/

or possibly tri-surf

https://plot.ly/javascript/trisurf/

from octoprint-bedlevelvisualizer.

I was able to move the axis on plotly create to shift by adding X and Y.

but the visual representation of the data is still skewed.

from octoprint-bedlevelvisualizer.

ok thanks for separating issues.
Im hoping to have the ranges used for delta printers be more representative of their actual bed dimensions. for a delta is double radius or bed diameter or printable area. So how does one get that range to show in a graph??
your pluggin pulls the bed dimensions when it pulls the topography report:
(0,9) (9,9)
(-98,98) (98,98)

Im asking that the pulled bed data be actual the x and y range for the graph shown.
So in above example
-1/2(98) = min x range graphical
1/2(98) = max x range graphical
so the x range:
-49 -40 -30 -20 -10 x 10 20 40 49

-1/2(98) = min y range graphical
1/2(98) = max y range graphical
so the y range:
-49 -40 -30 -20 -10 x 10 20 40 49

by definition a circle will have same radius all around, really no need to do calculations for x and y separately.

so maybe 1/2 of whatever largest number, maybe quick dirty way to get xy range to display on graph
(0,9) (9,9)
(-98,98) (98,98)

but the main point I'm trying to get across is having 0,0 center of graph like actual bed, like pic above in 1st post this issue.

from octoprint-bedlevelvisualizer.

I think our posts may have crossed, So axis like in above screenshot I just posted?

from octoprint-bedlevelvisualizer.

I realize it's not the actual dimensions, but at least is showing the probe points relative to center axis the same as with the cartesian one. I've been wanting to add more accurate representation of those anyway, so this would definitely need to be accounted for.

from octoprint-bedlevelvisualizer.

thats better then b4. glad 0,0 is center of graph, better than 0,0 lower left like cartesian

but why ranges
x -4 to 4
y -4 to 4

from octoprint-bedlevelvisualizer.

That's how plotly interprets it for some reason. The cartesian one does similar, if you supply 10 points it shows 9x9.

from octoprint-bedlevelvisualizer.

ok ok i understand.... not trying to add extra work for u.

you are trying to use same model for both kinds of printers, i get it

from octoprint-bedlevelvisualizer.

so bed size isnt passed to plotly? only plotted points?

from octoprint-bedlevelvisualizer.

Exactly, plotly interprets those, I just pass it an array.

from octoprint-bedlevelvisualizer.

But I'm only passing the z coordinates, not the x and y. That was going to be my next phase of revisions, pulling the dimensions from OctoPrint printer profile configuration and supplying it points based on the size of the array of points from the data collection.

from octoprint-bedlevelvisualizer.

well ok there u go...... :)

from octoprint-bedlevelvisualizer.

Can you send me a screenshot of what you printer profile in OctoPrint looks like?

from octoprint-bedlevelvisualizer.

For the build volume section.

from octoprint-bedlevelvisualizer.

from octoprint-bedlevelvisualizer.

Seems topography report pulls radius.... which would need to be doubled

But its cool if you can pull dimensions from Octoprint also

from octoprint-bedlevelvisualizer.

As I said on #34 (now closed), it would be great to have Z scale fixed (and configurable, maybe). This is the text from the other bug:

"I noticed that as I try to level the bed, the inclination on screen always stays the same, and what changes is the scale on the Z axis. This is technically correct, but is hard to work with. It would be better if the scale was fixed and you could see the plane changing inclination on the screen until it's horizontal. I suggest a fixed scale of 2mm as a starting point. If my bed is more dis-aligned than that, I wouldn't mind to see parts of graph off screen anyway."

This would be a great addition together with the changes proposed on this one.

from octoprint-bedlevelvisualizer.

I understand what you mean. I just did a quick test manually on the plotly site putting in the x and y axis probing points and I think the z axis will naturally scale more appropriately. But with +/-2mm on the z it doesn't look bad, thanks for the suggestion.

from octoprint-bedlevelvisualizer.

I think we are on to something here..... I love the z offset idea. Looks great. Also I noticed your graph has an actual bed scale that match's your beds length and width. I like 😁

from octoprint-bedlevelvisualizer.

I agree. The toss up now is if I fake the probe points just by dividing the bed dimensions by the number of points in the mesh data, or actually pull those from the report. The problem again with the later is dealing with all the different variations of bed leveling reports from the different firmware variants. I think going the lazy programmer route (that's me) of just dividing would be appropriate enough for most people.

What do you guys think?

from octoprint-bedlevelvisualizer.

This is your pluggin and your sweat. If you go the lazy route maybe put a disclaimer outlining the reasons the data set is divided so graph and actual bed isnt a 1:1 representation.
Or force the user to use either human readable or csv so that u cut the variations you have to program for. Or some other criteria that makes less work for you but allows you to use actual data points.

from octoprint-bedlevelvisualizer.

How does the Delta version looked graphed like that?

from octoprint-bedlevelvisualizer.

From the previous data this is what the Delta would look like. I know it's not as smooth as your initial screenshot but definitely is more legible than before.

from octoprint-bedlevelvisualizer.

That looks so much better then before, and I feel even though same data it looks closer to reality. Hope I can express my point, but before the z values were so extreme as though - how do you even print on a bed that warped. This version definitely a big improvement. (I know your working on a circle version for delta)

from octoprint-bedlevelvisualizer.

I agree. The toss up now is if I fake the probe points just by dividing the bed dimensions by the number of points in the mesh data, or actually pull those from the report. The problem again with the later is dealing with all the different variations of bed leveling reports from the different firmware variants. I think going the lazy programmer route (that's me) of just dividing would be appropriate enough for most people.

What do you guys think?

I almost sent you a suggestion about that, then I thought that it would make no difference in practice. The best you can do is work with the points you have, and the graph will represent only that, not the whole bed. You would have to extrapolate and do complicated math that maybe will be a best guess anyway,

from octoprint-bedlevelvisualizer.

Is there way to represent the unknown region. We know the total bed dimensions from Octoprint profile. We know the area the probe points cover. Can u show unprobed area as grey as in lacking data. If can't visually show an unprobed area, disclaimer that unprobed areas could be lower or higher than probed area. Simply no way to tell. U can imply a tilt based on preceding points but as suggested by token47 that's just a guess at best.

from octoprint-bedlevelvisualizer.

That type of predictive math on the mesh would be beyond my capabilities I'm afraid. It would also go against the lazy programmer method I'm leaning towards already. I'll probably continue to work on this aspect of the plugin later down the road, but for the initial release of "improved accuracy" I think division of bed size is going to be the fastest approach. I plan on working on it this weekend.

from octoprint-bedlevelvisualizer.

I just pushed a new branch 0.1.0 with the improved graphing. I tested with my cartesian and it's working as expected. I took the lazy programmer route as previously discussed so the points aren't exactly accurate, but I think it's definitely a better representation of the bed overall and gets the point across.

I tested also by setting by printer profile to circular and it does shift the axis correctly for me, hopefully my math is good enough to work for you real delta guys on here. Please give it a test and let me know how it goes.

Install using this url: https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/0.1.0.zip

from octoprint-bedlevelvisualizer.

@jneilliii Glad your still working on this pluggin.
Version 0.1.0 results
Only csv output works for me at this time, yes I did ctrlf5 after install, and I changed appropriate Data Collector Flag between tries.

Pic above from ver0.1.0
x axis has 0 in middle. (-80 0 +80) :)
y axis wrong. wanted 0 in middle like x axis :(
z seems to start at 0 as well, I preferred the z at -2 or some negative number to see under bed like b4. :(

from octoprint-bedlevelvisualizer.

I know you are pulling printer dimensions from Octoprint profile.
Suggest displaying to delta's differently based on if the form factor is circular in the profile.
Then Cartesian's would see origin lower left 0,0
Delta's would see center 0,0

from octoprint-bedlevelvisualizer.

I'll look into the y axis issue. It should have worked, but I may have gotten the logic wrong. I agree with you, I think the max on z range needs to be lowered instead of the total height of the build volume, the min z range is already set at -2, but because the max is so high it changes the perspective.

from octoprint-bedlevelvisualizer.

@mylife4aiurr, can you upload your config.yaml settings for this plugin now that you've pulled the data?

from octoprint-bedlevelvisualizer.

Ok as pointed out in #40....... newest marlins changed how human readable output for M420 V and G29 T looks. So I bet its throwing your interpreter off. csv output is unchanged in newest marlin so it works with your pluggin. Anyone using older marlin versions should be ok with your pluggin, human readable or csv.

So just sayin its not an error with your pluggin rather marlin got updated. You are aware? i think

from octoprint-bedlevelvisualizer.

yes, I will shortly

from octoprint-bedlevelvisualizer.

current config.yaml

  bedlevelvisualizer:
    command: 'G28

      G29 T1



      '
    mesh_timestamp: 4/28/2018, 6:40:25 PM
    report_flag: 'Bed Topography Report for CSV:'
    save_mesh: false
    stored_mesh:
    - - ''
      - '0.109'
      - '0.018'
      - '-0.037'
      - '-0.032'
      - '-0.000'
      - '0.007'
      - '-0.026'
      - '-0.060'
      - '-0.022'
      - '-0.001'
      - ''
    - - ''
      - '-0.026'
      - '0.003'
      - '-0.032'
      - '-0.054'
      - '-0.011'
      - '0.003'
      - '-0.021'
      - '-0.035'
      - '-0.025'
      - '-0.011'
      - ''
    - - ''
      - '-0.001'
      - '-0.019'
      - '-0.013'
      - '-0.043'
      - '-0.003'
      - '-0.015'
      - '-0.037'
      - '-0.053'
      - '-0.064'
      - '0.015'
      - ''
    - - ''
      - '-0.002'
      - '0.004'
      - '0.012'
      - '-0.013'
      - '0.010'
      - '-0.040'
      - '-0.065'
      - '-0.064'
      - '-0.069'
      - '0.043'
      - ''
    - - ''
      - '0.054'
      - '0.054'
      - '0.010'
      - '-0.000'
      - '-0.022'
      - '-0.057'
      - '-0.078'
      - '-0.061'
      - '-0.058'
      - '0.087'
      - ''
    - - ''
      - '0.179'
      - '0.085'
      - '0.030'
      - '0.005'
      - '-0.019'
      - '-0.040'
      - '-0.051'
      - '-0.030'
      - '0.087'
      - '0.193'
      - ''
    stored_mesh_x:
    - -100
    - -82
    - -64
    - -45
    - -27
    - -9
    - 9
    - 27
    - 45
    - 64
    - 82
    stored_mesh_y:
    - -100
    - -82
    - -64
    - -45
    - -27
    - -9
    - 9
    - 27
    - 45
    - 64
    - 82

from octoprint-bedlevelvisualizer.

I just noticed, the new output from marlin is interpreting a full grid now in lieu of the NaN that you were getting before from G29 T1? Also looks like my collector is not stripping out the z data correctly either because each row has a blank on each end.

from octoprint-bedlevelvisualizer.

Just re-pushed the 0.1.0 branch with a theoretical fix for the G29 T not getting data in bugfix. Let me know if that's working for you now please.

from octoprint-bedlevelvisualizer.

Will upgrade and post results of re-push of 0.1.0 between G26 bed mesh validation iterations.

from octoprint-bedlevelvisualizer.

M420 V (human readable)

G29 T1 (csv)

from octoprint-bedlevelvisualizer.

Well, that gets us closer than before. It's at least pulling data albeit looks like it's pulling large values, hince throwing off the view. Anything outside of the z range of -2 to 2 gets cut off and that why you only see the blue parts. Can you do me a favor and in the terminal do G29 T and copy/paste the received commands from the collector flag down into a code block? I think that will be quicker than me merging the latest bugfix into my set-up.

from octoprint-bedlevelvisualizer.

Send: G29 T
Recv: echo:Home XYZ first
Recv: 
Recv: Bed Topography Report:
Recv: 
Recv:     (  -98, 98)                                                                              ( 98, 98)
Recv:         0       1       2       3       4       5       6       7       8       9      10      11
Recv: 11 |   .       .       .       .       .       .       .       .       .       .       .       .
Recv:    |
Recv: 10 |   .       .       .     -0.010  -0.065  -0.020  +0.030  +0.050  -0.065    .       .       .
Recv:    |
Recv:  9 |   .       .     +0.110  +0.060  +0.070  +0.070  +0.050  +0.145  +0.020  +0.025    .       .
Recv:    |
Recv:  8 |   .     +0.210  +0.120  +0.065  +0.065  +0.100  +0.110  +0.075  +0.140  +0.080  +0.100    .
Recv:    |
Recv:  7 |   .     -0.026  +0.105  +0.065  +0.050  +0.090  +0.105  +0.080  +0.065  +0.075  +0.090    .
Recv:    |
Recv:  6 | +0.100  +0.105  +0.080  +0.085  +0.060  +0.200 [-0.015] +0.060  +0.050  -0.064  +0.015    .
Recv:    |
Recv:  5 | +0.150  -0.002  +0.105  +0.110  +0.095  +0.205  +0.060  +0.040  +0.035  -0.069  +0.043    .
Recv:    |
Recv:  4 |   .     +0.160  +0.155  +0.110  -0.000  +0.080  -0.057  -0.078  +0.045  -0.058  +0.087    .
Recv:    |
Recv:  3 |   .     +0.280  +0.185  +0.195  +0.105  +0.085  -0.040  +0.050  +0.070  +0.087  +0.193    .
Recv:    |
Recv:  2 |   .       .     +0.340  +0.255  +0.150  -0.008  -0.026  +0.060  +0.180  +0.196    .       .
Recv:    |
Recv:  1 |   .       .       .     +0.280  +0.155  +0.104  +0.090  +0.205  +0.198    .       .       .
Recv:    |
Recv:  0 |   .       .       .       .       .     +0.200  +0.200    .       .       .       .       .
Recv:         0       1       2       3       4       5       6       7       8       9      10      11
Recv:     (  -98,  -98)                                                                              ( 98,  -98)
Recv: 
Recv: ok P15 B3

from octoprint-bedlevelvisualizer.

Thanks. Very interesting that they reversed the direction completely.

from octoprint-bedlevelvisualizer.

I just pushed the 0.1.0 branch with some drastic changes. Not sure how well it will work out for the deltas, but it has simplified the data collection process drastically. I'm utilizing a custom GCODE command to trigger the start of the data collection process now, so no longer necessary to enter a Data Collector Flag in settings. Rearranged the settings a bit to clean it up, and added some axis logic. I'll start testing your report tomorrow to see what other adjustments may be necessary.

from octoprint-bedlevelvisualizer.

Had a chance to test 0.1.0 again since yesterday.

X axis presentation :)
Y axis presentation :)
Z axis presentation - Luv z floating. You can really get a sense of the deviation above or below z0.

from octoprint-bedlevelvisualizer.

Just pushed 0.1.0 again with changes that resolves the delta collector and a couple of other bug fixes...looks like your data is graphing as expected in my virtual testing using the virtual_level_report_delta_marlin_bugfix.gcode file and virtual printer connection configured as a 200mm diameter circular profile.

and the stored data...

That should put this branch ready to release, but I'd like for you to test on your end if you don't mind.

from octoprint-bedlevelvisualizer.

Should 0.1.0 appear as a update on octoprint yet? Iḿ not receiving it automatically.

from octoprint-bedlevelvisualizer.

Not yet, I was waiting for some delta testers to verify it's working correctly prior to release. You'd have to install manually from the url below.

https://github.com/jneilliii/OctoPrint-BedLevelVisualizer/archive/0.1.0.zip

from octoprint-bedlevelvisualizer.

I received notification after I went to sleep. I quickly tested this morning new repush of 0.1.0.
It worked as expected. Pulling data, displaying data, flipping axis etc. The saved data field looked normal and formatted in a circle for delta, nice. I like how you broke out the x and y off the to side in data field.
Only thing I need to look farther into is it seems when I flip x or y the saved data points get misaligned in the data field. But this could be because I didn't refresh data, after flipping y. I'll check more after work tonight.

from octoprint-bedlevelvisualizer.