Firmware 2.02RC5 now available

frafa

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

3dmntbighker

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?

dc42

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

3dmntbighker

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

3dmntbighker

@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

wilriker

@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 creating resurrect.g etc. must be a priority)?!

3dmntbighker

@wilriker said in Firmware 2.02RC5 now available:

@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 creating resurrect.g etc. must be a priority)?!

Good idea. Especially for debugging.

I was getting some seriously weird behavior tonight with the candle holder I have been trying to get to print. Sliced in S3D when I started the print no heaters would activate and nothing would home. It just said "processing". At one point I got this:

Error: Bad command: 30.454 Y91.117 E2.8345
Cancelled printing file PLA/candle_tree_V2_95.gcode, print time was 0h 2m

That line is missing the first few characters, and it took 2 minutes to error. The file is like 35MB. Once I changed from 0.2 to 0.3 layer height the file was 26MB and suddenly everything works more or less as expected. This could be a S3D bug (4.1.1) or something with the Duet? The trouble seemed to start when I tried to add some Z lift, but that could be coincidence.

wilriker

@3dmntbighker Have you checked the GCode file for this specific line? If it is in there then this is a S3D bug.

P.S.: File size should not be an issue here.

3dmntbighker

@wilriker said in Firmware 2.02RC5 now available:

@3dmntbighker Have you checked the GCode file for this specific line? If it is in there then this is a S3D bug.

P.S.: File size should not be an issue here.

Here is the line in question from the file:

G1 X130.454 Y91.117 E2.8345

It looks almost identical to the lines above and below. I see nothing wrong with that area of the gcode.

3dmntbighker

I think I verified it's S3D 4.1.1. If I get a file print that doesn't even activate the heaters, I can quit/restart S3D, and re-save the file, and it prints. S3D is a bit of a disaster lately (ever?). I think I'm switching my work flow to CURA.

wilriker

@3dmntbighker This sounds a little bit to me a if you are using S3D as a print server - which is not recommended anyway.
But this line is totally ok. RRF complained about a line that did not start with a G or M or T. So my question was if such a (broken) line exists in the file but it does not.

Apart from all of that I hear a lot of complaints about S3D lately. Development has virtually ceased - probably because a lot of the developers seem to have switched to develop ideaMaker for Raise3D instead.

3dmntbighker

@wilriker said in Firmware 2.02RC5 now available:

@3dmntbighker This sounds a little bit to me a if you are using S3D as a print server - which is not recommended anyway.
But this line is totally ok. RRF complained about a line that did not start with a G or M or T. So my question was if such a (broken) line exists in the file but it does not.

Apart from all of that I hear a lot of complaints about S3D lately. Development has virtually ceased - probably because a lot of the developers seem to have switched to develop ideaMaker for Raise3D instead.

Print server = NO (upload to SD and print)

I opened the gcode file in BBEdit and searched for the string in the error. As I said the line in the file was completely normal. But there could be garbage elsewhere in the file that caused Duet to freak out. Quitting S3D and re-saving it after resulted in a working file.