Strange homing behavior
-
@Phaedrux said in Strange homing behavior:
Do you have a Duex?
M584 X0 Y1 Z2:9 E3Drive 9?Indeed, I have one and it is connected.
If so, you may want to define it here:
[...]Added
M350 E16 I0No interpolation for the poor extruder?
I had some strange behaviors in the past with the original extruder. That may be different now with the bondtech. Well, I added it. Lets see later how that works now.The M140 must come before the M143 for your bed heater.
[...]Done!
M600 isn't a beep. It's a filament change pause.
[...]You are right, my bad. I wanted to change the frequency, which ended in the "double comand" and not "double frequency". Typo, I removed all of the beeps in the meantime anyway. They where for debug only anyway.
I'm actually wondering if some of your comments are being parsed strangely.
[...]Indeed, that is a very good idea. I removed all the URLs and removed other things like "°". Just in case, that would not be the first time that I have bombed a parser with unexpected characters.
Can you send M558 P1 and G31 and see if it echoes back the same values as in config.g?
Update:
I tested/played a bit with the setup to understand the behavior better.
Let me describe it like that: The "homeall.g" seems to work from time to time when "z" is not far away from the bed surface. But sometimes it drives into the bed.
It seems that it gets triggered in the air only when "z" is more than 10cm away from the bed when I power on the printer. It works or drives into the bed when the head is below 5cm away from the bed.
Did it make myself clear?
Does that makes any sense to you?Cheers, Chriss
-
I thought we would at elast get something back from M558 P1.
Please try sending the full M558 command from your config.g in the console.
I can't remember if I asked before, but can you send M98 P"config.g" and see what you get for errors and messages?
-
@Phaedrux said in Strange homing behavior:
I thought we would at elast get something back from M558 P1.
Please try sending the full M558 command from your config.g in the console.
I did not fully understand what you mean.
I added "M558 P1" at the end of config.g, without any result. I do not see any output of that, nowhere.I tried telnet:
[chriss@leela ~]$ telnet 192.168.1.170 Trying 192.168.1.170... Connected to 192.168.1.170. Escape character is '^]'. M558 P1 okI can't remember if I asked before, but can you send M98 P"config.g" and see what you get for errors and messages?
I guess that you mean "M98 P"0:/sys/config.g""
[chriss@leela ~]$ telnet 192.168.1.170 Trying 192.168.1.170... Connected to 192.168.1.170. Escape character is '^]'. M98 P"0:/sys/config.g" HTTP is enabled on port 80 FTP is enabled on port 21 TELNET is enabled on port 23 Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 270C Warning: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 486C okSo no parsing error if you where aiming for that.
Cheers, Chriss
-
I mean send this in the console
M558 P1 C"^zprobe.in" H5 F120 T6000
G31 P500 X-26.0 Y-9.0 Z1.85And then try your homing.
Though I'm starting to wonder if it's something wrong with the IR probe itself.
-
@Phaedrux said in Strange homing behavior:
I mean send this in the console
M558 P1 C"^zprobe.in" H5 F120 T6000
G31 P500 X-26.0 Y-9.0 Z1.85And then try your homing.
Done, with the same result, the probe get triggered in the air.
Though I'm starting to wonder if it's something wrong with the IR probe itself.
I have to admit that you may be right. I have in total 3 of the ir-probes here. Two for my corexy build and the one in my CR10.
I replaced the one at my CR10 now with a other one. That seems not brand new any more, but it seems to work now. :?
But it is a bit to early for me to blame the bl-touch. I will play a bit more with the new one before I will confirm that the new one is working.And I will put the suspicious probe into the corexy for some tests.
-
Can you explain the homeall.g to me, please?
I'm fully confused now. I removed the "M98" so source the homez.g from the homeall.g. So it looks like that now:; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v2.1.8 on Sun May 10 2020 08:05:32 GMT+0200 (Central European Summer Time) G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-315 Y-315 F1800 ; move quickly to X and Y axis endstops and stop there (first pass) G1 H2 X5 Y5 F6000 ; go back a few mm G1 H1 X-315 Y-315 F360 ; move slowly to X and Y axis endstops once more (second pass) ;M98 P"0:/sys/homez.g"And you know what? The printer homes Z after it homed X and Y. WTF? I added a "beep" into the homez.g to test whether it get executed and not. And the printer beeped when I executed "G28" right after it homed X and Y.
So I think that the homez.g is executed whether I execute it or not.
Is that the expected behavior? -
@Chriss said in Strange homing behavior:
But it is a bit to early for me to blame the bl-touch. I will play a bit more with
Do you mean your "IR probe" is a BLTouch? This would not be an IR probe and is configurated differently.
-
@JoergS5 said in Strange homing behavior:
@Chriss said in Strange homing behavior:
But it is a bit to early for me to blame the bl-touch. I will play a bit more with
Do you mean your "IR probe" is a BLTouch? This would not be an IR probe and is configurated differently.
Ahhhh.. no.. it is a IR-Probe! Not a BL-Touch, I replaces the BL-Touch with the IR-Probe.. sorry for the confusion. Forget the BL-Touch please..... My bad.
-
@Chriss ok - this would be the easist solution
-
@Chriss if you run homeall and the Z is homed unexpectedly: do you have any special files lying around in the sys or macros folder, which could produce this behavior (tool changing, override,...)? To find the reason, you should delete every files and lines which are not needed. (backup all first)
-
Hmmm... maybe but I do not see it, to be honest. I downloaded the content from the sdcard and grepped a bit in the files. The only files I found, which contain "G30" are:
macros/00_Z-Level:G30 P0 X20 Y155 Z-99999; probe near a leadscrew, half way along Y axis macros/00_Z-Level:G30 P1 X250 Y155 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors sys/bed.g:G30 P0 X20 Y155 Z-99999; probe near a leadscrew, half way along Y axis sys/bed.g:G30 P1 X250 Y155 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors Binary file sys/Duet2CombinedFirmware.bin matches sys/homez.g:G30 sys/homez.g:;G30 ; home Z by probing the bed sys/homez.g:;G30I fully understand your approach but I do not see any unexpected file. Or a file which may have it's bits in the cake.
I'm still very confused that the IR probe, which caused all the problems in the CR10, works very, very well in the corexy. :?
Directory listing of the CR10:
ftp> cd macros 250 Directory successfully changed. ftp> dir 227 Entering Passive Mode (192,168,1,170,136,148) 150 Here comes the directory listing. -rw-rw-rw- 1 ftp ftp 641 Mar 12 2019 01-Test_IR_PD_Homing -rw-rw-rw- 1 ftp ftp 640 May 30 2018 02-Test_Fans -rw-rw-rw- 1 ftp ftp 1099 May 24 2018 03-Test_Heaters -rw-rw-rw- 1 ftp ftp 2223 Mar 12 2019 04-Test_motors -rw-rw-rw- 1 ftp ftp 156 Jul 15 2019 SETNETWORK -rw-rw-rw- 1 ftp ftp 434 Jun 07 2020 99_Chriss_Beep -rw-rw-rw- 1 ftp ftp 199 Jul 02 2020 00_Z-Level -rw-rw-rw- 1 ftp ftp 7 Jun 07 2020 Allow Cold Extrude 226 Transfer complete. ftp> cd .. 250 Directory successfully changed. ftp> cd sys 250 Directory successfully changed. ftp> dir 227 Entering Passive Mode (192,168,1,170,162,76) 150 Here comes the directory listing. -rw-rw-rw- 1 ftp ftp 462 Jul 02 2020 bed.g -rw-rw-rw- 1 ftp ftp 4782 Jul 03 2020 config.g -rw-rw-rw- 1 ftp ftp 483 Jun 22 2020 cancel.g -rw-rw-rw- 1 ftp ftp 1329 Jun 30 2020 stop.g -rw-rw-rw- 1 ftp ftp 4772 Jul 03 2020 config.g.bak -rw-rw-rw- 1 ftp ftp 277520 Feb 19 2019 DuetWiFiServer.bin -rw-rw-rw- 1 ftp ftp 3518 May 10 2020 config.json -rw-rw-rw- 1 ftp ftp 60164 May 03 2019 iap4e.bin -rw-rw-rw- 1 ftp ftp 843 Jun 28 2020 pause.g -rw-rw-rw- 1 ftp ftp 481 Jul 02 2020 start.g -rw-rw-rw- 1 ftp ftp 406 May 10 2020 resume.g -rw-rw-rw- 1 ftp ftp 181 May 10 2020 sleep.g -rw-rw-rw- 1 ftp ftp 716 Jul 02 2020 resurrect.g -rw-rw-rw- 1 ftp ftp 168 May 10 2020 tfree0.g -rw-rw-rw- 1 ftp ftp 228 May 10 2020 tpost0.g -rw-rw-rw- 1 ftp ftp 172 May 10 2020 tpre0.g -rw-rw-rw- 1 ftp ftp 126 May 17 2020 test1log.txt -rw-rw-rw- 1 ftp ftp 432 Jun 27 2020 test2log.txt -rw-rw-rw- 1 ftp ftp 354 May 10 2020 test3log.txt -rw-rw-rw- 1 ftp ftp 42 Aug 27 2019 test4log.txt -rw-rw-rw- 1 ftp ftp 506772 May 19 2020 Duet2CombinedFirmware.bin -rw-rw-rw- 1 ftp ftp 277520 Apr 29 2020 DuetWiFiServer-1.23.bin -rw-rw-rw- 1 ftp ftp 944 Jul 03 2020 homeall.g -rw-rw-rw- 1 ftp ftp 567 May 20 2020 homey.g -rw-rw-rw- 1 ftp ftp 210 May 10 2020 deployprobe.g -rw-rw-rw- 1 ftp ftp 566 May 20 2020 homex.g -rw-rw-rw- 1 ftp ftp 983 Jul 03 2020 homez.g -rw-rw-rw- 1 ftp ftp 432 Jun 28 2020 heightmap.csv -rw-rw-rw- 1 ftp ftp 213 May 10 2020 retractprobe.g -rw-rw-rw- 1 ftp ftp 509 Jun 23 2020 config-override.g -rw-rw-rw- 1 ftp ftp 40804 May 10 2020 Duet2CombinedIAP.bin -rw-rw-rw- 1 ftp ftp 3279 Jul 03 2020 dwc2settings.json 226 Transfer complete. ftp> -
@Chriss I can explain my approach: you say when you run homeall, your Z is homed. But homeall doesn't contain any Z movement (only Z5), so there must be anything which makes the Z movement to trigger the signal. So I thought, something automatic like a tool change (tfree, tpost), heating up or something other could trigger the Z movement.
Looking at your files, bed.g could be triggered somehow.
Other possibility: if you run homeall and the X and Y are already in their endstop positions, is there something specific so the IR probe triggers immediately? (is the position of the IR probe outside your bed, e.g.? => could be the case, as X is 26 and Y 9 mm off the nozzle. To try you could position X and Y somewhere in the middle of the bed before calling homeall) And if IR triggers if it is outside the bed, it may be that the probe must be inverted with a ! in the M558 C command and maybe reduce sensitivity value G31 P value.
-
@Chriss said in Strange homing behavior:
And you know what? The printer homes Z after it homed X and Y. WTF? I added a "beep" into the homez.g to test whether it get executed and not. And the printer beeped when I executed "G28" right after it homed X and Y.
So I think that the homez.g is executed whether I execute it or not.
Is that the expected behavior?That's pretty peculiar.
Can you add an M400 before the M98 to call the homez? That should ensure it's finished all the previous X Y homing moves before moving on.
-
Indeed, it is very peculiar. Well, I needed a break, to I used the weekend do work on my fun car, that was bit more promising.
I tested this morning 8-10 times with "G28" and all axes got homed. And this is the homeall.g:
; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v2.1.8 on Sun May 10 2020 08:05:32 GMT+0200 (Central European Summer Time) G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-315 Y-315 F1800 ; move quickly to X and Y axis endstops and stop there (first pass) G1 H2 X5 Y5 F6000 ; go back a few mm G1 H1 X-315 Y-315 F360 ; move slowly to X and Y axis endstops once more (second pass) M400 ;M98 P"0:/sys/homez.g"Yes, Z got homed and yes, the beep from the homez.g changed every time I changed it. So there can be no other file involved.
I do not know why but the trigger up in the air went completely away. :? All of my test this morning where successful. Do not ask my why, the only change from last week was a very, very long power cycle.
But it is very odd to see the homing of Z but you know that you do not execute it from homeall.g. :?
Anyway, my main problem, the trigger in the air, is magically gone now. I'm not sure if I want to touch that again or not, it is working for now.
-
Actually I think this is totally normal. Homeall is homing all axis. It completed the homeall.g and the z axis was still unhomed, so it executes home z.
