Job status by filament usage

garyd9

In all fairness to @gnydick, things with RRF2 have kind of been dropped for a significant amount of time (relative to timelines in years past) in order to progress with RRF3 and Duet3.

For example, there's a known delta calibration bug in the last "released" version of RRF2 (2.03.) That bug was fixed within a month in an RC (2.04RC1) 3 months ago. Since then, there's been no visible activity for RRF2. The RC bug fix hasn't been released as 2.04, and there's been no other RC or beta.

Another example is DWC2. Until just a couple days ago, I thought development on it had completely stopped while it was in RC status. It seems it's finally been released outside of RC, but it feels like the changes between the last RC and now only are for RRF3. There are still outstanding bugs with it that are unfixed. (I'd really like to download a gcode file without having to wait 2-3 minutes before the download starts.)

All that being said, however, please keep in mind that RRF (and DWC) isn't a paid product. It's free and open source. The only thing being paid for is the hardware. Anyone is free to grab the source and fix bugs on their own. David doesn't get paid by us for firmware updates, and the fact that he keeps providing them for free is, to be honest, amazing. If he wants to use his time to work on RRF3 or just to play tiddlywinks - its his time - not mine (or yours.)

Would I like to see more progress for the things I personally want? Sure. I'd also like it if the next time David is in the US, he comes over to my house, gives me a free Duet3 board, installs it in my delta, AND ports my RRF2 config over to RRF3 with the new board. (Okay, that's being greedy; I'll install the board myself if David crimps the connectors for me. )

As for being an "acceptable software development practice", you're living in the past. Modern s/w dev practice is to throw as many new features as possible at users, see what sticks, and only fix the bugs that are causing a loss of revenue. (I'm not saying it's GOOD practice, only that it's become the normal practice in recent decades.) I'm extremely grateful that David doesn't follow that pattern.

robm

In my experience The RC's and betas are fine. The state is 'all the known bugs are fixed'. If there's no significant new features or huge issues driving a release, then yes, small bug fixes will just get collected here.

If there's a bug fix you need and it is available in the RC, please try it and see if it solves your problem - then comment either way so the developers can know. In the unlikely event you find a new problem, that would be nice to know too.

If you are relying on the developers to fix the bugs for you and the rest of the community to do the testing for you, then you will have to wait longer for any bug fixes to graduate to a stable release.

deckingman

AFAIK, filament usage is a feature of the DWC is it not? If so, that's Chrisham's domain and not DC's. But in any case, a quick gander at these forums will show that there are very many people asking for many different things. Whether that be new features that require conditional gcode for example, as well as bug fixes that might have crept in. Given that one can already get the most accurate estimation of print time by running a simulation, then it's no wonder that someone has perhaps decided that fixing the estimate based on filament usage is perhaps a lower priority than some other issues. You can please all of the people some of the time, you can please some of the people all of time, but you can never please all of the people all of the time. I happen to know that DC is usually at his computer at 7:00 am and until after 10:00 pm and 7 days a week. But even so, he'll never be able to please all of the people all of the time.

chas2706

I also get what @gnydick is saying. In my opinion RRF2 along with all of its remaining bugs has now been abandoned for RRF3 which will definitely bring along many new bugs and issues. It would not have been so bad if RRF2 "final" was released and left in a usable stable condition.

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.

I get that DC42 puts in everything he has got but isn't he part of Escher3d which is the company that produces and sells the Duet boards? and doesn't he design the boards too?.

Ok, RRF3 is compatible with my now 8 month old Duet2 board but it just makes me feel that I have spent good money on an abandoned project.
I suppose what I am trying to say is that there was so much potential available with Duet2 and RRF2 but was abandoned before its time.

IMO Duet3 is for specialist 3d printer enthusiasts that possess specialist 3D printer equipment and don't see a problem interfacing the board with a RPI just to gain internet access and control.

If Duet2 came with no internet facility and required an RPI, I would have thought twice about purchasing it.

FYI I love the Raspberry PI and have been involved in lots of projects involving them but to me the Duet3 is incomplete if it has no imbedded internet connection.

deckingman

@chas2706 No you are wrong. DC has just a short time ago released the latest RRF 2.04. So it hasn't been abandoned. Furthermore I can say that getting this release done has been David's priority over fixing issues that have come up with gen 3 prototype expansion boards. I know this for a fact because I have a non working gen 3 printer. But I'm not complaining because I know that these new prototypes must have lower priority than current mainstream products.

chas2706

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!

deckingman

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

gnydick

@deckingman it's a firmware issue.

deckingman

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

chas2706

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.

Phaedrux

Let's try to keep the discussion limited to the relevant reported bug.

fma

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.

gnydick

@fma hallelujah. I've been saying this for months.

dc42

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

Phaedrux

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

dc42

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

robm

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.

dc42

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

dc42

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.

dc42

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.