[REQUEST] Improved axis accuracy

[mylife4aiurr]

Its hard to interpret delta (circle) data in Cartesian (rectangle) format. should be a circle 0,0 as center of data points x/y scale should reflect delta radius or printable radius z scale lowest to highest probed points

http://forums.reprap.org/read.php?178,477060

If its too much work to make a specific view model for delta's let me know (your sweat) Just saying as is its more suited for prusa i3 style printers

[jneilliii]

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

[mylife4aiurr]

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

[jneilliii]

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

[jneilliii]

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/

[jneilliii]

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.

[mylife4aiurr]

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.

[jneilliii]

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

[jneilliii]

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.

[mylife4aiurr]

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

[jneilliii]

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

[mylife4aiurr]

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

[mylife4aiurr]

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

[jneilliii]

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

[jneilliii]

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.

[mylife4aiurr]

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

[jneilliii]

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

[jneilliii]

For the build volume section.

[mylife4aiurr]

[mylife4aiurr]

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

But its cool if you can pull dimensions from Octoprint also

[ajanky]

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.

[token47]

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.

[jneilliii]

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.

[mylife4aiurr]

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 😁

[jneilliii]

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?

[mylife4aiurr]

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.

[mylife4aiurr]

How does the Delta version looked graphed like that?

[jneilliii]

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.

[mylife4aiurr]

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)

[token47]

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,

[mylife4aiurr]

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.

[jneilliii]

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.

[jneilliii]

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

[mylife4aiurr]

@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. :(

[mylife4aiurr]

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

[jneilliii]

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.

[jneilliii]

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

[mylife4aiurr]

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

[mylife4aiurr]

yes, I will shortly

[mylife4aiurr]

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

[jneilliii]

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.

[jneilliii]

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.

[mylife4aiurr]

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

[mylife4aiurr]

M420 V (human readable)

G29 T1 (csv)

[jneilliii]

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.

[mylife4aiurr]

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

[jneilliii]

Thanks. Very interesting that they reversed the direction completely.

[jneilliii]

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.

[mylife4aiurr]

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.

[jneilliii]

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.

[token47]

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