0.91 - Z-probe causes Z-creep

[kyrreaa]

At first I thought I had a problem with my z-probe being too hard to push causing z creep. It turns out however to be creeping the wrong way, not backing off high enough before next probe. This is not noticable on a simple 3 point bed test, but when automating probing accross a full table with 289 measurement points it becomes significant.

My initial thoughts on the matter is it may be triggering the sensor, and then deciding to back up, but in the meanwhile the stepper loop continues to move a few more steps. If the reverse is based on the reading at point of triggering, not on the fial rest position after stop is confirmed this could lead to my observations.

Anyone else able to confirm this? It is aggravated by increasing probe speed.

[kyrreaa]

Code to test this (probes same point 20 times):

G0 Z<enter practical bed level atleast 3mm above expected tirgger of probe here> G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30 G30

After a few repeats you start seeing it change... It shouldn't!

[cakeller98]

interesting -

what if the Z-probe came down and triggered and backed off till it just un-triggered VERY SLOWLY, then triggered it again VERY slowly step at a time...

just a thought.

[kyrreaa]

Will not change the fact that the back move is relative and wrong... My printer has approx 140 steps/mm and indeed it looses about 1mm every 140 probes. This may be as simple as off-by-one... Will look into the code again.

[kyrreaa]

Hmm, looks like the actual steps and steps remaining is done and decremented in interrupt so the question is, is the endstops and z probing being checked inside or outside interrupt? Anywaym wouldn't this work better if it simply remembered where it was when it started the plunge, and went back there? Not via relative move, but via absolute?

[repetier]

I have tested the G30 command 100 times in a row with 80mm/step and it stays at the same height. With z probe speed 10 and 100mm/s.

Z probing is done in

float Printer::runZProbe(bool first,bool last)

which is called outside interrupts. It sends a large z move down. The nice thing about z moves is that one step steps down all steppers 1 step. So after z sensor is triggered the move stops as if finished and leaves the remaining steps in stepsRemainingAtZHit. This and endstop tests are done inside interrupts. Then this value is used to correct the current delta position and from there we go exactly as many steps upwards as counted down, so we should end at the same starting point, which my tests also verify.

What is a bit strange is that creating a height map 2 times gives 2 different results. It looks like it going up for y+. Will investigate that today. It is far from what you report, but perhaps the effect depends on geometry and yours triggers it more often. So there might be some problem, but currently I have no Idea what it could be. Investigating.

[kyrreaa]

Good, I also have a height map showing a very clear gradient along y. As I mentioned I run 140 steps/mm and have hacked the code now to force it to treat it as a big machine. I changed the 46000 limit to 42000 as I end up in the 42300 range. Will change it back and see if this is a "big" problem as I disabled a extruder and now have a smoother running system.

[repetier]

first tests show that this only happens when autoleveling is enabled. When it is disabled I get no more difference. So I guess the error comes somewhere from the constant enabling and disabling of autoleveling during measurement. bit have still to find where exactly it happens.

[kyrreaa]

