Firmware 2.02 released!

kazolar

@leonmf I replied on that thread -- hope that helps you, dual (or more ) z homing works fine in RC5 -- I believe there are some transient issues in 2.02 final -- possibly started with RC7 -- I notice that after a long period of on time there is some issue that builds up which results in a few other oddities, @dc42 -- i.e I noticed a slow down behavior between moves -- for example it moves, then thinks then moves again, the move is not slow (I've see that before), but it thinks a good bit before the next move -- in that state is when it starts to lose end stop triggers.

kazolar

David, I am running rc5 and after over 20 hours of printing, no issues with end stops, it's a 30 hour print, but I just checked the diagnostic page while it's printing and checked the end stops on the duex5 and they work fine. Definitely there was an issue with the new firmware and duex5 end stops.

LeonMF

I think the U Axis homing I'm seeing is not 2.02 final specific (even though I believe it to be a real bug).

I'm also seeing a new thing in 2.02 where the first move of any axis after homing any axis is exceptionally slow and ignores the FXXXX parameter. Subsequent moves are fine, though.

dc42

@kazolar said in Firmware 2.02 released!:

@leonmf I replied on that thread -- hope that helps you, dual (or more ) z homing works fine in RC5 -- I believe there are some transient issues in 2.02 final -- possibly started with RC7 -- I notice that after a long period of on time there is some issue that builds up which results in a few other oddities, @dc42 -- i.e I noticed a slow down behavior between moves -- for example it moves, then thinks then moves again, the move is not slow (I've see that before), but it thinks a good bit before the next move -- in that state is when it starts to lose end stop triggers.

That sort of slow down is usually the result of I2C communication between the Duet and the DueX breaking down. Please check the I2C stats in the M122 report when this happens. The usual cause is a poor ground connection between the VIN terminal blocks of the Duet and the DueX.

dc42

@kazolar said in Firmware 2.02 released!:

David, I am running rc5 and after over 20 hours of printing, no issues with end stops, it's a 30 hour print, but I just checked the diagnostic page while it's printing and checked the end stops on the duex5 and they work fine. Definitely there was an issue with the new firmware and duex5 end stops.

If/when this happens again, after the print finishes please check:

The I2C stats in the M122 report
If you have any fans connected to the DueX then test whether they are still working.

kazolar

@dc42 David, this never happens with rc5, how can it be hardware/wiring related. I'm running rc5 now and haven't had it happen in over 100 hours of printing.

dc42

@kazolar said in Firmware 2.02 released!:

@dc42 David, this never happens with rc5, how can it be hardware/wiring related. I'm running rc5 now and haven't had it happen in over 100 hours of printing.

Whatever the reason for the problem, I need the results of the tests I requested, to determine whether the I2C comms have stopped working or just the endstops on the DueX5.

kazolar

@dc42 I have a long print project to complete, so I won't be able to roll back to 2.02 final until after it's done. I am in hour 10 of a 2nd 30 hour print, then I have 3 12 hour parts to print out. I can test it on a benchy this weekend -- it is absolutely repeatable after 4+ hours of printing. BTW when it happened I did electrical testing the duet and duex5 -- I tested the 5v, 3.3v and 24v rails for any variants -- and everything was copacetic, my first thought it was wiring related, but everything checked out fine, and since a rollback to rc5 fixed it, I'm sure it's not.

BTW, i have 2 fans blowing across the duet and they're working fine -- duet MCU reports 25-26c even during 20+ hour long print jobs

bret4

Just wanted to say the new firmware is working fine on my Hypercube Evolution. Only problem I found was that I had to make changes to my config.g to get it to work after upgrading. 2.01 I believe was my old firmware. Now with 2.02 I had to make these changes to config.g to get it to work.

Old settings:

; Axis Limits
M208 X0 Y0 Z0:0 U0 S1 ; Set axis minimum

M208 X285 Y270 Z285:285 U285 S0 ; Set axis max

New Settings:

; Axis Limits
M208 X0 Y0 Z0 S1 ; Set axis minimum

M208 X285 Y270 Z285 S0 ; Set axis max

What would happen is it would set my Z axis Min and Max to 285mm with the old settings. This would always move the bed to the furthest position from the head and start printing in air. Not on the bed. Those old settings worked fine in the old version but mess things up bad in the latest firmware. Spent about 10 hours trying to figure out this problem.

Hope this is of some help to others that may have problems with Z axis moving strange after upgrading.

dc42

I'm glad you got it working. The reason you had problems was that firmware 2.01 ignored the second Z value in your M208 command, whereas firmware 2.02 allows you to use e.g. M208 X0:200 Y-10:200 Z0:250 instead of using separate M208 S0 and M208 S1 commands.

mveinot

Hi all, been using Duet3D for my CoreXY since the middle of last year or so.

Since 2.02 I've been unable to home the axes correctly. I use stepper resistance to home the X/Y and a BLTouch to home Z (I assume this is probably still working)

After updating to 2.02 I got a message when I try to home about insufficient axes being homed - did some reading and saw I needed to add M564 H0 to allow movement before the axes were homed, so I did that, but now the print head just smashes into the 0 position and tries to keep going instead of determining that's the home position and proceeding with the rest of the home position.

I've placed my config and home gcode files at this location.

Any help would be greatly appreciated.

wilriker

@mveinot First of all I would not recommend the use of M564 H0. This opens up a possibility for bad things IMHO. You should always adapt your homing macros as a better solution (and home before any movement).

I was looking at your homex.g (and homey.g) and at least they should not create this error message. Maybe your homeall.g does. Only thing that I found a little strange in your homex.g is that you go to home, go to X=5 and at the end set this position to be 0 via G92 X0. This might be totally correct for your setup but I find it quite strange. (I also find you regular acceleration values of 15,000mm/s² strange but again this might be totally fine for your machine)

Anyway, regarding the stallGuard-based homing I sadly cannot really help since I don't use it. The only thing I can think of is that something changed (mechanically, inside firmware) and your previous stallGuard settings just don't work anymore, i.e. it does not detect the stall.

mveinot

@wilriker Thanks for the insights. The reason I set the x=5 offset is that the x/y carriage bumps into part of the printer frame if I don't move it in a bit on that axis.

Even trying to home each axis individually I was still getting that error (insufficient axes homed)

My homeall.g just calls each of the individual homing files in sequence, it doesn't do anything special.

wilriker

@mveinot Oh wait, you have M452 in your config.g. This sets your printer into Laser mode. In this case it is mandatory to change all your G1 Snnn into G1 Hnnn. This is because in 2.02 when the printer is set to laser mode the Snnn parameter of G1 controls the laser power!

From the documentation of M452

Very important! If you use M452 to put your machine into Laser mode and are running Firmware 2.02 or above, you must replace all S parameters in G0/G1 commands in homing files etc. by H parameters. This is because S is now used to control laser power.

mveinot

@wilriker Darnit! I forgot all about having that in there. Yep, that did it. Thank you so much.

dc42

@mveinot, you can avoid the move to X5 and G92 X0 if you change the M208 lower X limit from 0 to -5.

mveinot

@dc42 Thanks, I've made that change as well. Seems to work!

Hornetrider

Hi Guys,

I hope you can help me out.
I have updated to latest FW2.02 and DWC2.0.0-RC3 and at first it looked great.
But since the update I can't home my axes, any of it. I tried to modify the home files, f.e. homex.g with very slow movement but that didn't help.

I allways receive the error G0/G1:insufficient axes homed

I checked the switch states again and they work fine.

It seems like S1 is ignored...

Here the config.g:
; General preferences
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves

; Network
M550 P"RicDuet" ; Set machine name
M552 P0.0.0.0 S1 ; Enable network and acquire dynamic address via DHCP
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

; Drives
M569 P0 S0 ; Drive 0 goes backwards
M569 P1 S0 ; Drive 1 goes backwards
M569 P2 S0 ; Drive 2 goes backwards
M569 P3 S0 ; Drive 3 goes backwards
M350 X32 Y32 Z32 E32 I0 ; Configure microstepping without interpolation
M92 X160.00 Y160.00 Z8000.00 E210.02 ; Set steps per mm
M566 X900.00 Y900.00 Z12.00 E120.00 ; Set maximum instantaneous speed changes (mm/min)
M203 X10020.00 Y10020.00 Z198.00 E10020.00 ; Set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z100.00 E3000.00 ; Set accelerations (mm/s^2)
M906 X1200.00 Y1200.00 Z1200.00 E1200.00 I0 ; Set motor currents (mA) and motor idle factor in per cent
M84 S0 ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1 ; Set axis minima
M208 X210 Y297 Z220 S0 ; Set axis maxima

; Endstops
M574 X1 Y1 Z1 S0 ; Set active low and disabled endstops

; Z-Probe
M574 Z1 S2 ; Set endstops controlled by probe
M558 P5 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds
G31 P500 X0 Y0 Z0.750 ; Set Z probe trigger value, offset and trigger height
M557 X5:170 Y5:275 S20 ; Define mesh grid

; Heaters
M305 P0 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 280C

; Fans
M106 P0 S1 I0 F500 H1 T45 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P1 S0 I0 F500 H-1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off

; Tools
M563 P0 D0 H1 ; 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

; Automatic saving after power loss is not enabled

; Custom settings are not configured

; Miscellaneous
T0 ; Select first tool

and f.e. homex.g

; generated by RepRapFirmware Configuration Tool v2 on Mon Dec 31 2018 02:05:14 GMT+0100 (Mitteleuropäische Normalzeit)
G91 ; relative positioning
;G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 X-215 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X6 F6000 ; go back a few mm
G1 S1 X-215 F100 ; move slowly to X axis endstop once more (second pass)
;G1 Z-5 F6000 S2 ; lower Z again
G90 ; absolute positioning

Just unmarked the Z axis movents not to be anoyed...

Any ideas?

BR
Ric

Phaedrux

@hornetrider Can you post your other homing files? Homex looks correct.

Hornetrider

@Phaedrux

thanks for the quick reply.
The homeall.g looks similar to the homex.g as it was generated with the RepRapFirmware Config Tool.
It uses the same controls just for all axes and including the G30 for the Z Probing.

The strange thing is, before the FW update (done 02.01.19) the homing worked fine...

Also
G1 S1 X-215 F1800
G1 X6 F6000 ; go back a few mm
work fine as the X-Axe goes back the distance after hitting the first time the switch....

But at the end of the script the error message appears.