Firmware 2.02RC5 now available
-
@resam said in Firmware 2.02RC5 now available:
@dc42 said in Firmware 2.02RC5 now available:
Were you using workplace coordinate offsets when this happened?
No - I'm running in a simple plain FFF mode as 3D printer.
I do not have any G53 or G54 codes in mysys/
ormacros/
files.Thanks. Are you using any G10 tool offsets?
EDIT: or M206 offsets?
-
@dc42 said in Firmware 2.02RC5 now available:
Thanks. Are you using any G10 tool offsets?
The only G10's I have are hotend temperature and retract commands:
G10 10 P0 S0 R0
,G10 S175
and similar.EDIT: or M206 offsets?
No.
I do have a M208 with a negative Y minima - which I use as a pause position - maybe this is causing a weird edge case ("out of workspace"?)
My pause.g:
M83 ; relative extruder moves G1 E-2 F1200 ; retract G91 ; relative moves G1 Z3 ; raise nozzle G90 ; absolute moves G0 X230 Y-5 F6000 ; move head out of the way of the print and clear nozzle M106 S0 ; fan off
My resume.g:
G0 R1 X0 Y0 Z3 F6000 ; return to point previously paused at (but above it) G1 R1 X0 Y0 Z0 F180 ; return to point previously paused at (lower nozzle) M83 ; relative extruder moves G1 E2 F1200 ; undo the retraction M106 R1 ; restore fan speed T R1 ; restore tool selection
I based these scripts on https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Pause_resume_and_cancel_files - but it seems some of it is redundant now because RRF already does the same steps before/after calling resume.g
-
Even though the G0 R1 and G1 R1 lines are not strictly needed, they should still work, at least if you are not using workplace coordinate offsets or tool offsets. As you are not using either of those, I don't know why they are not working properly. The negative Y coordinate is OK. I tested pause/resume in 2.02RC5 using this resume.g file:
; Resume macro file
G1 R1 X0 Y0 Z2 F5000 ; move to 2mm above resume point
G1 R1 X0 Y0 Z0 ; lower nozzle to resume point
M83 ; relative extruder moves
G1 E4 F2500 ; undo the retraction -
I flashed RC5 again - the bug is repeatable.
I added beeps to my resume.g to check when the faulty moves are made:
TheG1 R1 ...
commands in resume.g are not correctly executed. The head seems to be moved to (0,0) in absolute coordinates (front left corner).The following similar moves in the firmware seem to be correct.
With RC4 this works as expected.
So this bug seems to happen somewhere during/before the execution of resume.g, because once we enter theresuming_1
state, it behaves correctly.
HandleMCode
for case 24 is pretty simple - so I suspectDoFileMacro
again... -
@dc42 I think I got a reasonable outline of what is happening:
When we call resume.g,
DoFileMacro
setsuseMachineCoordinatesSticky = true
.
https://github.com/dc42/RepRapFirmware/commit/6e457735157a8cb452cc244f866fb1c083c7b48b#diff-4982d99e6381f0b210c46336de3818d4R123 introduced aUsingG54()
which now also becomes true.
https://github.com/dc42/RepRapFirmware/commit/6e457735157a8cb452cc244f866fb1c083c7b48b#diff-6418fd0d517411c266a27fb33b10ad76R2523 now usesUsingG54()
, therefore we enter the first if-block, instead of the block for handling a resume-point. -
@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.
I'll fix this and run tests on multiple printers. Also I'll rename UsingG54, it's related to to G53 not G54.
-
@frafa said in Firmware 2.02RC5 now available:
I have exactly the same problems as with version 2.02RC3
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70tested with your homing.all file adapted to my config, the same errors ...
Downgrade 1.21RC3 waiting ...
Please can you try again, but this time:
- Verify that firmware 2.02RC5 is definitely installed (send M115 to check)
- Check that you don't have a deployprobe.g or retractprobe.g file in /sys on the SD card, unless you are using BLTouch
- If the problem still occurs, send the commands in your homing file one by one to establish which command is failing.
My SCARA is working fine on 2.02RC5 with just G30 for Z homing, provided that I home prox+distal first. I am using an IR sensor, so I don't have deployprobe.g or retractprobe.g files.
-
@dc42 said in Firmware 2.02RC5 now available:
@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.
I believe that I've encountered this same issue a few times. My resume.g is identical the one posted by @resam , though mine also contains a M906 to reset the idle current for the stepper motors (I set the idle current to 100% in my filament-change.g)
In my case, the nozzle crashing against the print has, I believe, caused physical damage when the part fan duct was shoved against the side of the print, and pressed hard against the wires from my heater and Pt1000 thermistor. (Apparently, smashing the side of a PT1000 where the wires come out can be bad for the PT1000.)
Note: I'm not trying to make any claim for the destroyed thermistor. I completely recognize that I'm using RC firmware and that's one of the risks I take. On the other hand, I'm hoping that @dc42 can get a fix for this particular issue out more quickly considering that it can cause physical damage.
-
I also have a problem with 2.02RC5. As you can see I have 2 tools defined, and for one of them I have Z offset.
When I try homing T1 Duet ignores Z offset (I go to 0 on end). 2.02RC4 works as intended.; Configuration file for Duet WiFi (firmware version 1.20 or newer) ; executed by the firmware on start-up ; ; generated by RepRapFirmware Configuration Tool on Mon Jul 16 2018 21:02:33 GMT+0200 (Central Europe Daylight Time) ; General preferences G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves ; Network M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Drives M569 P0 S1 ; Drive 0 goes forwards M569 P1 S0 ; Drive 1 goes backwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S0 ; Drive 3 goes backwards M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation M92 X160 Y160 Z8000 E835 ; Set steps per mm (at default 16x microstepping) M566 X900 Y900 Z24 E1200 ; Set maximum instantaneous speed changes (i.e. jerk) (mm/min) M203 X12000 Y12000 Z180 E1200 ; Set maximum speeds (mm/min) M201 X1000 Y1000 Z250 E1000 ; Set accelerations (mm/s^2) M906 X2400 Y2400 Z2400 E2400 I30 ; Set motor currents (mA) and motor idle factor in per cent M913 X70 Y70 Z70 ; set X Y Z motors to 70% of their normal current M913 E70:70 ; set extruders 0 and 1 to 70% of their normal current M84 S30 ; Set idle timeout ; Axis Limits M208 X-13 Y-12 Z0 S1 ; Set axis minima M208 X220 Y220 Z200 S0 ; Set axis maxima ; Endstops M574 X1 Y1 Z1 S0 ; Set active low endstops ; 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 S0 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off M106 P1 S1 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on M106 P2 S1 H1 T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on ; 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 M563 P1 D0 H1 ; Define tool 1 G10 P1 X0 Y0 Z-8.4 ; Set tool 1 axis offsets G10 P1 R0 S0 ; Set initial tool 1 active and standby temperatures to 0C ; Automatic saving after power loss is not enabled ; Custom settings are not configured ; Miscellaneous M501 ; Load saved parameters from non-volatile memory T0 ; Select first tool
; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool on Mon Jul 16 2018 21:02:33 GMT+0200 (Central Europe Daylight Time) G91 ; relative positioning G1 Z5 F6000 S2 ; lift Z relative to current position G1 S1 X-238 Y-225 F3600 ; move quickly to X and Y axis endstops and stop there (first pass) G1 X5 Y5 F6000 ; go back a few mm G1 S1 X-238 Y-225 F720 ; move slowly to X and Y axis endstops once more (second pass) G1 S1 Z-200 F1800 ; move slowly to X and Y axis endstops once more (second pass) G1 Z5 F6000 G1 S1 Z-200 F360 G1 Z8 G90 ; absolute positioning G1 X0 Y0 Z0 ;G1 X15 Y15 F6000 ; go to first bed probe point and home Z ;G30 ; home Z by probing the bed ;G1 Z5 F100 S2 ; uncomment this line to lift the nozzle after homing
-
Hi David,
For memory, works perfect on firmware 1.21RC3 ...
My M669 config...
M669 K4 P200 D200 A-116:175 B-175:140 1:0:0 S100 T0.1 X64.2 Y-150.0; set SCARA kinematics parameters ok S200M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.02RC5(RTOS) ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2018-11-28b1Removed:
deployprobe.g (exist, but empty file)
retractprobe.g (exist, but empty file)Homing test without move (G1 S2 X1 Y-1) before G30 return Error on G30 (x/y home ok):
17:33:43 M120 G91 G1 Z-0.05 F6000 M121 Error: G0/G1: insufficient axes homed 17:33:33 G28 Error: Z probe was not triggered during probing move Error: G0/G1: insufficient axes homed
Second test Add move on homall.g before G30:
;Home Z ir-probe
G91
G1 S2 X1 Y-1 ;Add test ...
G90 ; absolute movement
G30 ; Single Z-ProbeHoming OK
But after homnig absolute movement return error
possible move just on relative movement ...
Move on G90 impossible ...Error:
18:00:19 G1 X10 Y10 F500 Error: G1/G2/G3: intermediate position outside machine limits 17:59:57 G90
Print test ok but impossible to put it in the right place because no absolute movements ...
My homeall.g
M18 ; Disable all stepper motors (pour desactiver le second bras IMPORTANT !) G91 ; relative movement G1 S2 Z4 F250 ; ensure head is clear of the bed ;Move by security to the case or already home! G1 S2 X5 G1 S2 Y-5 ; Home proximal joint G91 G1 S1 X-200 F2000 ; move proximal joint clockwise by up to 200 degrees until the endstop switch is triggered G1 S2 X5 ; move proximal joint anticlockwise by 10 degrees G1 S1 X-20 F300 ; move proximal joint slowly to the endstop switch again G90 ; absolute movement ; Home distal joint G91 ; relative movement G1 S1 Y200 F2000 ; move distal joint clockwise by up to 200 degrees until the endstop switch is triggered G1 S2 Y-5 ; move distal joint anticlockwise by 10 degrees G1 S1 Y20 F300 ; move distal joint slowly to the endstop switch again G90 ; absolute movement ;Home Z ir-probe G91 G1 S2 X1 Y-1 ;Add test ... G90 ; absolute movement G30 ; Single Z-Probe
-
@garyd9 said in Firmware 2.02RC5 now available:
@dc42 said in Firmware 2.02RC5 now available:
@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.
I believe that I've encountered this same issue a few times. My resume.g is identical the one posted by @resam , though mine also contains a M906 to reset the idle current for the stepper motors (I set the idle current to 100% in my filament-change.g)
In my case, the nozzle crashing against the print has, I believe, caused physical damage when the part fan duct was shoved against the side of the print, and pressed hard against the wires from my heater and Pt1000 thermistor. (Apparently, smashing the side of a PT1000 where the wires come out can be bad for the PT1000.)
Note: I'm not trying to make any claim for the destroyed thermistor. I completely recognize that I'm using RC firmware and that's one of the risks I take. On the other hand, I'm hoping that @dc42 can get a fix for this particular issue out more quickly considering that it can cause physical damage.
I'm sorry it may have caused damage. I've added a warning in the what's new file and also on the release page for 2.02RC5. I've already implemented a fix in the RC6 source.
-
I think I was just bitten by the resume bug. I was printing with some stonefil filament that is rather brittle. The filament broke midprint and I paused it so I could reload it, when pausing it dropped the print head to Z5 instead of raising it by 5, and I didn't really notice it as a problem. When I resumed the print it moved the print head diagonally back to the resume point and in the process smashed into the print popping it off the bed. No damage that I can see thankfully.
Here's my pause and resume files just for the sake of completeness.
; pause.g ; called when a print from SD card is paused ; ; generated by RepRapFirmware Configuration Tool on Wed Feb 07 2018 13:21:45 GMT-0600 (CST) M83 ; relative extruder moves G1 E-2 F5000 ; retract 1mm of filament G91 ; relative positioning G1 Z5 F300 ; lift Z by 5mm G90 ; absolute positioning G1 X0 Y0 F6000 ; go to X=0 Y=0
; resume.g ; called before a print from SD card is resumed ; ; generated by RepRapFirmware Configuration Tool on Wed Feb 07 2018 13:21:45 GMT-0600 (CST) G1 R1 Z5 F6000 ; go to 5mm above position of the last print move G1 R1 ; go back to the last print move M83 ; relative extruder moves ;G1 E2 F600 ; extrude 10mm of filament
-
For now I recommend that anyone using 2.02RC5 comments out any G1 R1 command in the resume.g file.
-
I've found why it doesn't allow you to do a G30 immediately after prox and distal homing. It calculates the XY position from the homed position, then when preparing the G30 move it has to calculate prox and distal positions back from XY. Because of a slight rounding error in the round-trip calculation, it thinks the prox and/or distal position is slightly beyond the homing switch limit. So it abandons the G30 move.
For 2.02RC6 I have saved the XY and arm positions in the position cache, so that it can bypass the calculation of XY from the arm angles. This allows G30 to be performed immediately after prox and distal homing.
The "Add test" move you added should work around the problem. Please can you explain what you mean when you said "Print test ok but impossible to put it in the right place because no absolute movements ...".
Alternatively you can use a regular G1 X... Y... move at that point to put the print head at a specified XY position, which is what my homing file did before I removed that command to investigate the problem with G30.
-
David In advance thanks for your changes in 2.02RC6
Humm of memory ... because the test of impression I had realized it on version 2.02RC3..4 ?
in short the impression started from my homing position,
it was not in the right place because no absolute movements -
Last night my print stopped dead in it's tracks with the nozzle stopped in mid print. The DWC was apparently reset, because there was no history in the gcode console. There was no saved state file. All this sounds like it could be down to a power outage, EXCEPT that the hot end and bed were still at the temperature from the job, and M591 D0 reports the history between 64% and 95% as if the job were still in process. It's 2.0RC5 Maestro. I'm moving my UPS so I can plug the Ender into it.
--Ideas?
-
@3dmntbighker said in Firmware 2.02RC5 now available:
Last night my print stopped dead in it's tracks with the nozzle stopped in mid print. The DWC was apparently reset, because there was no history in the gcode console. There was no saved state file. All this sounds like it could be down to a power outage, EXCEPT that the hot end and bed were still at the temperature from the job, and M591 D0 reports the history between 64% and 95% as if the job were still in process. It's 2.0RC5 Maestro. I'm moving my UPS so I can plug the Ender into it.
--Ideas?
What did M122 say was the reason for the last reset?
-
@dc42 said in Firmware 2.02RC5 now available:
@3dmntbighker said in Firmware 2.02RC5 now available:
Last night my print stopped dead in it's tracks with the nozzle stopped in mid print. The DWC was apparently reset, because there was no history in the gcode console. There was no saved state file. All this sounds like it could be down to a power outage, EXCEPT that the hot end and bed were still at the temperature from the job, and M591 D0 reports the history between 64% and 95% as if the job were still in process. It's 2.0RC5 Maestro. I'm moving my UPS so I can plug the Ender into it.
--Ideas?
What did M122 say was the reason for the last reset?
I'm afraid I just turned it off and went to work. If it stores beyond that I can check when I get home.
-
@dc42 said in Firmware 2.02RC5 now available:
@3dmntbighker said in Firmware 2.02RC5 now available:
Last night my print stopped dead in it's tracks with the nozzle stopped in mid print. The DWC was apparently reset, because there was no history in the gcode console. There was no saved state file. All this sounds like it could be down to a power outage, EXCEPT that the hot end and bed were still at the temperature from the job, and M591 D0 reports the history between 64% and 95% as if the job were still in process. It's 2.0RC5 Maestro. I'm moving my UPS so I can plug the Ender into it.
--Ideas?
What did M122 say was the reason for the last reset?
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.02RC4(RTOS) running on Duet Maestro 1.0
Board ID: 08DAM-9F9DA-MWNS8-6JTD0-3SD6T-953AZ
Used output buffers: 1 of 20 (15 max)
=== RTOS ===
Static ram: 21428
Dynamic ram: 97792 of which 0 recycled
Exception stack ram used: 212
Never used ram: 11640
Tasks: NETWORK(ready,456) HEAT(blocked,1260) MAIN(running,3672) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:00:51 ago, cause: power up
Last software reset at 2018-12-12 11:34, reason: User, spinning module GCodes, available RAM 11640 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 19.3, current 24.1, max 24.1
Supply voltage: min 24.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, read errors 0, write errors 0, ifcount 7, reads 2046, timeouts 0
Driver 1: standstill, read errors 0, write errors 0, ifcount 7, reads 2046, timeouts 0
Driver 2: standstill, read errors 0, write errors 0, ifcount 7, reads 2046, timeouts 0
Driver 3: standstill, read errors 0, write errors 0, ifcount 7, reads 2046, timeouts 0
Driver 4: standstill, read errors 0, write errors 0, ifcount 7, reads 2046, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2053
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2052
Date/time: 2018-12-14 22:22:52
Slowest loop: 2.42ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 69.92ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0 sensor: position 0.00, ok, framing errors 0, parity errors 0, no calibration data -
@3dmntbighker said in Firmware 2.02RC5 now available:
I'm afraid I just turned it off and went to work. If it stores beyond that I can check when I get home.
Sadly, it does not persist this information across (any kind of) restart.
But that sparked the following idea in me: what about saving the results of a
M122
together with date and time (if available) to e.g./sys/diagnostics
whenever RRF does detect a power loss and is not printing at the same time (since then creatingresurrect.g
etc. must be a priority)?!