I tried to only enable z probe as I did not want autolevelling. However 0.91 does not compile without also turning on autolevelling. Maby this is somehow related to the curved tracks that 0.91 makes on fast z-moves vs 0.83 ? It seems to be scraping the top of finished fills if they are large... (Sometimes forcing head low enough to cause misalignment from lost steps or even knocking the bed off it's supports!)

[repetier]

Ok I found the problem. Now a 10x10 measurement got from linear 0,5mm increase down to 0.16mm bump over complete bed. And that looks like wrong radius or rod size, which can hopefully be reduced further down.

The problem were the moves between measurement. The z-probe works with steps and at the end it computes z height from current steps position. That can give rounding errors based on position. Then you move xy taking the now wrong z (+rounding error) to new pos and measure again and add again rounding errors.

I also added repeated probing at one spot, so I can now build the mean value over e.g. 5 tests.For these I go only 0.5mm up with my hall endstop so it is really fast and adds to precision when measuring.

The changes were quite large, so I need to do some more tests before I release the new code. Now I have a new set of coordinates send over gcode and use these when a coordinate was omitted. That gives the best approximation.

[kyrreaa]

I found the creep happening without move too. Repeated G30's in the code would not give same result and would creep slowly downwards untill hitting bed.

Btw, wouldn't the correct z probe simply be to ask printer to move to x,y,z=0 and stop when it registers a hit? Then ask it to move back to x,y,zold that was remembered before starting the move? Since such commands work in absolute space and are calculated relative to a fixed point and delta moves are taken from current position to new position there would be no creep and no aggregated rounding error. It would also remove additional counting from the code which would speed stuff up.

[repetier]

While searching I made some changes to my runZProbe. I now have also a debug variable for stepped delta position to compare against computed/should deltaPositionSteps and at least now it is exactly set at the end. So I guess the changes made a difference.

[kyrreaa]

Latest fix in master fixes this. Before:

My workaround using homing between each:

And finally the new fixed routines with 5 samples in every point:

Beautiful!

[kyrreaa]

I think something is not fully right though... http://www.youtube.com/watch?v=3VTyg6rFFcE It seems to move to next pos before it reaches top of last z probe backmove.

[repetier]

It is not visible from the video, but did you start probing above the bed? All moves appear with pressed probe so I assume this was the height when you started the sequence. The idea is to start a few mm over it. The switch height is only for repetitions and after the last repetition it goes back to the origin height.

[kyrreaa]

The code is as you see in the post. G28 G1 Z23 F15000 X-120 Y-120 G30 G1 Z23 F15000 X-115 Y-120 G30 G1 Z23 F15000 X-110 Y-120 G30 G1 Z23 F15000 X-105 Y-120 G30 (and so on...) I go to Z23 before probing and get a result of 1.24mm approx. The "depressed" probe you see is not depressed, but it is still touching the board. Maby it is the "safe to disable" or something parameter you added allowing next move to queue in before the backmove? What is clear in the slow motion is the backmove is not run until after the new coordinates have been reached. It should have been fully completed before any new command is allowed to be executed. this leads to the rubbing of the probe along the bed. Then, it is lifted by the backmove before any new probe is run so it does not falsly trigger the next probe.

A good note btw: My Due arrived!

[kyrreaa]

By the way, when this works properly I will be making maps showing the actual effects of small changes to important settings such as Delta radius, Delta rod length, x y and z heights and their radius offsets. I think it will make it much easier for people to calibrate their printer if it is visually explained what the different settings can do, and how they will affect the other areas values. (It is quite clear that radius and diagonal rods interact in a complicated way causing adjustments of one to counteract adjustments of the other etc...)

[repetier]

Such a map gallery would be a great to learn calibration.

My problem is that I still do not see an error, especially when I do it slow and with good distances I see exactly what I expect.

define Z_PROBE_SWITCHING_DISTANCE 1.5 // Distance to safely switch off probe

Is the height the probe gets released between repetitions on one probe. When you would use Z30 the differences would be much better too see. Your code is not perfect btw. You enable/disable z probe for each test. Use G30 P1 for the first G30 P0 for all in between and G30 P2 for the last. This has of course only an effect if the probe is not at extruder position. That is how the host creates it's height maps. (do you use the host map function? It can also export values to excel)

[kyrreaa]

I have not seen any host map functions. I run V0.95D of Repetier Host and I see there is a new one available. My z probing is just for initial calibration work on a newly assembled delta. My future plans is to add a routine in the firmware that can measure 7 points and estimate the correct adjustments, an auto-calibration if you will. For this use, a nozzle-replacing z-probe seems best as it does not rely on offsets which will not be accurate untill calibration is finished. Since my Enable/Disable script is blank it does not matter if I enable or disable the probe, or so I thought. Thanks for the tip though. I agree it's nicer to do it properly.

I still claim that the next move is executed before the z backmove from the probe. Maby a queue problem?

It's like the Repetier host bug I am about to report regarding pause... It executes the end-code script when it reaches a pause at end of gcode-file and stats it is done, even though the printer is still executing the last part of the buffer and it's supposed to wait for use ok before sending more. (This will be a seperate bug though.)

[repetier]

It is in 0.95A-E in the Tools menu: Bed height map You set the rectangle and number of samples and it measures them all and paints a map. The copy to clipboard button saves the exact positions and height as a matrix.

Please try with z30 to make the error obvious. The code in runZProbe always has a wait until moves finished flag set, so it can not be an ordering problem.

[jamesarm97]

Is there a mac version that has this feature? The version numbers are different between the mac and windows version.

On Jan 13, 2014, at 9:10 AM, repetier notifications@github.com wrote:

It is in 0.95A-E in the Tools menu: Bed height map You set the rectangle and number of samples and it measures them all and paints a map. The copy to clipboard button saves the exact positions and height as a matrix.

Please try with z30 to make the error obvious. The code in runZProbe always has a wait until moves finished flag set, so it can not be an ordering problem.

— Reply to this email directly or view it on GitHub.

[kyrreaa]

Thanks! I missed it as it was grayed out (on my monitor at work it is barely visible due to the crappy monitor contrast). I expect it will be available for me on my home machine. Wish I had seen it sooner. Would have saved me from writing scripts to make gcode to probe, and also script to parse the data afterwards. Oh well, we learn, or at least pretend to...

Edit: It was grayed out as I was not connected to a printer here. It doesn't work with virtual printer btw... One would expect the virtual printer to be perfectly level. hehe.

[repetier]

@jamesarm97 No it is not included in the mac version.

@kyrreaa After connecting with real repetier firmware it is selectable :-)

[kyrreaa]

When using the bed map from the host app it travels at probe move speed from almost entire height of printer. This takes incredibly long. I suggest adding a Z start height to the menu so user can set a max height to probe from. This will speed up the probing by a day.

[repetier]

I always start it shortly over the bed, so it is fast:-) Perhaps I should add a comment to do so. I think this is safer then a fixed height as height might be wrong, especially when you du this the first time.

[kyrreaa]

Sorry, I see now it does not do any z moves so if I position it at a usefull height it will run the probe from that height. Saves a lot of time when probing at 10mm/s ! True, thanks. We responded simultaneously! Lovely function.

Oh, and a trick: If you run your filter backwards and forwards at half strength (aka on the mirrored data) you get a nice smoothing both left and right side. Do same for top/bottom too. A nifty way of doing it is a 180 rotate and refilter.

[kyrreaa]

I just tested the dragging. It only occurs if the probe height is less than the 1.5mm set in the firmware as safe height. Then it will indeed run thhe move before the last lift, atleast if you run G30 instead of G30 P0 etc... It's thus not a problem if height is over 1.5mm (default safe height).

[kyrreaa]

Awsome with a built in dialog for the bed scan btw. How would it be to have one for the delta calibration too? It's a lot of work getting those 7 important readings and tweaking the settings. Would be great to have them done by simply stating what radius you want to check. It would then do 7 probes: Center, L (150), X (210), F (270), Y(330), R(30) and Z(90).

That'd give you a "cake" with 6 pies and the lines dividing the pie can show the heights at the outer circumference as well as the joint in middle showing the center. Could be a very good tool for the calibration and only needs 7 readings vs a bunch for a whole bed in grid.

[repetier]

Sound good. Write measured heights along the points and to the right side the eeprom excerpt for these settings. Nice idea for a wizard in version 1.0.

[kyrreaa]

Thanks. I think it would help people understand more about how to tune it when they can see what changes after adjusting something. Reading those 7 points would be really quick with a probe. I currently use a script to do it as I tune my bed. It's still horrid, but at least it allows me to print 120x100 boxes now.

I still get a wierd slowdown on some upper corners like -100,-80 without understanding why. -100, -90 also goes like a crawl but then it's fast on -90, -80 etc. Must be a delta calculation thing. My work area is defined as -140 to + 140 in both directions. 0,0 as center. Delta rods are 300mm long so should reach +/-140 no? So why issue at +/- 100?

Edit: I see now 140x140 is overzealous by far. A radius of 150mm is more expected. That leaves out the corners. Maby the grid function should allow for radial probing so we could do the full radius leaving out the corners we'd get in the grid map?

