G26 tried to move X carriage off of end of axis #6646
Comments
|
The X & Y position get initialized at the start of the G26 to the current position if not specified: x_pos = current_position[X_AXIS];
y_pos = current_position[Y_AXIS];and then at the very end... The nozzle is moved back to the start position. move_to(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], 0); // Raise the nozzle
destination[X_AXIS] = x_pos; // Move back to the starting position
destination[Y_AXIS] = y_pos;
move_to(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], 0); // Move back to the starting positionAnd here is the other thing... x_pos & y_pos are used constantly as the algorithm tries to find the next closest mesh point that has not been processed yet. So if the pattern was drawing normally... that implies x_pos & y_pos were not corrupted (at least at that point in time). So... That is a long way of saying "I don't know what could have caused that!" |
|
I wonder if it's that I started the G26 outside of the UBL area (the bed minus the insets) ...? I'm not sure exactly where the Y was, but it's likely I was at the max limit for the axis, which is just outside the UBL area (I left a few mm off on that side) ... |
Oh!!! That may be part of the equation to re-duplicate this. Because G26 does try to go back to where it started! |
|
That's probably it. I'll try it in a bit. In other news, I'm currently extremely frustrated, as I can't get a decent mesh created -- every time I G29 P1 I get a different looking mesh (different z values), and G29 P2 B (which I like to use to fill in the rows the probe can't hit) is giving unexpected values (almost entirely inconsistent with the probed values) .. as in a P1-probed z value will be -0.050, which looks and is generally right, but the adjacent P2 B-probed z value will be +0.200 .. and my bltouch is good within 10um at the moment and my bed is pretty flat, so that's not really possible. I know it used to work, so not sure what happened... Maybe there was some random squaring-the-same-variable-instead-of-multiplying-different-variables or some other new maths applied somewhere. |
|
Does M48 give you good results? The G29 P1 code is fairly simple because it just invalidates the mesh and uses the standard lower level probe functions. It might be useful to do a G28 and a G29 P1 V4 and let it get a few points... Stop it and do another G28 and G29 P1 V4 and see if those points compare at all? And probably, for that little test, it makes sense to have the machine's heaters turned off. If you can't get any consistency with that little test... We may have a bigger problem with the probing sub-system. I sure hope that is not true. But that would explain some of the craziness we have been seeing. |
|
Yes. I'm averaging about 10um stddev, which is more than I used to have, but acceptable -- and certainly good enough for this purpose. Right now I'm going back to a broken branch I still have lying around (one of the ones before the optimization issue was sorted out) that I -know- worked very well (other than the memory issue) ... Will report on that shortly, then try your test if I'm no further along.
Yeah, there seems to be a lot of unusual stuff happening... |
|
edcffdc (version from ~3 weeks ago), bed cold, endstop interrupts (avg of 6, which is only ~60% of what I was getting earlier in the day (average of 10-11um) .. and better than anything I've seen recently .. also more consistent with what I used to see regularly) edcffdc, bed hot and stable (soaked for 20 min), endstop interrupts edcffdc, bed hot and stable, endstop interrupts off So this is no help. What I really don't understand is how a probe that can do this: Can also do this, without being touched: No way is the bed changing shape to that degree due to thermal or other effects. I saw only 35um deviation earlier with bang-bang (between heater on and heater off). I'm using PWM now and there's no more than 5um variation once the bed is to temp. I guess I'll go back to an even older version and try that. |
I have another idea... I have a 'brand new' probe from back when they were still hand assembling things... It has the 5 ms. pulse. If you are willing to bolt it on your machine with the dial indicator... We will know a lot more about what is going on.... |
|
I'm going to try my old one (which I don't necessarily think was damaged, now that I know the new one is doing similar things), but may take you up on that if I continue to struggle. Thank you. Going to revert to a Marlin version another week or so older than the one I just tried - the exact one I got the beautiful G26 prints out of, if possible. Am also going to spend some more time 'profiling' the bed to make extra-double-sure it isn't changing shape any more than I saw last time I checked. Obviously something is going on here... |
|
The thing is... The code that does the probing is a little bit convoluted... But the actual code that locks in the sampled points is pretty simple. I don't have the Git skills to look for changes in that code, but it is all down in the interrupt handlers. There is very little code involved in this. The one thing I'm wondering is: Did something happen such that the point is not being sampled as quickly? Did nested interrupts get turned on and thus we have a big delay because something (like the LCD Update) is happening after the sampled point triggers but before it got locked in? Or maybe the opposite... Maybe the processor is now in a timer update... and we have locked out interrupts from the probe coming in? What I'm getting at is: The actual code that locks in the points is pretty small and simple. If it didn't change... Maybe the timing of the code running did change? |
Can probably use 'blame', which is something available on github.com and is pretty easy to use. If you go to the source file (I assume the code in question is in Marlin_main.cpp) and then click the 'Blame' button in the upper right hand corner, it'll show you who the last person to change a particular line was. Not sure if you're familiar with that, but thought I'd mention.
That was one of my early concerns - a longer routine causing a delay that's preventing the detection of the endstop .. or maybe the triggering of an overlapping interrupt in the middle of that process .. I think either of those would explain why I see the axis moving further before stopping and reversing on 'bad' probes. But that doesn't explain why it happens when the bed is warm and not when it's cold. I just tried the Marlin version that gave me the beautiful G26 right out of the box/without any modification of the grid (which implies pretty strongly that the probing was really good/reliable) and I'm seeing the same 3-6um M48 sigma when cold. Haven't tried M48 hot or generating a mesh yet, but will shortly. Tweaking my bed leveling screws after rebuilding the bed just now, then going to 'profile' with the dial indicator to make sure it's stable when hot. |
This would be horribly brute force... But pulling that directory into a Visual Diff program and comparing against the current would tell us a huge amount. If that old version checks out... How about you .ZIP it up and post it here... I'll be able to help with the scavenger hunt. |
|
Thank you. Yeah.. we'll see here shortly. So far, the bed is really stable. It's going convex as it's warming up, but is stable with just a few um delta / min, so far. Nothing that would affect M48 even if it were in the middle of heating -- it doesn't run long enough for changes of this scale to matter. |
With the bed hot. No way did the bed change shape that much. It's stable at temp and +/- <2um currently. |
|
Notice that on the first few points all is well.. then starting with point 6 we have the exact same progressively-'worse' z that we saw before..... |
|
Same thing, again .. first few points fine, last points really 'off' .. watching dial indicator confirmed it. The axis started at and returned to 0.000 on the dial indicator, too, so no issue there. |
|
OK... Several questions:
Now some speculation... Is it possible we are seeing an electrical issue? The BL-Touch does suck a lot of current when it moves the pin. What if we put a 10,000 uf capacitor on its power??? Do we get better readings???? |
|
I'm following this conversation with atention. |
|
That is a good point. And remember... With BL-Touch probes we used to have to move fast because of the short pulse length. However... I think bgort is using interrupts and in theory... when it triggers, it should get the point very quickly. |
Yes. This is with RCBugFix from April 13 -- the one where I got the great G26 (and great real prints).
Yes, I believe so. And -- also, the weird issue where Z moves didn't match up on the dial indicator is completely gone. I don't know where I posted that, but it was like it was off by 32um, then 27, etc. at every 1mm step. This version doesn't have that issue at all -- it's dead on at every Z position.
I wondered/worried about this, too, so my BLTouch is on its own linear regulator (a Fairchild LM7805, which is really solid) with hefty caps. I really doubt that's the problem here. |
Good idea. Going to slow it way down now -- but why is it 'fine' when the bed is cold and not when it isn't? So I don't have to go looking, does manage_heaters() or the thermal ISR fire more often when target temps are set? |
OK... But... it seems like in a lot of your posts, 3 or 4 or 5 points are good... And then the numbers start getting bad. Is it an internal heat issue inside the BL-Touch? One thing that would be very easy to do is put a 30 second safe_delay() call inside of M48. If we do that... Do you then get 5 or 6 or 8 good points before they go to shit? |
No... I don't believe so. But depending on what the counters are doing.... there can be much more or less calculations being done. And obviously... If the heater is turned off... The calculations are not being done but this ISR is still happening. |
It doesn't do it when the bed is cold, and I can't imagine heat radiated from the bed is enough to throw things off in the BLTouch itself... I still need to try the blow dryer idea you had, though.
That's a good idea. I'll try that too. -- Here's 1/4 probing speed: So that's a significant improvement. Going to try this a few more times to make sure it isn't a fluke. Took forever.... And, yes I'm using interrupts. There doesn't seem to be any difference with or without interrupts, though -- does the same thing, more or less. |
and So maybe a fluke?? Look at the last points in that last one - progressively 'worse' starting at 4... |
|
Very strange.... some kind of acumulative error...? What if you reset your board and prior to each M48 test? |
|
Yeah... The big problem is we don't know what we are chasing... The 30 second delay between points in M48 is going to be interesting too... |
|
With a 30 second safe_delay between probes: I'm going to do this a few more times, and I'm also charging my thermal camera; will record the bltouch during a longer M48 to see if there's any noticeable deviation in temperature.... |
|
Wow!!! I know it is a total nuisance... But if 30 seconds between probes did this... I bet 60 seconds fixes the issue!!!! If so... The Antclabs people are going to want to know about this! |
|
Second time... |
|
Yes... Filling with the current_position[x & y] would be safe! So at that point... Down in LEAVE: destination[Z_AXIS] = Z_CLEARANCE_BETWEEN_PROBES; |
Yes... But there is no way knowing how quickly the nozzle will cross a line. I think it is best to just raise the nozzle, and then move... |
|
Another idea: G26 could be limited to x number of points, just like G29 P4 Rx. If I'm working on a certain area of the mesh, I may only want the nearest 5 points to print; that way I don't have to worry about stopping it manually. I imagine I can do that, too, if you're okay with it. |
|
I'm OK with that... But seeing if you can find that problem in ubl_motion.cpp is a bigger help.... |
|
I made it crash again by starting in the right rear corner. That's twice, so I suspect that's the way to reproduce it. Will check out the ubl_motion issue, though starting to fade for tonight... might end up being in the morning. I do need to get my debugger up and going. I have the connectors installed, but haven't made time to get avarice or openocd going. Decided I'm not going to fiddle with Atmel Studio, because I just don't like it at all. |
|
Oh, check this serial output: That's what I got when it crashed just now. |
|
Looks like the same bug, or very similar. Yep.... |
If I could set a hardware break point... I would be willing to use Atmel_Studio!!!! But if starting in the back corner can make it happen... Maybe I can do it. One problem is I have a 45mm inset too. So that might make it hard to happen. At least on my main printer. |
|
X0 Ymax did it for me twice. I think avarice and gdb are going to allow me to set hardware breakpoints, but we'll find out soon enough. |
Yeah... so for me... It might be (inset, Y-Max-inset) I'll try a few things and see! Thanks for the info!!! |
bgort
changed the title
|
Taking a look at this now... |
|
Is it time for the J-Tag Ice? |
|
Yeah -- approaching that point... |
|
No more need for this, I don't think, though I'm going to add the BLTouch and UBL tags because there's some good info here. |
|
@bgort @Roxy-3D Remember that I have seen the same behaviour earlier with a mechanical switch... So BLTOUCH could be eliminated The mechanic of the Z axis also can present some hysteresis (the thread of the Z rod, the screw, the lubricant, etc.)... By starting at the same height, a "tension" could be induced that gets released when homing or by waiting 30 seconds... my 2 cents... |
Hmm.. should be. That's definitely worth considering.
I've been wondering about these things (hysteresis, etc.) the most recently, as we're running out of other possibilities. I'm looking at replacing my leadscrews with ballscrews and anti-backlash nuts, though I may need to upgrade my Z steppers to support them. I still can't sort out why the probe is so accurate when everything is cold, but isn't accurate at all once things have warmed up. There's not enough heat anywhere to soften any of the printed parts holding things together, I don't believe, as my bed is only at 45C and nothing on the axis gets warmer than 4-5C above ambient. I'm using a PEI surface, and I don't think it softens in a way that could be detected by the BLTouch, as the pressure it exerts is virtually nil. I'm also considering integrating a laser triangulation sensor so as to both eliminate the BLTouch as a potential source of error, and also to enable faster, more accurate, more complete characterization of the bed, generally. Costly, though, and will involve a decent amount of work, including possibly the creation of an intermediate interface board, depending on the direction I go with it and how it actually works, which I'll know more about once I've got my hands on one (or I bother reading through the user manual...). Anyway, I appreciate the idea and your time. Will give some thought to altering M48. |
I doubt it will help... but would a drop of light oil on the threads where the nut is positioned help? |
|
Yeah.. I've thought about both oil and grease. May try it. Thank you. |
|
So we still have another bug... G26 just tried to raise the Z axis to the moon. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Was just printing a validation mesh and canceled by holding the control wheel because I wasn't getting good bed adhesion.
After cancel, G26 normally returns the nozzle to the coordinates it started at, but this time it tried to send the X axis off into never-never land (< X0) and I had to power down the printer to prevent damage.
I had started the G26 in the X ~0, Y ~310 corner.
The text was updated successfully, but these errors were encountered: