New firmware 2.03RC2 available

dc42

@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.

kuhnikuehnast

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...

boldnuts

This post is deleted!

kuhnikuehnast

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

@dc42

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?

dc42

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?

dc42

I'll add this to my list of issues to investigate. Please post your homex.g file.

TypQxQ

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.
0_1558126571899_Skärmklipp.PNG

@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.g

1st) 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 homed

M98 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 homed

2nd) homex-movement.g

; actual homex-movement
; for general reference see https://duet3d.dozuki.com/Wiki/Gcode#main

G54 ; 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 0

M400 ; 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

dc42

@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?

ben_van

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??

Milan

Hi , Wifi connected IP address provided , but the IP address is not working , pls help

Milan

@milan WiFi module is connected to access point MMM, IP address 192.168.43.250

dc42

@ben_van said in New firmware 2.03RC2 available:

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??

Are you running the machine in CNC mode (using M453) or in the default FDM mode? In CNC mode, G0 should use the maximum feed rate. In FDM mode, it uses the same feed rate as G1 commands.

dc42

@milan said in New firmware 2.03RC2 available:

Hi , Wifi connected IP address provided , but the IP address is not working , pls help

Is this specific to firmware 2.03RC2, or does it happen in 2.02 as well? If it isn't specific to 2.03RC2, please create a separate thread for your issue.

dc42

There are some known issues with firmware 2.03RC2 on CNC machines when using workplace coordinates, so please do not use workplace coordinates with this release.

ben_van

@dc42 said in New firmware 2.03RC2 available:

@ben_van said in New firmware 2.03RC2 available:

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??

Are you running the machine in CNC mode (using M453) or in the default FDM mode? In CNC mode, G0 should use the maximum feed rate. In FDM mode, it uses the same feed rate as G1 commands.

I am running the machine in laser mode (M452). Previously when i was using older firmware, and had the Z axis in steps per micron, G0 moves would take the max feedrate set in M203. They do also on this release, however only for the X and Y axis, not Z.

dc42

That's odd because X Y and Z should be treated in exactly the same way. Please post your config.g file.

minim

Anyone having issues with babystepping not working? On rc2 with dwc 1,23/2.0 and I can't step down but I've never tried on the stable. Will roll back after this print and check.

Edit: just read that M208 is stopping it from going below Z0. What a strange limit to have. Well then it's not a firmware issue atleast since I have M208 set to Z0.