My bad. On further checking, Marlin is generating the matrix, and Pronterface is just reporting what Marlin is sending it. The problem is in Marlin. Discovered by enabling "#define DEBUG_LEVELING_FEATURE" in Marling Configuration.h, and then issuing "M111 S32" from Pronterface and then running G29. A detailed report to Pronterface shows Marlin is the culprit.
Like my tag says:
Often in error, but rarely in doubt.
ORIGINAL POST:
I am using Pronterface Printrun 2014.08.01 to operate a MendelMax running Marlin 1.1.0-RCBugFix on a Rambo. I use G29 before each print to auto bed level bilinearly. I told Marlin to use 12 points. It samples as follows:
10 11 12
9 8 7
4 5 6
3 2 1
where 1 is the lower right corner of the bed and 10 is the upper left of the bed.
When the samples are completed, Pronterface shows a matrix in its sidebar that orders the data correctly from left to right, but upside down top to bottom.
The data is displayed as:
3 2 1
4 5 6
9 8 7
10 11 12
Has anyone else noticed this? I am hoping my son-in-law ( an uber-coder ) can fix the Pronterface Python file so it generates the measurement data in the correct order.
I have every reason to believe that Marlin is applying the data correctly to compensate for bed leveling, and the error is in how Pronterface displays it.
Edited 3 time(s). Last edit at 03/14/2017 09:34AM by PJMoore.
Often in error, but rarely in doubt.
