Next "z probe was not triggered during probing move" problem
-
Correct is:
M569 P1.0 S0 ; physical drive 1.0 goes backwards - rear motor M569 P1.1 S0 ; physical drive 1.1 goes backwards - right motor M569 P1.2 S0 ; physical drive 1.2 goes backwards - left motor
The motor movement is correct.
Cheers, Chriss
-
I would suggest a couple of things.
Firstly, you M584 needs to be in the same order as your probing etc.
So as you probe front left, front right and the rear, I would adjust your M584 toM584 Z1.2:1.1:1.0
Secondly, have you tried adjusting the motors (manually by hand) so the second and third probe points so they are higher than the first? (increase the dive height if you do this just incase its too much)
-
You are right, the order was wrong. Maybe a glitch from the build phase.
I lowered point 2 and 3, I did not raised them. That is actuall a good idea. But here comes the big "BUT". I get a new error from "G30".
Error: G30: Some computed corrections exceed configured limit of 30.00mm: -400.000 -400.000 -400.000
That comes now right at the center where the printer does it "G28" from the bed.g
bed.g
G28 ; home ;M401 ; deploy Z probe (omit if using bltouch) G30 P0 X20 Y63 Z-400 ; probe left leadscrew G30 P1 X380 Y63 Z-400 ; probe right leadscrew G30 P2 X195.5 Y330 Z-400 S3 ; probe leadscrew at the end G1 X200 X200 ; Back to the middle
config.g
; Configuration file for Duet 3 (firmware version 3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.1.1 on Thu Jun 04 2020 17:41:46 GMT+0200 (Central European Summer Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"Blimy" ; set printer name M669 K1 ; select CoreXY mode ;; Drives ; XY M569 P0.5 S1 ; physical drive 0.1 goes backwards - right motor M569 P0.0 S1 ; physical drive 0.2 goes backwards - left motor ;Z M569 P1.0 S0 ; physical drive 1.0 goes backwards - rear motor M569 P1.1 S0 ; physical drive 1.1 goes backwards - right motor M569 P1.2 S0 ; physical drive 1.2 goes backwards - left motor ; Extruder M569 P0.3 S0 ; Extruder Motor M584 X0.0 Y0.5 Z1.2:1.1:1.0 E0.3 ; set drive mapping M671 X-31.5:437.4:198.5 Y63:63:440 S30.0 ; Z-Level leadscrews at left (connected to E6(9)) and right (connected to E2) of X axis (S=MaxCorrection) M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation M92 X80.00 Y80.00 Z400.00 E420.00 ; set steps per mm M566 X900.00 Y900.00 Z12.00 E120.00 ; set maximum instantaneous speed changes (mm/min) M203 X30000.00 Y30000.00 Z300.00 E1200.00 ; set maximum speeds (mm/min) Z180 M201 X500.00 Y500.00 Z20.00 E250.00 ; set accelerations (mm/s^2) M906 X2500 Y2500 Z1000 E800 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X380 Y360 Z400 S0 ; set axis maxima ;; Endstops ##################### TODO M574 X1 S1 P"!0.io1.in" ;Induktions geber X1=low end ; configure active-high endstop for low end on X via pin io2.in M574 Y2 S1 P"!0.io2.in" ;Induktions geber Y2=High end ; configure active-high endstop for high end on Y via pin io1.in M574 Z1 S2 ; Configure Z-probe endstop for low end on Z ;; Z-Probe ; BL Touch: M950 S0 C"io7.out" ; create servo pin 0 for BLTouch M558 P9 C"io7.in" H5 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds G31 P500 X30 Y0 Z2.02 ; set Z probe trigger value, offset and trigger height ; IR Probe: ;M558 P8 C"0.io0.in" H5 F120 T6000 ; set Z probe type to unmodulated and the dive height + speeds ;G31 P500 X0 Y25 Z1.45 ; set Z probe trigger value, offset and trigger height ; M564 S0 to disable axis limits. ;M557 X10:380 Y40:380 P10:10 ; Chriss - define mesh grid M557 X50:350 Y50:350 P3:3 ; https://duet3d.dozuki.com/Wiki/Gcode#Section_M557_Set_Z_probe_point_or_define_probing_grid ;; Heaters ; Bed ; Tune in with: M303 H0 S60 (60=Temp) (M500 oo save) M308 S0 P"0.temp1" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin temp0 M950 H0 C"0.out2" T0 Q10 ; create bed heater output on 0.out2 and map it to sensor 0 and Frequency (Q) 10Hz M307 H0 A340 C140.0 D5.5 S1.0 V0.0 B0 ; disable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S120 ; set temperature limit for heater 0 to 120C ; Hotend M308 S1 P"0.temp0" Y"thermistor" T500000 B4723 C1.196220e-7 ; configure sensor 1 M950 H1 C"0.out3" T1 ; create nozzle heater output on 0.out3 and map it to sensor 1 M143 H1 S280 ; set temperature limit for heater 1 to 280C M307 H1 A340 C140.0 D5.5 S1.0 V0.0 B0 ; disable bang-bang mode for heater and set PWM limit ;; Fans ##################### TODO ; Fan for the printed part: M950 F0 C"0.out9" Q500 ; create fan 0 on pin 1.out4 and set its frequency M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off ; Fan for the Hotend: M950 F1 C"0.out8" Q500 ; create fan 1 on pin 1.out5 and set its frequency M106 P1 S1 H1 T45 C"Hotend" ; P="set fan 1" S="value" H="Thermostatic control Heater No." T=" is turned on at 45°C" ; Fan for expansion case Alwas on ;M950 F9 C"1.out8" Q500 ;M106 P9 S1 H-1 ; Tools ##################### TODO M563 P0 S"TooL0" D0 H1 F1 ; define tool 0 G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C ; Custom settings are not defined ; Miscellaneous #M501 ; load saved parameters from non-volatile memory M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss
Cheers, Chriss
-
Can you also comment out your M574 for Z.
The S2 option of M574 is intended for use only when axes other than Z are using the Z probe for homing. The only printers known that do this using Duet electronics are the RepRapPro Ormerod, Huxley Duo, and Mendel Tricolour machines. When using the Z probe to home Z, M574 Z0 should be used.
And can you edit your bed file so its Z-99999 and not Z-400 (thats your new error I think)
-
Yes, you are right, sorry, my bad.
I found the same a minute after your post in the docu.
Anyhow, I did what you say and lifted "right" and "back" a bit and they got triggered correctly:
Leadscrew adjustments made: -5.000 -5.000 -5.000, points used 3, (mean, deviation) before (-5.000, 0.000) after (0.000, 0.000)
The second run produced the same message. I kept my fingers on the leadscrews and I was not able to feel the "correction".
And it is the same result, the probe do not get triggered at P2 and P3 if P1 is higher than the two.
Cheers, Chriss
-
Just to make sure, can you move the Z probe from the Duet 3 to the Expansion board that you are running the Z motors on?
-
I tried "1.io5" (the only one the wires can reach) without any luck. The probe did not even deployed the probe with "M280 P0 S10".
The "self test" at the power on was fine.Is there a limitation where the probe can be connected on?
Cheers, Chriss
-
I'm more and more convinced that there is some kind of "protection" which prevents the FW to drive the bed closer to the nozzle then the Z-home or the "G30 P0".
-
It looks now like that: (In the case that I have P0 lower than the other two points)
08/09/2020, 17:47:53 G32 Leadscrew adjustments made: -5.000 -5.000 -5.000, points used 3, (mean, deviation) before (-5.000, 0.000) after (-0.000, 0.000) 08/09/2020, 17:46:22 G32 Leadscrew adjustments made: -5.000 -5.000 -5.000, points used 3, (mean, deviation) before (-5.000, 0.000) after (-0.000, 0.000)
And the "G29" has the same problem btw.
The behavior is exactly the same when I use "1.io4".
Cheers, Chriss
-
@Chriss said in Next "z probe was not triggered during probing move" problem:
G28 ; home
Can you post your homeall.g? I don't see it above.
Does it home correctly using the probe?
Please send M98 P"config.g" and report any errors. Also please post the results of M122.
-
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