RRF3 and Duet wifi + Duex5
-
you'd probably need to include the
homeall.g
,homez.g
,homex,g
andhomey.g
files to see whats going on there(also please put
```
on a line over and under each section of config file to make it easier to read. thank you) -
@beachtec the homing files are important.
What you can test as a first step is whether your XYZ axis are where you expect them to be, following https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter#Section_Testing_motor_movement
But with RRF3 the syntax changed from S to H, so instead of G1 S2 use G1 H2 etc.
Just move a little distance, so you don't get problems reaching the endstops.G31 X and Y coordinates are still 0 each, please set offsets for probe and correct the M557 so the BLtouch is always in the region of the bed.
If e.g. the BLtouch has X-20 Y-20 (left in front of nozzle), then M557 would need to be M208 X0 plus 20 of G31 => minimum X20 for M557 starting position. -
@beachtec said in RRF3 and Duet wifi + Duex5:
; Endstops
M574 X1 S0 P"xstop" ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S0 P"ystop" ; configure active-high endstop for low end on Y via pin ystopI think the issue may be here. S0 is not supported in RRF3. Instead you'd use S1 and a ! in front of the pin name to invert the signal. If you post the error message it gives when you try to home we may see it say something to that effect. or that endstops aren't configured?
So you could try
M574 X1 S1 P"!xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"!ystop" ; configure active-high endstop for low end on Y via pin ystop
Or perhaps you don't need the ! at all and simply
M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop
Would do. It depends on if the switches are normally open or normally closed.
-
Thank you for responding. First off...
; homez.g G91 ; relative positioning G1 H2 Z10 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 X150 Y150 F6000 ; go to first probe point G30 ; home Z by probing the bed ; Uncomment the following lines to lift Z after probing ;G91 ; relative positioning ;G1 Z10 F100 ; lift Z relative to current position ;G90 ; absolute positioning ; homex.g G91 ; relative positioning G1 H2 Z10 F6000 ; lift Z relative to current position G1 H1 X-305 F1800 ; move quickly to X axis endstop and stop there (first pass) G1 X5 F6000 ; go back a few mm G1 H1 X-305 F360 ; move slowly to X axis endstop once more (second pass) G1 H2 Z-10 F6000 ; lower Z again G90 ; absolute positioning ; homey.g G91 ; relative positioning G1 H2 Z10 F6000 ; lift Z relative to current position G1 H1 Y-305 F1800 ; move quickly to Y axis endstop and stop there (first pass) G1 Y5 F6000 ; go back a few mm G1 H1 Y-305 F360 ; move slowly to Y axis endstop once more (second pass) G1 H2 Z-10 F6000 ; lower Z again G90 ; absolute positioning ; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time) G91 ; relative positioning G1 H2 Z10 F6000 ; lift Z relative to current position G1 H1 X-305 Y-305 F1800 ; move quickly to X or Y endstop and stop there (first pass) G1 H1 X-305 ; home X axis G1 H1 Y-305 ; home Y axis G1 X5 Y5 F6000 ; go back a few mm G1 H1 X-305 F360 ; move slowly to X axis endstop once more (second pass) G1 H1 Y-305 ; then move slowly to Y axis endstop G90 ; absolute positioning G1 X15 Y15 F6000 ; go to first bed probe point and home Z G30 ; home Z by probing the bed ; Uncomment the following lines to lift Z after probing ;G91 ; relative positioning ;G1 Z10 F100 ; lift Z relative to current position ;G90 ; absolute positioning
I made a change after reading the feedback here to the M574 X1 & Y1 stop commands which cleared them up. BUT... the home Z is sill toast; the command moves the probe inboard a bit, deploys it, and starts indexing the bed up to meet it. The probe does turn blue and then changes over to blinking red after a bit of contact... the z-probe display on the Duet Web Control page never shows a value... and I am making up that is why the z-axis never stops indexing. So close here... but a little brain fried over this. The BL touch responds to commands. UGH!
; Configuration file for Duet WiFi (firmware version 3) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"My_Nightmare :)" ; set printer name M669 K1 ; select CoreXY mode ; Network M552 S1 ; enable network M586 P0 S1 ; enable HTTP M586 P1 S0 ; disable FTP M586 P2 S0 ; disable Telnet ; Drives Definitions M584 X0 Y1 E3 Z5:6:7 ; set drive mapping ; Stepper configuration M569 P0 S0 ; physical drive 0 X Stepper M569 P1 S1 ; physical drive 1 Y Stepper M569 P3 S0 ; physical drive 3 Extruder M569 P5 S0 ; physical drive 5 Front Left Z Stepper M569 P6 S0 ; physical drive 6 Rear Left Z Stepper M569 P7 S0 ; physical drive 7 Right Z Stepper ; Motor Dynamics M350 X16 Y16 Z16 E16 I1 ; configure micro stepping with interpolation M906 X1400 Y1400 Z1000 E1344 I30 ; set motor currents (mA) and motor idle factor in % M201 X3000 Y3000 Z100 E750 ; set accelerations (mm/s^2) M203 X24000 Y24000 Z900 E3600 ; set maximum speeds (mm/min) M566 X1000 Y1000 Z10 E500 ; set maximum instantaneous speed changes (mm/min) M92 X160.00 Y160.00 Z3200.00 E873.08 ; set steps per mm M906 X1400 Y1400 Z1400 E1344 I30 ; set motor currents (mA) and motor idle factor M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z-0.5 S1 ; set axis minima M208 X300 Y300 Z600 S0 ; set axis maxima ; Endstops M574 X1 S1 P"!xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"!ystop" ; configure active-high endstop for low end on Y via pin ystop M574 Z0 S2 ; configure Z-probe endstop for high end on Z ; Z-Probe M558 P9 C"^!zprobe.in" H10 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds M950 S0 C"duex.pwm1" ; create servo pin 0 for BLTouch G31 P500 X172 Y186 Z2.5 ; set Z probe trigger value, offset and trigger height M557 X15:250 Y15:250 S20 ; define mesh grid ; Heaters M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin bedtemp M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0 M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit M140 H0 ; map heated bed to heater 0 M143 H0 S160 ; set temperature limit for heater 0 to 160C M308 S1 P"e0temp" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin e0temp M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1 M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit ; Fans M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency M106 P0 S1 H1 T45 ; set fan 0 value. Thermostatic control is turned on M950 F1 C"fan1" Q500 ; create fan 1 on pin fan1 and set its frequency M106 P1 S0 H-1 ; set fan 1 value. Thermostatic control is turned off ; Tools M563 P0 D0 H1 F0:1 ; 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 M575 P1 S1 B57600 ; enable support for PanelDue
-
; Z-Probe M558 P9 C"^!zprobe.in" H10 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds M950 S0 C"duex.pwm1" ; create servo pin 0 for BLTouch G31 P500 X172 Y186 Z2.5 ; set Z probe trigger value, offset and trigger height M557 X15:250 Y15:250 S20 ; define mesh grid
You've changed too much.
M558 P9 C"^!zprobe.in"
Remove the exclamation mark ! that's inverting the pin signal, so it's acting triggered when it is not. Leave the carat ^ to enable the pull-up resistor.G31 P500 X172 Y186 Z2.5
The X Y offset is totally wrong. This is the distance between the nozzle tip and the probe pin. I highly doubt it's that far away.See here for how to measure it. https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe#Section_Measuring_Probe_X_Y_Offset
Change G31 P500 to P25
When you send M401 and M402 does the pin deploy and retract? Post your deployprobe.g and retractprobe.g files.
Also, for good measure, please provide the results of M122 and M98 P"config.g"
-
That is interesting. If I remove the inversion, nothing works. With it in, the probe functions, including M401 deploying and M402 retracting on command, reseting, and deploying for measurement (but it doesn't result in a measurement that I can see). But... I can follow direction
My_Nightmare :) M122 Status Idle Mode: FFF Tool Position X 0.0 Y 0.0 Z 0.00 Extruder Drives Drive 0 0.0 Speeds Requested Speed 0 mm/s Top Speed 0 mm/s Sensors Vin 24.2 V MCU Temperature 37.6 C Z-Probe 0 Tools Extra Control All Tool Heater Current Active Standby Tool 0 T0 - Load Filament Heater 1 off 21.1 C 0 0 Bed Heater 0 off 21.7 C 0 0 Temperature Chart Send code... 7/21/2020, 6:18:32 AM M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5 Board ID: 08DGM-917Q9-GLMS8-6J1F6-3SJ6K-TGHW8 Used output buffers: 3 of 24 (21 max) === RTOS === Static ram: 27980 Dynamic ram: 94144 of which 84 recycled Exception stack ram used: 264 Never used ram: 8600 Tasks: NETWORK(ready,384) HEAT(blocked,1216) DUEX(suspended,160) MAIN(running,1840) IDLE(ready,80) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:02:18 ago, cause: software Last software reset at 2020-07-21 06:16, reason: User, spinning module GCodes, available RAM 8560 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00417000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 36.9, current 37.6, max 37.8 Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max not available Driver 1: standstill, SG min/max not available Driver 2: standstill, SG min/max not available Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max not available Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-07-21 06:18:31 Cache data hit count 229401789 Slowest loop: 9.21ms; fastest: 0.14ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.9ms, write time 0.9ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 201.55ms; fastest: 0.09ms Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 1 WiFi firmware version 1.23 WiFi MAC address 84:f3:eb:dd:cd:cb WiFi Vcc 3.34, reset reason Unknown WiFi flash size 4194304, free heap 18072 WiFi IP address 10.182.207.15 WiFi signal strength -50dBm, reconnections 0, sleep mode modem Socket states: 0 4 0 0 0 0 0 0 === DueX === Read count 0, 0.00 reads/min
-
@beachtec please try setting
M566 X1000 Y1000 Z10 E500
a higher Z value, because 10 mm/min means only 0.16 mm per second speed change. Please set to 50.If it doesn't work after this change, can you please check wiring or make an image where you connected the wires? (to help checking)
-
For completeness...
; deployprobe.g ; called to deploy a physical Z probe ; ; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time) M280 P0 S10 ; deploy BLTouch ''' ; retractprobe.g ; called to retract a physical Z probe ; ; generated by RepRapFirmware Configuration Tool v3.1.4 on Sun Jul 19 2020 14:49:46 GMT-0500 (Central Daylight Time) M280 P0 S90 ; retract BLTouch
The probe deploys correctly using any normal command. I do NOT get an indication of a z-probe value in DWC during probing and no control action. It will crash if allowed to do so.
Is it possible that something happened to the Duet "Z_Probe_in" channel? Is there a away to configure another GPIO pin to accept the signal from the BLTouch... or does this sound improbable? -
I wish. The wiring is ok. I made a separate BLTouch loom and went around the existing wiring harness in place, with the exact same outcome.
-
This post is deleted! -
@beachtec the white and black cables look as if they are not at the left 2 pins, but the white in the air.
It's very difficult to check the other connections. I would connect the three PWM Servo cables to one connector of the Duex, not partly to the LCD connector. You have a condensator between 5V and ground, is this for a special reason? -
@JoergS5 They are 100% on the pins... but thank you . Sorry for the poor photo quality... the angle of the photo does make it appear that way! There is no cap/condensator between the +5 and ground. It is a connector with a shrink wrap sleeve on it (to reduce chances of accidentally pulling them apart. I have built 7 machines with the BLTouch, granted in the RRF2.x software. I have had issues with using the the 5v from the PWM connector that cleared up immediately with the move to the unused connector on the duet to power provide power. The BLTouch is responding to the PWM commands... in every case, except I can not get a trigger event to get the duet to "home".
BTW, I have a spare 3.1 BLTouch here... it's brand new. Swapping them had no impact. -
@beachtec I would put the 3 servo cables together to one connector. Second I would check the cables: look at the 5 pin connector at the BLtouch and compare with BLTouch images in the internet which cable is which signal. Because sometimes the cables are switched.
I don't know whether you are "electronics-affine", but I saw people testing their BLtouch with Arduino Uno, to be sure the BLtouch is ok. E.g. https://www.3d-druck-community.de/showthread.php?tid=26431, but this is a german forum, but I'm sure there are english users doing this also.
-
@beachtec I think I've found something:
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_name_format
the comment that using the duex.pwm1 syntax inverts the signal ("The DueX boards buffer and invert the signal. Therefore, when you use one of the forms prefixed with duex the firmware knows it has to invert the signal, but it doesn't invert it if you use one of the other forms"),So you will probably need a ! in the M950 command if you use duex.pwm1.
There is another issue if you have Duex version 0.9 or 0.9a board, is this the case? Then check https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Duet_2_WiFi_Ethernet_with_Duex_2_or_Duex_5_expansion_board the switch setting.
-
@JoergS5 said in RRF3 and Duet wifi + Duex5:
@beachtec I think I've found something:
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_name_format
the comment that using the duex.pwm1 syntax inverts the signal ("The DueX boards buffer and invert the signal. Therefore, when you use one of the forms prefixed with duex the firmware knows it has to invert the signal, but it doesn't invert it if you use one of the other forms"),So you will probably need a ! in the M950 command if you use duex.pwm1.
There is another issue if you have Duex version 0.9 or 0.9a board, is this the case? Then check https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Duet_2_WiFi_Ethernet_with_Duex_2_or_Duex_5_expansion_board the switch setting.
That's all for the servo control for the pin though, which in this case is working.
The signal for triggering is the white wire to the probe in pin. Try swapping out that wire because it seems like it's showing triggered even when it is not. You won't typically be able to see the trigger status change in the DWC display because the BLTouch triggers and resets instantly, so the display doesn't usually have time to register it.
The best way to test is the dynamic test described here: https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe
By the way it looks like you may have a cloned board.
-
This post is deleted! -
@beachtec said in RRF3 and Duet wifi + Duex5:
How am I supposed to know it is a clone?
Its a "risk" when buying outside the authorized resellers I guess; depending on your consumer laws it might be illegal to sell clones even privately so if you feel tricked then maybe look into your options there.
As far as being able to tell its a clone, the top silk screen says "Based on Duet 2" instead of just "Duet 2", and the bottom will likely clearly state its a reproduction that is not support / endorsed by Duet3d.
That being said, as you've already experienced both the community and Duet3d will still support you with the firmware on a best effort basis
-
Yes we'll do our best to help, we just can't provide warranty obviously.
It shouldn't be necessary to invert the signal of the Bltouch, and when you run without the inversion it's telling you that it's showing as triggered even though it's not. Which I believe. If it's not wiring then I suspect something is wrong with the probe, but you've said you've also tried swapping out a different working BLtouch and it has the same problem, which means maybe it's the board? Not sure.
Have you tried without the pull up resistor enabled? Remove the ^ from the M558.
-
My recommendation would mean some work...
You have too many options where the error is, so to reduce the possibilites, I would remove the duex and use the connectors which are used most often (2 cables at zprobe, the 3 on the connector which is now used for the cable to Duex), testing with the newly bought BLtouch first.
Then I would build a test station with the help of an Arduino Uno to make sure the Bltouch and cabling is working correctly. I'm sorry it's in german, but something like this project: https://www.3d-druck-community.de/showthread.php?tid=26431 This way you could reduce 3 possible error reasons (Duex, BLtouch, wiring). The attached bltouch.zip has english comments.One additional idea: I have genuine BLtouch, but I have also a clone BLTouch (Geeetech). The clone has one speciality: I can turn the top allen key screw (the key at the top of the BLtouch which moves the core) as much as I like, more than the documented 180°. When turning a lot of turns, the pin becomes unmovable, so retract/deploy doesn't work any more. Maybe the core position is wrong at your BLtouch. That the pin of your BLtouch is bent, is another possibility.
-
@JoergS5 Thank you all for your help here. It is certainly multivariate! I am going to pull it apart this weekend and bench test it... but I am leaning toward some sort of board failure and less a config error. I did learn allot (and I hope others did)... including the bit about the oft missing aux power jumper on the Duex board... completely explains why I have seen a missing 5v rail in the PWM ports there in the past. Those zingers in plain sight are the worst. I will post what I find. Thank you!