New firmware 2.03RC2 available
-
Awsome - will try to test it tonight
-
Compiled and flashed.
-
I'll push the firmware today and test also. But there's been no changes to M291 is that correct? It didn't unlock movement of the tool change in RC1.
-
submitted an issue, 2.03 has a bed leveling issue
-
Tool offset work fine, thanks! Tested on 2.03RC1
-
I've got also problems with G30.
On the second probe point, the BLTouch starts to just moving up and down and doesn't measure at all...``G1 Y227.0 F12000 ; move bed out of the way
M561 ; clear any bed transform
M280 P4 S105 I1 ; left Servo Up
M280 P5 S83 I1 ; right Servo Up
G1 Z10 ; move 10 up to prevent a crash
G1 X-20.7 Y227.0 F12000 ; go to left Servo probing point
G31 P25 Z0 ; set trigger height to 0
G30 X-20.70 Y227.0 ; define left Servo probing point as Z=0G30 P0 X6.2 Y232.935 H0 Z-99999 ; probe point P0
G31 P25 Z0.2075 ; set trigger height to 0.2075
G30 P1 X214.4 Y232.935 H0 Z-99999 S2 ; go to defined probing point 2 and do: S2 - Adjusting; S-1 ReportM280 P4 S25 I1 ; left Servo down
M280 P5 S170 I1 ; right Servo downG92 Z15 ; define z higher than normal to get a probe result
G31 P25 X+26.9 Y5.935 Z1.065 ; Z probe trigger value, offset in relation to nozzle. And trigger height adjustment -> reset to standard
G1 X83.1 Y104.065 F12000
G30 X83.1 Y104.065 ``` -
Hmm... There seems to be a really big error in the firmware I am unable to use my printer! Even a downgrade to a previous version didn't work... The problem is the BLTouch: It just doesn't what I want it to do... While homeing, it starts to do a "self-test" (down-up-down) during this move:
´´G1 S1 X-275 Y-245 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)´´
and if I use a G30 command it doesn't work either. The first probing point works well, but at the second it either starts to just going up and down while moving z down or just doesn't deploy the probe... damn! Please help! At the moment, I am unable to use my printer!!! -
@kuhnikuehnast said in New firmware 2.03RC2 available:
Hmm... There seems to be a really big error in the firmware I am unable to use my printer! Even a downgrade to a previous version didn't work... The problem is the BLTouch: It just doesn't what I want it to do... While homeing, it starts to do a "self-test" (down-up-down) during this move:
´´G1 S1 X-275 Y-245 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)´´
and if I use a G30 command it doesn't work either. The first probing point works well, but at the second it either starts to just going up and down while moving z down or just doesn't deploy the probe... damn! Please help! At the moment, I am unable to use my printer!!!I suspect you have a bad crimp connection in the cable to the BLTouch.
-
no, not at all. It worked fine!
If I do the first probe
e.g.:
G30 P0 X-20 Y150 H0 Z-99999
this works! But if I want to probe the second point
e.g.:
G30 P1 X-20 Y150 H0 Z-99999 S2
the probe either doesn't trigger at all or runs into the bed just going up and down...
-
This post is deleted! -
omg- @dc42 you've been right! After now searching for the error over and over, it was really a bad connection... So for now- everything works fine
-
I have a question regarding the intended behaviour of G54/G55 & homing, in this release (but since this release is the one and only I have ever really used starting with the 2.03 beta a while ago, I assume it might be there for a long time already):
After powering up the printer and homing (of course G54) all axis, I can rehome (even multiple times) later (without restarting the duet or so) and all works fine! (E.g. to fast move the printhead out of the way into the corner in my case)
Curious observation: If machine is homed (in G54 of course) and in x&y a G55 is defined with offset to G54 x&y, all works fine EXCEPT if I want to rehome the machine then (without zeroing out the delta between x to x & y to y for G54 to G55) if I home any axis, it seems to try to first move itself the amount of the delta IGNORING all endstops...
Is not really a problem because I can always do a softstart/rebooting of the duet if I would really need to home again (usually why would you home again & using additional csys, etc. if an axis is already homed, the only case is to be to lazy to move via jog console the prinhead in its "rest" position), just curious what might be the reason for the behaviour? Or am I doing anything wrong here?
-
Workplace coordinate offsets are always ignored when running system macros. If that wasn't the case, homing would give different results depending on what coordinate offsets you are using. Similarly for pause/resume.
In firmware 2.02, tool offsets are also ignored in system macro files. This was a mistake, so in firmware 2.03 tool offsets are applied even in system macros, unless you use G53 at the start of the line to signal that you want to ignore them..
-
@dc42 said in New firmware 2.03RC2 available:
Workplace coordinate offsets are always ignored when running system macros. If that wasn't the case, homing would give different results depending on what coordinate offsets you are using. Similarly for pause/resume.
In firmware 2.02, tool offsets are also ignored in system macro files. This was a mistake, so in firmware 2.03 tool offsets are applied even in system macros, unless you use G53 at the start of the line to signal that you want to ignore them..
Thanks so much for coming back on this so fast! A lot to learn here for me.
O.K. I get the offsets are ignored, but that is strange: I try to explain the example again. O.K. E.g.: machine was powered up, homed (in G54 of course), a piece of fabric was fixed on the table, for Z G54 is used (adjustment is done if necessary via temporary baby-stepping), but for X&Y G55 is put on some corner of the fabric to better control where things are printed onto the fabric. Everything works fine, it prints fine, all done, perfect.
Now somebody wants to print somewhere else on the table (on the same or new fabric). Instaed of just updating G55 in x&y for positioning the print (or doig an shift/offset in the the slicer), because of getting in a lazy fashion the printhead out of the way, the person just homes x e.g., THEN: Not only is the printhead moving in x only - as one would suspect and as it does usually with standard-homing after powering up - BUT (I think because of the delta between G54 and G55 in X&Y) it makes a diagonal move of the amount in X & Y AND if that offset was very big, this is of course a big diagonal move I do not understand AND it ignores only on that move totally any endstop? What am I doing wrong? Should I open a diffrent thread and post all homing and config files?
-
I'll add this to my list of issues to investigate. Please post your homex.g file.
-
Working fine CoreXY with 3 steppers on X, 3 on Y, 3 on Z and one E. As seen on 3D Sweden Meetup. Though still same error about "homing file not found" after first reset. Tried printing at 300mm/s and travel at 600mm/s with 80 steps/mm.
-
@dc42
to not get confused: They are split macros to be able to call the actual homex-movement.g either direct and only for homex.g or to call it within homeall.g1st) homex.g
; called to home the x axis
; for general reference see https://duet3d.dozuki.com/Wiki/Gcode#main
;M291 P"Homing x?" R"Make sure fly-shuttle cannot crash!" S3 ; intentionally?
; change endstop/homing behaviour
M564 H0 S0 ; S1 = enable axis limits, H1 = NOT allow movement of axes that have not been homedM98 P"home-zhop-plus.g" ; call P".g" submacro; see https://duet3d.dozuki.com/Wiki/Gcode#Section_M98_Call_Macro_Subprogram
M98 P"homex-movement.g" ; call P".g" submacro; see https://duet3d.dozuki.com/Wiki/Gcode#Section_M98_Call_Macro_Subprogram
M98 P"home-zhop-minus.g" ; call P".g" submacro; see https://duet3d.dozuki.com/Wiki/Gcode#Section_M98_Call_Macro_Subprogram
; change endstop/homing behaviour
M564 H1 S1 ; S1 = enable axis limits, H1 = NOT allow movement of axes that have not been homed2nd) homex-movement.g
; actual homex-movement
; for general reference see https://duet3d.dozuki.com/Wiki/Gcode#mainG54 ; use 1st machine coordinate-system, see https://duet3d.dozuki.com/Wiki/Gcode#Section_G54_to_G59_3_Select_coordinate_system
M400 ; Finishes all current moves and and thus clears the buffer
;M913 X50 ; set specified motors to 0-100% of their normal current specd in the config.g
G1 H1 X-705 F1250 ; move "quickly" to specified axis endstop and stop there (first pass), make sure it is slow enough to have some place left after hitting endstop to break to halt before crashing
G1 X10 F550 ; go back a few mm to make sure the trigger can "untrigger"!
G4 P100 ; dwell for time in P_ milliseconds or S_ seconds
M400 ; Finishes all current moves and and thus clears the buffer
G1 H1 X-705 F65 ; move slowly to specified axis endstop once more (second pass)G1 X0 ; be sure to be at 0
; zero out also G55-2ndcsys
G10 L20 P2 X0 ; set P1=G54-1stcsys, P2=G55-2nd-csys, ...G1 X20 F1500 ; move inwards a few mm
G92 X0 ; set axis to 0M400 ; Finishes all current moves and and thus clears the buffer
;M913 X100 ; set specified motors to 0-100% of their normal current specd in the config.g
M117 Homed P1/G54 in X ; put out message to console/user
-
@typqxq said in New firmware 2.03RC2 available:
Though still same error about "homing file not found" after first reset.
What is the exact error message?
-
Thank you for adding the option to set the minimum movement speed! Now i can work all axes in mm.. However it seems like there is also a minimum limit of 1mm/s applied to G0 moves as well? In my config file I set this:
M203 X2500 Y2500 Z20 E10000 I1
If I send G1 Z5 F20; the commanded speed is correct.
If I send G0 Z5; The max feedrate set in M203 is not honoured and it commands 1mm/s or F60.
This doesn't really bother me except that all of the motion buttons on the PanelDue and Webcontrol send a G0.. Or am I missing something?? -
Hi , Wifi connected IP address provided , but the IP address is not working , pls help