Next "z probe was not triggered during probing move" problem
-
Hi @Phaedrux ,
Can you post your homeall.g? I don't see it above.
Here you are:
Homeall.g:M98 P"0:/sys/homex.g" M98 P"0:/sys/homey.g" M98 P"0:/sys/homez.g"
Before you ask:
homex.g; homex.g ; called to home the X axis ; ; generated by RepRapFirmware Configuration Tool v3.1.1 on Thu Jun 04 2020 17:41:46 GMT+0200 (Central European Summer Time) M400 ; make sure everything has stopped before we make changes G91 ; relative positioning ; home Y first G1 H1 Y420 F2500 ; Test the endstop G1 Y-15 F6000 ; go back a few mm G1 H1 Y55 F500 ; Do it one more time ; X Now ;G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-500 F2500 ; move quickly to X axis endstop and stop there (first pass) G1 X15 F6000 ; go back a few mm G1 H1 X-500 F500 ; move slowly to X axis endstop once more (second pass) ;G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning G1 X208 Y174 F2000 ; Center head to the middle M400 ; make sure everything has stopped
homey.g
M400 ; make sure everything has stopped before we make changes G91 ; Relativ positioning G1 H1 Y420 F2500 ; Test the endstop (F2400 to be fast enough for detection) G1 Y-15 F6000 ; go back a few mm G1 H1 Y55 F500 ; Do it one more time G1 Y-79 F6000 ; Move away from the end stop M400 ; make sure everything has stopped G90
homez.g
G90 ; absolute positioning G1 X208 Y174 F6000 ; go to first probe point M400 G91 ; relative positioning ;G1 H2 Z10 F6000 ; lift Z relative to current position ; Run 1 M558 F250 ; Chriss - set the down speed G30 ; home Z by probing the bed ;Run 2 M558 F60 ; Chriss - set the down speed G30 M558 F350
Does it home correctly using the probe?
Yes, yes... The probe works fine, all the time. As long as "P0" is LOWER than "P1+n" in the probing. (Zlevel or Mesh).
You can see that the bed stops moving up right before it touches the pin of the bltouch if P1+n" is HIGHER than "P0".
That is the reason that I believe that there is some kind of protection. (I tried "M564 S0" in the bed.g already)Please send M98 P"config.g" and report any errors. Also please post the results of M122.
M98 P"config.g"
Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365C
M122
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DJM-956L2-G43S4-6JTDL-3SS6L-1876H Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 154604 Dynamic ram: 162596 of which 60 recycled Exception stack ram used: 224 Never used ram: 75732 Tasks: NETWORK(ready,1980) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1452) TMC(blocked,204) MAIN(running,4952) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:01:57 ago, cause: software Last software reset at 2020-09-09 09:23, reason: User, spinning module LinuxInterface, available RAM 74492 bytes (slot 1) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 33.9, current 34.0, max 34.3 Supply voltage: min 20.3, current 20.3, max 20.3, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0 Driver 0: standstill, reads 52097, writes 14 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 52100, writes 11 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 52101, writes 11 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 52098, writes 14 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 52102, writes 11 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 52099, writes 14 timeouts 0, SG min/max 0/0 Date/time: 2020-09-09 09:25:35 Slowest loop: 4.08ms; fastest: 0.14ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon* is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 1.45ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 449, longest wait 2ms for type 6036 === Linux interface === State: 0, failed transfers: 0 Last transfer: 22ms ago RX/TX seq numbers: 3506/3508 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 31.43
Cheers, Chriss
-
@Chriss said in Next "z probe was not triggered during probing move" problem:
Is there a limitation where the probe can be connected on?
Yes there are limitations:
Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.3.0.
If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.3.0.https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations
Does this affect you?
-
jay_s_uk mentioned that already. So I connected the Z-Probe to the extension board some posts ago.
And I do not have the problem that the motors do not stop, they stop to early. The stop at the absolute height of P0 before P1+n hit the z-probe.
The "z home" works perfectly.It seems to me that the "G30" at "P1+n" do not ignore the z height measured with G28 or G30 at "P0", so it stops before it hits the probe. I do not know how to explain it better, I hate it when I have to explain technical things in a foreign language and I'm not sure that I made myself clear.
Would a video help?
Cheers, Chriss
-
Would you be able to do a test in standalone mode so we can narrow down if it's a limitation/problem in the SBC interface?
A separate SD card with your /sys and /www folder is all that's needed. Disconnect the SBC and put the SD card into the Duet.
-
You, Sir, challenged me this evening.
0: I had no feasible sd card around, so I had to remove a node out of my raspberry cluster.
1: I was not able to get the Ethernet connection working. I used M55? to set the IP and the netmask after I did not see any requests on the dhcp server. Well.... I connected my Panedue at the end because the Ethernet will not be a permanent thing anyway.
2: I have destroyed my X endstop holder during all of that and I have so spare on stock, sidechannel problem. I fixed it with a oversized amount of gaffer tape. (I guess that I have to rename the printer to "Angus" (MacGyver).)3: I added three config changes to my config.g: M55[2|3] and M575. So I was able to execute G32 via the PaneDue finally but with the same result: Works fine for "G28" and if P0 is lower than P1 but not if P0 is higher than P1.
In short: No difference in the behavior.
Should I try the beta of 3.2?
Is there a way to run "whatever" in debug? To understand what happen internally when it stops? In my world would I do something like "bla_daemon -vvvv -d" or "strace bla_daemon". If you know what I mean.
I feel so helpless here that I have no way to make the firmware more verbose.
Cheers, Chriss
-
@Phaedrux said in Next "z probe was not triggered during probing move" problem:
If you use a Z probe then the Z motors must be connected to the main board.
I don't think it's enough to move the z probe to the expansion board. The limitation says the z motors and z probe must be on the main board.
-
@Chriss said in Next "z probe was not triggered during probing move" problem:
Should I try the beta of 3.2?
I don't think that will help because it was work planned for 3.3 release according to the note. Checking if that's still the case.
-
Well well... that will blow up my cable management.. but "all for the results".
I will test that later, I'm awake for 24 hours now. I'm on my way to bed already.
Thanks for your brilliant support and patience with me.
Cheers, Chriss
-
For clarity:
- Z motors should always be connected to the main board when a Z probe is used. This is a limitation of the firmware, and even when it is removed it will still be desirable in the interests of low latency.
- The Z probe can be connected to an expansion board. However, if communication between the main board and the expansion board is lost (which should not happen, but I am aware of two users reporting it happening), the probing move will not be stopped. Firmware 3.2beta includes an additional check that the the expansion board is communicating and knows about the Z probe at the start of the probing move. Meanwhile I suggest using reduced Z motor current during probing.
- Other axis motors can be connected to other boards, however there is a limitation on endstop switches, and a bug in 3.1.1 and earlier. The limitation is that an endstop switch connected to the main board cannot stop a motor on an expansion board unless a motor on the main board is also moving. The bug is that under some conditions, homing an axis motor connected to an expansion board doesn't work when there are multiple axis motors. The bug is fixed in 3.2beta.
-
Thanks for the explanation!
I will rework my wiring and I will connect all motors which move all axes motors to the board. The 0.1 is "short to ground" unfortunately. So I need the expansion at least for one motor which will no the the extruder.One more comment: (A bit of-topic here)
Could you please ad a comment on "https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter" about the "G1 S" change on "Testing motor movements" with FW 3.x?
I run every time into the same problem that I have to use "G1 H" now. Thanks!Cheers, Chriss
-
Thanks for pointing that out. I have corrected it.
-
Thanks, I will do a "quality test" later.
-
@Chriss said in Next "z probe was not triggered during probing move" problem:
The 0.1 is "short to ground" unfortunately.
Are you aware of the issue with certain Duet 3 main boards reporting short to ground when they should not? If you have one of the affected boards, you are most certainly entitled to a warranty replacement.
-
I saw that yesterday, no my boards starts with "WD31". And I was not able to find the diods on the pcb (compared with one of the pictures in the other thread) I guess that the board layout has changed... Anyhow, other problem, maybe something we can talk in a other thread about.
Cheers, Chriss
-
OK, feel free to start another thread. If you do, then please post a photo of that area of the board, because a missing resistor can also cause that issue.
-
I'm more than sorry. I have to admit that I wasted alot of our time with my concept of wiring.
It works now! I connected all motors for the axes directly to the mainboard and the extruder only to the extension board.
Jay was more than right with his initial theory. I should have followed his idea straight. I have to admit that I was to bullheaded with my cable management. I'm more than sorry and I can not apologize enough.
It may be a good idea to mention the situation with the endstops and the motors in the "get started with duet3" or somewhere close to it. That may be helpful for the next newcomer.
Cheers, Chriss
-
glad you got sorted in the end.
no time has been wasted by anyone.