[kyrreaa]

I am trying to add a an alternate probing response to the firmware but every value I send to the host is listed on a new line with OK [number] ? Edit: Found it, I was forgetting that every line executed lead to a ok from the printer to the host, thus fubaring my attempt at sending a bit of a line on every command.

I extended the probe allowing 4 (bit 2 in P) to be used to notify bare format. It prints the zprobe: text and value on first run, then value and nothing else for the mid and end runs giving a nice 1 column list. Makes it easy to paste into a spreadsheet to keep track of the results after a parameter change...

[repetier]

Near some edges the sliders have to go much faster then in the middle. That could be a problem depending on the speed you are going. I have made a excel sheet that shows how much steps the 3 sliders have to go for one step in a direction:

https://dl.dropboxusercontent.com/u/74036902/DeltaResolution.xlsx

Check it with your geometry and see if you are in linear or nonlinear range. I think deltas should only print in a range where the curves are quite linear and not in the steep descending area.

[kyrreaa]

Yes, you are right. I was sure I'd have a larger area based on my enlargement of the original Rostock but I guess the Rostock Max and such you guys are using is way bigger. Atleast wider...

[kyrreaa]

The calculation of speed for the sliders near the corners is wrong though. It reduces speed on the last segment or line, but does so to such a extent as to sometimes make the movement imperceptible. Waiting 2 minutes or more and it may reach it's destination, or at least a new segment and suddenly speed up.

The creep is most definitely gone now though. I've tested it rigorously. Now all I need to do is understand all the changes that happen in the 7-point results for any given change in the parameters.

[elidorz]

Hello guys

maybe someone could me with the z probe . my setup

firmware 0.91 ramp 1.3 simple mechanical switch windows 8

im trying to use z probe and i get no result , when im M119 im getting a read for all the endstop including the MIN Z , now when im trying to get a read with G30 command for the MIN Z im getting noting the reading keep saying Low (Like the end-stop doesn't working) .

i was checking my hardware and every thing seems to working fine . did i miss something here ? . i was doing z probe before on other system with no issues so whats wrong here appreciate your help

[repetier]

Hi,

z probe has it's own pin and should NOT be used as endstop. So disable min endstop and only set the pin for zprobe pin.

Yours Roland Littwin

2014-11-02 20:45 GMT+01:00 elidorz notifications@github.com:

Hello guys

maybe someone could me with the z probe . my setup

firmware 0.91 ramp 1.3 simple mechanical switch windows 8

im trying to use z probe and i get no result , when im M119 im getting a read for all the endstop including the MIN Z , now when im trying to get a read with G30 command for the MIN Z im getting noting the reading keep saying Low (Like the end-stop doesn't working) .

i was checking my hardware and every thing seems to working fine . did i miss something here ? . i was doing z probe before on other system with no issues so whats wrong here appreciate your help

— Reply to this email directly or view it on GitHub https://github.com/repetier/Repetier-Firmware/issues/213#issuecomment-61420384 .

Mit freundlichen Grüßen

Roland Littwin

---

Hot-World GmbH & Co. KG Knickelsdorf 42 47877 Willich Deutschland

Tel.: 02154-606518 Fax: 02154-606519

Geschäftsführer: Marcus Littwin Handelsregister: Amtsgericht Krefeld HRA 5325 Umsatzsteuer-Identifikationsnummer: DE213748632 Persönlich haftender Gesellschafter: Hot-World Medien GmbH mit Sitz in Willich Handelsregister: Amtsgericht Krefeld HRB 10800

[charlie2806]

What a pin please?

[repetier]

You can leave it on z min, but you have to set the z probe pin number to z min and disable z min hardware endstop.

[elidorz]

Hello

thank you Roland i was wondering about PIN 64 !!! , im using capacitive sensor so i guess the negative/signal wire will go to the pin and the positive wire from any 12 volts pin ?

best wishes

Elidor

[repetier]

Don't know about your sensor. Just make sure sensor pin gets only 5V not 12V!