What G32 method and sensor type are you using? I had grid and 4 point symmetric working on bltouch and node sensor.
Also would a simple G30 work? Just to figure out if the bed leveling or measurement is crashing.
I wonder about the timeouts since we have busy protocol mentioning any longer pause. It is much stricter then marlins busy handling. Maybe you should also test with Repetier-Server as host instead. That increases g-code throughput plus we know our firmware better.
Regarding encoder - in which context does this happen? Menu/Value/Files on sd card?
Finally after 1.5 months of distraction (Covid included) I was able to resume working on this project. Here are my settings:
#define ENABLE_BUMP_CORRECTION 0 // CPU intensive, so only activate if required
#define BUMP_CORRECTION_START_DEGRADE 0.5 // Until this height we correct 100%
#define BUMP_CORRECTION_END_HEIGHT 2 // From this height on we do no correction
#define BUMP_LIMIT_TO 0 // Maximum allowed correction up/down, <= 0 off.
#define Z_PROBE_BORDER 35 // Safety border to ensure position is allowed
And here are my remaining issues:
1) G32 execution starts with homing Z, X and Y. I have opto-mechanical probe that is deactivated when printhead is homed. To activate probe I need to move printhead in a particular bed position where the magnet holding z-probe's visor is released. So I am doing couple of G1 moves to enable probe and then execute G32, which deactivates it again. Is there any way to avoid homing within G32?
2) After manually re-activating the probe while G32 is being executed, grid measurement starts but then something happens and bed crashes into the nozzle. I tried couple of times and it always crashes at the same spot (at the last measurement point in the 2nd row). Here is the log from Octoprint terminal window
I can see that the probe is triggered. Any ideas what can be causing this?
3) PID question. After PID tuning in Classic mode Extruder still overshoots requested temperature by 5-6 degrees. So when I set 240C for PETG it goes up-to 245-246 and then starts to come back and fluctuates between 238 and 242. Is this normal? PID tuning for heated bed worked perfectly. Temperature gradually increases to the requested value and stays there.
4) I still have problem with display encoder. Unless I turn it really slow, LCD goes blank and SKR2 hangs. The only way to bring board back to life is power cycle or by pressing reset button. Not sure if encoder uses interrupts, if yes - could it be that new interrupt from encoder comes in before the previous is handled? Never had issues with this LCD and encoder under Repetier 1.x. Although it should be mentioned that mainboard was different.
Any advises/suggestions will be very much appreciated.
ok = Motion1::moveByOfficial(Motion1::tmpPosition, Motion1::moveFeedrate[X_AXIS], false);
if (ok) {
ok &= ZProbeHandler::activate();
}
Here you see Motion1::homeAxes(axisBits[Z_AXIS]); but that should be no problem. Or does homing normally not work? The important part is I think that afterwards we call
ZProbeHandler::activate();
which activates the z probe. There is also a deactivate. The idea is to have a handler that takes care of what ever is required. So there you should run your sequence to activate probe and then it would always automatically happen when required. Or is tehre something preventing it to adding the gcode in activate/deactivate? I mean tehre is even a script for it already.
2) Recv: Error:Failed to trigger probe endstop! Bed crash? Well that sounds like it did not trigger. At least not when expected. Can it be, that you need a minimum starting distance to trigger? Not sure what probe you are using when it has a visor - whatever that means. But I know from bltouch that it has some timings and violations get errors.
3) Overshoot some extend is quite normal. You can only prevent overshoot if you come very slowly from below (might be why bed works better), but that means longer heat up times. This also depends on how much power the heater has - more power is easier to overshoot that a heater happy to reach a temperature at all.
4) Never had that. There is an encoder speed setting if it jumps more than one menu item per click you need to adjust that. What display type are you using? Character or 128x64 pixel. The latter need some time to update but haven't seen a crash due to fast changes. But you can use most of cpu when changing display quickly. Encoder is polled frequently in an interrupt, but execution is in main thread so we only buffer signals for execution. In V2 we use the newer LCD library. On some displays timings are quite critical sometimes. But I do not really see why encoder should have influence on it apart of more updates. Does cable run next to heater/motor cables so it might get bad signals? Does it happen when only powered from usb where that issue should not exist?
Many Thanks for quick reply. I made some progress with #1 and #2 but run out of time last night. Planning to continue tonight. So far I was able to put my probe activation code into Z_PROBE_START_SCRIPT. That took care of #1. I also increased Z_PROBE_SWITCHING_DISTANCE from 1.5 to 5. Looks like that helped with #2 as measurement went through all 25 points. However 2 new issues came up.
One is this: while measuring the distance to the bed (I have Z_PROBE_REPETITIONS 2) bed moves up and down twice, as expected, but then before moving printhead to the next position, it moves up and while printhead is relocating the probe pin touches the bed. It is very light touch way below probe's triggering point, but still would be nice to move print head while bed is at its lowered position after the last measurement. Simply looks like unnecessary extra move plus may cause bed scratching.
Another problem was that after completing 25 point measurement bed and printhead started to move unexpectedly which then turned into an attempt to run G32 again (the command was entered only once). Probe startup script was part of that run and because the initial position of the printhead in this case was not at Home it crashed into z-probe activator. I will rerun this tonight, film it and share the video on YouTube.
Not sure I understand correctly. Logic for 25 grid points is 1. Move to xy position 2. Probe and return to start height 3. If not finished start next point with 1.
So all xy moves should happen at same z height which is start height when you start. With repetitions the repetition is done from a lower z, but at end it should go back up to origin height. Sound like the 24 moves between measurements happen not at first z height or if z is moving while xy is changing. Would be both bad. You can debug this easily when you activate move debugging. Compile with
#define DEBUG_MOVES 1 in configuration.h at top area. Then activate it by enabling echo debug M111 S7 Then you see in log all executed moves and it is quite easy to see if there is a move you did not expect/want.
What are the script codes you run? Especially the deactivate code might be an issue with your repeated G32. Not all gcodes are allowed if they cause a recursion. E.g. G32 in deactivate script will always restart until firmware crashes.
My Z_PROBE_START_SCRIPT contains the string "G1 X0 F6000\nG1 Y193 F4000\nG1 X50\nG1 Y50"
Z_PROBE_FINISHED_SCRIPT and Z_PROBE_RUN_AFTER_EVERY_PROBE are empty.
As it can be seen from the video both print-head and bed make lots of unnecessary moves. Below I tried to describe them with timestamps
0:00-0:20 - Initial homing after executing G28
0:20-0:33 - homing that happens at the beginning of G32
0:33-0:47 - bed moves up then down while print-head moves at certain (random??) position
0:48-0:51 - Z_PROBE_START_SCRIPT is executed and the probe is dropped down (activated)
0:52-0:54 - print-head moves towards the first measurement point but then by some reason moves to the same (random) spot that it was before executing Z_PROBE_START_SCRIPT. At the same time bed makes few extra moves up and down.
0:54-0:58 - print-head moves back to the 1st measurement point and starts probing
0:59-1:06 - bed goes up and down twice (Z_PROBE_REPETITIONS = 2) then moves up to the point where probe pin touches the glass, but the probe is not triggered yet and while it is in that position print-head moves to the next point of the grid.
1:07-4:24 - the remaining 24 points are measured the same way.
4:24-4:27 - bed moves down then stops. Print-head moves to the same (random) position as at the beginning of the measurement.
4:28 -4:40 - bed goes down and does Z-homing. XY axis do not home, i.e. the probe is still activated.
4:41-4:47 - print-head moves to another random position close to the middle of the bed. At the same time bed moves up until probe is triggered once again. Then bed goes down a little bit.
4:48 - 4:51 print-head moves towards probe activator from the opposite side and crashes into it.
4:52 - 4:59 print-head moves towards the first measuring point, then returns to the center of the bed and this completes leveling.
I am really puzzled about the purpose of all these extra moves. Maybe they all are needed, but user'd expect just the following G32 functionality. If G28 has been executed after powering up the board - no need to run it again. Execute Z_PROBE_START_SCRIPT. Move print head to the 1st position of the grid and start measuring. Run Z_PROBE_RUN_AFTER_EVERY_PROBE if configured. Keep bed down while moving between points. After measuring the last point execute Z_PROBE_FINISHED_SCRIPT. Finally home all axis and update EEPROM if S1 switch is present.
Sorry for the long post but I decided to paste the serial log of the measurement, although it is not from the same measurement as on the video. At the very end of this attempt to run G32, after measuring all points and crashing into probe activator, print-head also crashed into the bed which caused the major error and mainboard restarted. I hope this log can shed some light on this strange behavior.
I think your Z_PROBE_BED_DISTANCE is quite low. This has the effect that the normally lower Z_PROBE_SWITCHING_DISTANCE is now higher, so at end of test it goes down to bed distance which is where it might scratch.
Your random position should be bed center I think. After homing for z max measurement we go to that position as it is in general the most save position across all printers to activate/deactivate probes.
I increased Z_PROBE_BED_DISTANCE from 4 to 12 but that made things even worse.
Right now studying Leveling::measure(GCode* com) code and trying to debug every move.
Meanwhile, could you please confirm that Z_PROBE_BORDER value should be greater or equal than absolute values of Z_PROBE_X_OFFSET and Z_PROBE_Y_OFFSET to avoid crashing onto one of the printer's side panels?
Z_PROBE_BORDER has nothing to do with offsets. It is used to create the grid size. We use the bed size (not reachable area) and subtract Z_PROBE_BORDER from all sides to be sure to be on the bed as sensors wont work outside bed. If offsets require more reduction they should get added automatically. So normally Z_PROBE_BORDER is maybe 5mm for physical sensors. Magnetic/optical sensors may need more distance to bed edge if that has an influence.
Spent several hours during the last weekend troubleshooting the issue with practically no progress. Unfortunately with my next long trip quickly approaching, I won't be able to keep working on this. For now I will through in other firmware to have running printer and hopefully will get back to this later this year.
For measuring we use the defined bed size minus Z_PROBE_BORDER, so make sure bed position/size is set correctly.
Can you explain how to set the bed position correctly? I can't get away from the edge of the bed on Y axis. I tried adding 10mm to Z probe border and I affected the X the way I expected. Then I thought maybe I had the wrong sign on the Z probe offset for Y axis. Your saying offset has no affect. So how can I get away from the edge of the bed? Plenty of room on the other end of the bed. I've defined everything in firmware host and the server. I have the same issues on other printers too with different FW. I'm missing something? Please define bed position settings.
So Y_MIN_POS .. Y_MIN_POS + Y_MAX_LENGTH is the allowed range for bed. This is described by BED_Y_MIN .. BED_Y_MAX. In case eeprom is enabled you can change values there and it may be there that your area is set too small.
Comments
Also would a simple G30 work? Just to figure out if the bed leveling or measurement is crashing.
I wonder about the timeouts since we have busy protocol mentioning any longer pause. It is much stricter then marlins busy handling. Maybe you should also test with Repetier-Server as host instead. That increases g-code throughput plus we know our firmware better.
Regarding encoder - in which context does this happen? Menu/Value/Files on sd card?
For measuring we use the defined bed size minus Z_PROBE_BORDER, so make sure bed position/size is set correctly.
Thanks
Here you see Motion1::homeAxes(axisBits[Z_AXIS]); but that should be no problem. Or does homing normally not work? The important part is I think that afterwards we call
which activates the z probe. There is also a deactivate. The idea is to have a handler that takes care of what ever is required. So there you should run your sequence to activate probe and then it would always automatically happen when required. Or is tehre something preventing it to adding the gcode in activate/deactivate? I mean tehre is even a script for it already.
2) Recv: Error:Failed to trigger probe endstop! Bed crash?
Well that sounds like it did not trigger. At least not when expected. Can it be, that you need a minimum starting distance to trigger? Not sure what probe you are using when it has a visor - whatever that means. But I know from bltouch that it has some timings and violations get errors.
3) Overshoot some extend is quite normal. You can only prevent overshoot if you come very slowly from below (might be why bed works better), but that means longer heat up times. This also depends on how much power the heater has - more power is easier to overshoot that a heater happy to reach a temperature at all.
4) Never had that. There is an encoder speed setting if it jumps more than one menu item per click you need to adjust that. What display type are you using? Character or 128x64 pixel. The latter need some time to update but haven't seen a crash due to fast changes. But you can use most of cpu when changing display quickly. Encoder is polled frequently in an interrupt, but execution is in main thread so we only buffer signals for execution.
In V2 we use the newer LCD library. On some displays timings are quite critical sometimes. But I do not really see why encoder should have influence on it apart of more updates. Does cable run next to heater/motor cables so it might get bad signals? Does it happen when only powered from usb where that issue should not exist?
1. Move to xy position
2. Probe and return to start height
3. If not finished start next point with 1.
So all xy moves should happen at same z height which is start height when you start. With repetitions the repetition is done from a lower z, but at end it should go back up to origin height. Sound like the 24 moves between measurements happen not at first z height or if z is moving while xy is changing. Would be both bad. You can debug this easily when you activate move debugging. Compile with
in configuration.h at top area. Then activate it by enabling echo debug
M111 S7
Then you see in log all executed moves and it is quite easy to see if there is a move you did not expect/want.
What are the script codes you run? Especially the deactivate code might be an issue with your repeated G32. Not all gcodes are allowed if they cause a recursion. E.g. G32 in deactivate script will always restart until firmware crashes.
Your random position should be bed center I think. After homing for z max measurement we go to that position as it is in general the most save position across all printers to activate/deactivate probes.
Bed must be within the rectangle described by allowed positions
So Y_MIN_POS .. Y_MIN_POS + Y_MAX_LENGTH is the allowed range for bed. This is described by BED_Y_MIN .. BED_Y_MAX. In case eeprom is enabled you can change values there and it may be there that your area is set too small.