@dc42 Sounds good. I'm in no hurry. Homing each axis individually works fine for now.
Best posts made by ctilley79
Latest posts made by ctilley79
RE: RRF3 Sensorless Homing issue/bug
@dc42 I was able to temporarily get around the problem by homing the X and Y axis individually. Some additional buggy behavior, occasionally I do get an "G28 X G0/G1insufficient axes homed" error in the web interface when using the home_x and home_y files. This happens after a fresh boot or after an emergency stop. The axis stops and home is set, however the remaining part of the file isn't processed. The problem persists until the other axis is also homed. For example....
- emergency stop or fresh boot condition
- press home x.
- x axis moves to the endstop and sets X=0
- throws error and remainder of the file is ignored.
- press home y
- y axis moves to endstop and sets Y=0
- No error is thrown and axis move to 125,100 as expected
- home x now works
; homex.g ; called to home the X axis M561 M400 ; make sure everything has stopped before we make changes M574 X1 S3 ; set endstops to use motor stall M913 X40 ; reduce motor current to 50% to prevent belts slipping G91 ; use relative positioning G1 H2 X15 Z5 ; Move Z and Y up for a running start G1 H1 X-270 F6000 ; move all carriages up 700mm, stopping at the endstops G90 ; back to absolute positioning M400 ; make sure everything has stopped before we reset the motor currents M913 X100 ; motor currents back to normal G1 X125 Y100 F6000 ; centre the head and set a reasonable feed rate
RRF3 Sensorless Homing issue/bug
I'm testing RRF3 beta and ran into an issue when using sensorless homing on my Duet 2 WiFi. My home X, Y, and Z files work as expected, but my home all file has the following symptom. As soon as the X axis homes off of X min, the y axis stops as well resulting in an incorrect home location for Y. Conversely, if the Y axis reaches the endstop first, it results in an incorrect position for X. My homeall.g is as follows.
M561 ; unload heightmap M400 ; make sure everything has stopped before we make changes G91 ; relative positioning M574 X1 Y1 S3 ; set endstops to use stall detection M913 X30 Y30 ; reduce motor current G1 X5 Y5 Z2 F6000 ; lift Z relative to current position G1 H1 X-270 Y-220 F6000 ; move quickly to X and Y axis endstops and stop there (first pass) G1 X5 Y-5 F8000 H2 ; go back a few mm M400 ; make sure everything has stopped before we make changes M913 X100 Y100 ; motor currents back to normal G1 Z2 F6000 H2 ; raise head 2mm to ensure it is above the Z probe trigger height G90 ; back to absolute mode G1 X100 Y100 H2 F6000 ; put head over the centre of the bed, or wherever you want to probe G30 ; lower head, stop when probe triggered and set Z to trigger height
RRF 2.04 RC3 Erratic BLTouch behavior
I am getting strange behavior out of my bltouch that I wasn't getting in 2.04 RC1. My board is a duet wifi hardware revision 1.03. My board is hooked up according to the guide here https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe.
The behavior is the probe will not deploy 100% of the time when homing. I also have macros set up to manually deploy and retract the probe, reset errors etc and the firmware is not applying any of those. for example, M280 P3 S160 I1 no longer clears the probe. Also running deployprobe.g or retractprobe.g does nothing.
RE: Duet Web Control 2.0.0-RC5
@pkos Unfortunately, Prusa version of Slic3R is becoming more and more biased towards it being used with Prusa firmware and every release sees this integration becoming tighter and tighter.
So should we expect RepRap firmware to be changed to support a specific slicer? To my mind, the slicer should be firmware agnostic but Prusa Slic3R has started doing things differently.
I disagree with this statement. For example, they added the option to upload directly to a Duet WiFi from within slic3r pe. Not sure how your statement is in the least bit accurate.