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 creatingresurrect.g
etc. must be a priority)?! -
@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 creatingresurrect.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 2mThat 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.
-
@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.
-
@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.
-
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.
-
@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.
-
@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.