Job status by filament usage
-
Or it is you that is wrong. This is my opinion and how I feel.
dc42 administrators 8 Oct 2019, 19:58
I have just released RRF 2.04RC3 at https://github.com/dc42/RepRapFirmware/releases/tag/2.04RC3. From the whatsnew file:
Compatible files:
DuetWiFiServer 1.23
DuetWebControl 2.0.2 (recommended) or 1.22.6
Upgrade notes:
If using this release to control a laser cutter/engraver, see the notes below on changed handling of the G1 S parameter
Feature improvements/changed behaviour:
mDNS is now supported on the Duet Ethernet and Duet Maestro
In Laser mode, if sticky laser power mode is selected, the power set by the S parameter in a G1 command is remembered across G0 moves to the next G1 move
CRC checking of uploaded file data is now supported (requires DWC 2.0.2)
When an error occurs reading or writing SD card data, the number of retries is increased to 5 and the delay between retries increases with each retry
Increased minimum motor current for open load warnings from 300 to 500mA
When writing the resurrect.g file, select the active tool before calling resurrect-prologue.g. This is to allow extrusion to be done in resurrect-prologue.g.
Bug fixes:
M675 did not take workplace coordinate offsets into account
Duet WiFi/Ethernet + DueX configurations did not start up if excessive noise was present on the DueX endstop or GPIO inputs
The SHA1 has reported by M38 sometimes had one or more zero digits missing
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com……..Complete with all other unresolved bugs!
-
@chas2706 Of course you are entitled to your opinion. But you made a factually incorrect statement which is wrong. That's what I meant when I said you were wrong.
On 8 Oct 2109 @ 21:42 you stated ".........RRF2 along with all of its remaining bugs has now been abandoned for RRF3............." Yet on the same date at 19:58 DC posted that RRF 2.04 RC3 had been released.
That is clear evidence that RRF2 has NOT been abandoned therefore you are wrong. Furthermore, this is an RC (Release Candidate). So it's entirely possible that bugs still remain. But that doesn't mean that they will never be fixed.
And finally but most importantly, this post probably isn't getting the attention it deserves because it has been posted in the wrong section. This is "Firmware Wishlist". But as I pointed out above, filament estimations are a function of the Duet Web Control and nothing to do with the firmware.
I respect that you have your own opinion, but it is based on factually incorrect assumptions - i.e. that development has been abandoned, and also that bugs exist in the firmare which do not (because they relate to the web control software and not the firmware).
-
@deckingman it's a firmware issue.
-
@gnydick "Job status by filament usage" is a firmware issue?? This the filament usage displayed in the web interface that we are talking about?
Or are you using some weird volumetric extrusion and it's M200 setting of filament diameter that's screwed up?
-
Sorry Im pulling out of this discussion. Its started to sound like an episode on Judge Rinder.
"@deckingman On 8 Oct 2109 @ 21:42 you stated ".........RRF2 along with all of its remaining bugs has now been abandoned for RRF3............." Yet on the same date at 19:58 DC posted that RRF 2.04 RC3 had been released."
My actual point was:
Quote "I currently run RRF 2.02RTOS (of which is stable) and dare not "upgrade" to any of the "RC" releases after this release because of problems personally experienced in doing so."
No reply please end of. -
Let's try to keep the discussion limited to the relevant reported bug.
-
I also think that bugs should be handled in a better way.
Why not using the a.b.c release scheme? 'a' for major, 'b' for minor', and 'c' for fixes.
New features should only be added on minor releases, or in major releases when they breaks backward compatibility. Then, when a bug is found, it should be fixed in the current minor by incremeting 'c' (and, of course, in the next minor under dev.).
git allow easy patching between branches, so from a developper point of view, it is not much work.
-
@fma hallelujah. I've been saying this for months.
-
@Phaedrux said in Job status by filament usage:
Let's try to keep the discussion limited to the relevant reported bug.
I have completely lost track of what bug this is. The first post in this thread gives only a vague sense of what it might be. There may just be time to get it fixed in 2.04RC4, but only if I am given a clear description of the symptom by tomorrow morning.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 your guess is as good as mine. I wasn't able to find reference to anything else from searching other than this: https://forum.duet3d.com/topic/10581/fix-to-show-correct-filament-usage-in-dwc-for-slic3r-gcode/12
But I think the prusa slicer filament usage was fixed.
Perhaps @gnydick can restate the problem?
-
@Phaedrux said in Job status by filament usage:
@dc42 your guess is as good as mine. I wasn't able to find reference to anything else from searching other than this: https://forum.duet3d.com/topic/10581/fix-to-show-correct-filament-usage-in-dwc-for-slic3r-gcode/12
But I think the prusa slicer filament usage was fixed.
Perhaps @gnydick can restate the problem?
I've looked through the list of posts by @gnydick at https://forum.duet3d.com/user/gnydick and apart from this thread and one post in the thread you linked to above, I don't see any posts where the title appears relevant to his original post in this thread. So I hope he can clarify what he means.
-
gnydick believes the time to finish estimation based on filament usage became less accurate after a recent firmware update.
msbailly thinks that the filament usage counter employed for that estimate is off because it counts retractions but not the return from retraction.
I think prints take a long time anyway and I just check back later.
Thanks David for all your work.
-
@robm said in Job status by filament usage:
gnydick believes the time to finish estimation based on filament usage became less accurate after a recent firmware update.
Can you link to the post where he says that?
msbailly thinks that the filament usage counter employed for that estimate is off because it counts retractions but not the return from retraction.
If that were the case, the filament used so far that is reported just before the print finishes would be much less than the filament usage reported by the slicer. I haven't noticed that happen, but I'll watch it carefully in my next print.
It's also possible that the slicer has the opposite bug, i.e. in reporting the filament needed it counts re-prime moves but not retractions. If a slicer has this bug, I'm not sure than anyone not running RRF would notice it.
One thing that might throw off the calculation is if firmware retraction is used and in M207 the re-prime amount is set differently from the reaction amount. This will obviously cause the filament consumption to be different from the amount reported by the slicer, and I don't think RRF allows for that. Again, the opposite bug could affect the slicer if it doesn't take account of the "extra restart distance".
-
I watched the figures given by DWC for my latest print as it approached the end. The filament-based estimated end time remained fairly accurate and converged to zero time remaining at the end of the print. The filament usage count at the end tallied exactly with the expected usage count as far as I could tell, certainly within 1mm. This was on a print sliced by S3D version 4.0.0 and not using firmware retraction.
If there really is a problem in RRF in this area, I need more information so that I can reproduce it; for example a sample GCode file along with config.g settings that will enable me to replicate it.
-
PS - one thing I noticed during testing is that if you turn the printer off in the middle of a print and then resurrect it, the print times are inaccurate. This is because the resurrection data doesn't include the amount of filament consumed, so it counts from zero again. I'll make a note to fix this.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
-
@gnydick said in Job status by filament usage:
@dc42 sorry I've been away, @dc42 . The prusa slicer bug is what I'm referring to. The DWC shows nothing for filament usage.
When was that fixed?
Did you read what dc42 has written? Please post a sample g-code file with this problem and config.g. And maybe M122 response because I use Prusa Slicer too and don't have any problems with filament usage.
-
@gnydick said in Job status by filament usage:
@dc42 sorry I've been away, @dc42 . The prusa slicer bug is what I'm referring to. The DWC shows nothing for filament usage.
When was that fixed?
There is an entry for Prusa slicer in the version 2.03 section of the whatsnew file. Is that the one you mean?
-
Prusa slicer just starting to print skirt of model...…….
-
In Cura, all jobs have max layer of 25...…….
