Job status by filament usage
-
Firrmware development will shift to RRF 3 which runs on Duet 2 and Duet 3. Don't expect major new features for RRF 2.
-
@deckingman this is another example of what I believe to be improper prioritization.
I've brought this up before. There is a large install base using the duet 2 boards. Current customers shouldn't be ignored to do new product development.
You're not going to keep those users. If there was a comparable alternative, I would have switched long ago.
This particularly ticks me off because it's a regression.
Seems like they could use a DevOps guy to help build tools that can automate testing, code analysis, etc.
-
@gnydick RRF3 works on duet 2 boards as well as duet 3, so I really don’t see what the problem is. RRF3 gives more flexibility in regards to assignment of motors, end stops and heaters and hopefully soon conditional g code which will be a great feature. People can move onto it if the so choose. They also have not said that development on the duet 2 family hardware will stop entirely. The changes between the last two releases of duet 2 boards has been minimal, so again I don’t see what the problem is.
My 2cents worth anyway.
Sam
Custom Core-XY
-
@gnydick You talk like I'm part of the Duet team. I'm not. I'm just an end user like you. So don't shoot the messenger.
But unlike you, I quite like the Duet range of products. If you actually read the quote from DC that I posted, and also the response that Tony posted, you'll understand that it is in fact the current user base that is being given priority. For further confirmation of that, I can also say that my printer which uses prototype expansion boards is in a non working state and has been ever since those boards were fitted. This is because there are some as yet unresolved issues with the expansion board firmware. But I'm not making a fuss because I understand that these issues are being given lower priority than issues related to current, non prototype boards. -
@deckingman I didn't mean to. I was using the general "you".
-
@samlogan87 my issue is that, every time I have reported a bug, I was told it is fixed in the next release and encouraged to use the RC until the next stable came out. Well, the RC invariably broke something else. So, I end up waiting for MONTHS for the next stable because I don't want to find a new bug. Also, when the fix is already known, he refuses to apply it to the current release. Fixes only go forward. This is not an acceptable software development practice IMHO.
-
@samlogan87, oh, also, I wouldn't touch RRF3 with a ten foot pole until it's been out at least 18mo. I can guarantee it will not be as stable as RRF2.
-
Time for my opinion!
I greatly appreciate the Duet team, and their support is always far above-par! I find it quite impressive that they do their customer support themselves, and come out with major new features on the time schedule that they do! Software and hardware development take an enormous amount of time, and somehow they're still on the forums seemingly almost 24/7!
Hats off to the Duet team, @dc42 and @T3P3Tony, as well as all the "regulars" such as @deckingman, @Phaedrux, @zapta, and all the others! Your tremendous work and dedication make the Duet ecosystem what it is - awesome boards with great support and insanely fast development!
@gnydick, a board with even slightly better support would be almost unbelievable! Be sure to tell me if you can find one!
I've tinkered with software development before, and I think their support is far above what's required or even expected.
Thanks again!
-
@JadonM There's a difference between keeping up to date with questions on the forum where people need help with configuration and bugs. The former is fantastically supported, you are right. It's the bugs that get short shrift.
-
I wasn't going to comment but you're acting like bugs are ignored. Bugs do get fixed, they just don't get back ported into every old version of the firmware. And for some reason this really sticks in your craw. But frankly it's pretty unrealistic to expect from such a small software team. Even a long term service style release would require an inordinate amount of work.
-
@Phaedrux you're allowed your opinion. I'm not asking for things to be back ported to every old version. I'm asking that a known bug-fix be incorporated into just the last single stable release.
As for not being ignored. I've reported one bug that I've managed to reproduce with video evidence on 4 different duet boards and it's just been dropped on the floor. As far as I can tell, it will never be fixed.
-
@gnydick said in Job status by filament usage:
@Phaedrux you're allowed your opinion. I'm not asking for things to be back ported to every old version. I'm asking that a known bug-fix be incorporated into just the last single stable release.
As for not being ignored. I've reported one bug that I've managed to reproduce with video evidence on 4 different duet boards and it's just been dropped on the floor. As far as I can tell, it will never be fixed.
It will be fixed when a new version goes stable.
Job status by filament usage isn't a critical thing with need be fixed immediately.
So don't be rude and wait for RRF 3 to be stable. -
@dragonn I'm not being rude. I'm conveying my experience with the duet team/product as well as my 22+ years of being an engineer as well and what my expectations are. If you don't agree, that's up to you. I'll say it again, the end-user support for getting things working is fantastic. Handling of bugs is not. That's my opinion and I'm allowed to have it.
While status by filament isn't critical, it was the only accurate measure for me. In fact, it was eerily accurate. I miss it.
-
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.
-
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.
-
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.
-
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.
-
@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.
-
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).
