Custom Z-probe question
Hi,
This is my 1st post here and I'd like to say BIG THANKS to the developers of Repetier-Firmware. I switched to Repetier 0.92 about 5 weeks ago after using different versions of Marlin and then Klipper and so far am extremely happy with Repetier's stability, reliability and performance.
I am in the process of designing my own 3d printed touch-based z-probe and have a question about the output signals it should generate.
During normal operation/printing, my z-probe's sensor-pin will be lifted and the output of z-probe will be HIGH. During bed leveling, when the pin is lowered, output will be LOW and will switch to HIGH when pin touches the bed. Could you please advice if such output from z-probe is supported and whether Z_PROBE_ON_HIGH should be set to 1 or 0. I have Z_max_endstop and will not be using z-probe as Z_min_endstop.
Another related question - does it matter whether z-probe's output is HIGH or LOW during the time when we are not running bed leveling?
Thanks
This is my 1st post here and I'd like to say BIG THANKS to the developers of Repetier-Firmware. I switched to Repetier 0.92 about 5 weeks ago after using different versions of Marlin and then Klipper and so far am extremely happy with Repetier's stability, reliability and performance.
I am in the process of designing my own 3d printed touch-based z-probe and have a question about the output signals it should generate.
During normal operation/printing, my z-probe's sensor-pin will be lifted and the output of z-probe will be HIGH. During bed leveling, when the pin is lowered, output will be LOW and will switch to HIGH when pin touches the bed. Could you please advice if such output from z-probe is supported and whether Z_PROBE_ON_HIGH should be set to 1 or 0. I have Z_max_endstop and will not be using z-probe as Z_min_endstop.
Another related question - does it matter whether z-probe's output is HIGH or LOW during the time when we are not running bed leveling?
Thanks
Comments
When probing start the signal must be low so it can switch high. However, there is a start and end gcode run to allow e.g. deploying the probe. I'm not 100% sure but think if you deploy it and add a small delay (G4) so that you know signal should be low when script finishes, I think the wrong signal on idle position should not hurt. I think the test happens after that.
I still have several questions and will post them here later this week.
1) To save time, I'd like to use 3x3 grid with G32 and 7x7 grid with G33. I know this is supported, but is this a good practice? What settings would work the best for 200x200mm heated bed?
2) The directions of probe moves, while processing G32 and G33 gcodes, are different. The images below depict that. Point P1 is next to Xmin/Ymin, P2 is next to Xmax/Ymin and P3 is next to Xmin/Ymax.
When running G32 head moves like this:
When running G33 - like this:
Is this expected behavior or I have something misconfigured?
3) Also, just curious about design decision - why not to use the shortest path shown below?
4) Finally, I got a problem with Octoprint's Bed Visualizer plugin. The bed is drawn flipped along Xmin/Ymin-Xmax/Ymax line, i.e. Xmin/Ymin and Xmax/Ymax corners appear at the right spots, other 2 corners are swapped. I posted question in Octoprint forum and waiting for the reply. Decided to mention it here as well in case somebody experienced the same and knows the solution. Plugin's FlipX and FlipY options do not help in this case. Could this be caused by the issue described in item 2) above? Here is my gcode from plugin configuration:
----------------------------
Thanks
2) Different routines and different definitions, so order can in deed differ, but that is no problem.
3) Code was easier and did not think of it. Maybe I change it some time.
4) Don't use Octoprint so can not say if the plugin has swapped something.
If I get my Octoprint issue resolved, I post here the solution.
void Distortion::showMatrix() {
-----------------------
with
-----------------------
Not sure if this needs to be fixed in Repetier or in the plugin. I reported the issue to plugin developer here
Thanks
I was able to modify measureAutolevelPlane function in BedLeveling.cpp and make probe move is zig-zag manner. It works on my Core XY printer. Please review below code and feel free to use it. I will try to do similar change to the routine handling G33.
Replace these lines:
with these:
Replace these lines:
Option 1 (starting point Xmin/Ymin):
Option 2 (starting point Xmin/Ymax):
Finally, here is time-lapse video showing the sequence of G32 S2 and G33 commands running on my printer after implementing these changes https://www.youtube.com/watch?v=ChvEcDOx-rE
Thanks
Thanks
going over x left/right with increasing y.
If it is same as G32 is not important. Selecting different points for G32 can rotate and mirror G32 behaviour. Hope this works as expected as I need to assemble the printer with z probe first.
Sorry, looks like I misread you post from Apr 27.