Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.
-
@gtj0 How would I determine whether to post in RRF 3.0RC6 vs. DSF 1.3?
Delta / Kossel printer fanatic
-
@Danal run the job in Duet 3 standalone with the same settings and firmware version?
Ian
-
@Danal said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
@gtj0 How would I determine whether to post in RRF 3.0RC6 vs. DSF 1.3?
I have asked that question many times and I've never received a satisfactory response.
@droftarts said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
@Danal run the job in Duet 3 standalone with the same settings and firmware version?
Ian
Don't get me started.
It's not always easy to just "run in standalone mode". In my case, I have to remove the covers from the printer to get to the sd card and remove the cable between the Duet and the SBC.
I also don't believe it's the user's responsibility to have to determine which component of the system is at fault. That should be Duet3D's responsibility. The fact that RRF and DSF seem to be owned and operated by 2 separate companies irks me to no end.
-
I agree. From a user's perspective, DSF and RRF are the same thing. Gcode goes in one end and motion comes out the other.
For example, it is incredibly weird that M999 restarts RRF but not DSF, even when it is absolutely reproducible that any number of hangs are cleared ONLY by restarting DSF. Which a user of this "gcode everywhere" system has no way to do (other than on the Pi, and with sudo no less!)
I love Duet and have been a happy advocate for at least a few years. I am aghast at the latest directions and actions. I sincerely hope they course correct. (To be clear, I'm all in favor of SBC/Pi integration. It is the way that's being accomplished that is going to send a great company downhill if they don't change something).
Delta / Kossel printer fanatic
-
Also, as regards how easy to "reproduce in stand-alone", I don't have any ethernet that will reach. I am not the first owner of this house, and there is not an inch of Cat anything in it (except about 1 foot (1/2 meter) between the cable modem and the main wireless router). I'm also not real motivated to make a special SD card, run special ether, etc, etc, to run the printer in a mode which I will literally never run. It goes back to DSF and RRF being layers of the same thing, and they should be supported that way.
-
OK, rant over. Sort of.
Delta / Kossel printer fanatic
-
And here I am, just sad that RRF 2 isn't getting the attention it needs and deserves! We need an LTS team!
-
@Danal said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I agree. From a user's perspective, DSF and RRF are the same thing.
I had my sarcastic rant earlier when I quoted DC42's statement that RRF 3.01-RC6 has no bugs.
I agree, I too am not interested if any particular bug is within the RRF, DCS, or DSF. They should all work together as one whole package.
The issue I have is that like you I love the idea of Duet 3 with SBC but there are many problems at the minute and all I seem to get is "It works ok in standalone mode".
If I wanted "stand alone" I would not have purchased RRF 3 and Raspberry Pi 4!
Rant over!
-
@Danal said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
and with sudo no less!
this was a topic way back when, sort of intermingled with permissions on the /opt/dsf/sd folder and /dev/spi nodes and the priority was to get it working first, then revisit.
as such i didn't poke in great detail, but as access to the spi node can be solved by group permissions, listening to port 80 (or any port below 1024) sounds like the last hurdle. the easy woraround would be nginx and a reverse proxy which would also ease setting up ssl with sometihng like letsencrypt (even if not exposed to the internet)
There are larger issues to deal with first i guess - but I will say the state of the supporting firmware and software has not been clearly communicated following the release of the hardware.
I believe I in August said I expected to run RRF2 as the stable version for 6-12 months, and the unfortunate truth of it is that with the limited team developing RRF3 + DSF they need the depend on the community for testing to stand a chance at getting ready for main stream use in such a short timeframe.
At the end of the day its up to the user to choose something tried and true, or accept that early adoption comes with a price tag in more than one sense.
-
@gtj0 said
Don't get me started.
Okay, sorry I mentioned it.
@Danal said
OK, rant over. Sort of.
Okay, sorry, won't mention it again! We appreciate all your support!
@chas2706 said
Rant over!
No, really, I'm sorry for suggesting it, I'll never say it again!
@bearer said
At the end of the day its up to the user to choose something tried and true, or accept that early adoption comes with a price tag in more than one sense.
I agree. It's just taking time to get DSF (which is pretty much brand new) up to speed with the rest of the firmware (painstakingly developed over many years). But without community interest and expertise getting it working, reporting bugs and fixing, it will take much longer. So once again, thank you all for your continued support.
Ian
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@droftarts said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I agree. It's just taking time to get DSF (which is pretty much brand new) up to speed with the rest of the firmware
The activity shown on GitHub regards DSF says it all.
-
@gtj0 said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
It's not always easy to just "run in standalone mode". In my case, I have to remove the covers from the printer to get to the sd card and remove the cable between the Duet and the SBC.
I find that I can switch between standalone and SD mode just by inserting the SD card or not, without removing the SBC cable.
-
@chas2706 said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I had my sarcastic rant earlier when I quoted DC42's statement that RRF 3.01-RC6 has no bugs.
I was sure I typed "no known bugs" when I composed the message, however I composed it on a smartphone and somehow the "known" got lost.
There are now some known bugs in RRF 3.01-RC6 so we are preparing to release 3.01-RC7 along with updated DSF and DWC. See https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md for the changes to RRF.
-
@bearer said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
At the end of the day its up to the user to choose something tried and true, or accept that early adoption comes with a price tag in more than one sense.
Disconnects in the way that RRF vs DSF are being handled by Duet the company are equally applicable to the 'full' releases.
-
@bearer said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
and with sudo no less!
this was a topic way back when, sort of intermingled with permissions on the /opt/dsf/sd folder and /dev/spi nodes and the priority was to get it working first, then revisit.
as such i didn't poke in great detail, but as access to the spi node can be solved by group permissions, listening to port 80 (or any port below 1024) sounds like the last hurdle. the easy woraround would be nginx and a reverse proxy which would also ease setting up ssl with sometihng like letsencrypt (even if not exposed to the internet)
I withdraw my comment regarding sudo. It diverted attention from the real issue: What is the GCODE to restart the system ?
-
@droftarts said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I agree. It's just taking time to get DSF (which is pretty much brand new) up to speed with the rest of the firmware (painstakingly developed over many years). But without community interest and expertise getting it working, reporting bugs and fixing, it will take much longer. So once again, thank you all for your continued support.
This completely misses the points being discussed by at least three or four vocal users. It is a powerful indication of the "blind spot" within Duet that causes me to invest the energy in typing these responses:
Any rational person would expect a new major section of software to climb a maturity curve. Totally agree with you on that. And introducing major new architecture and function in V3.x, I believe we all expect it to take time to stabilize. Regardless of where it runs or what tech stack it uses or... it will just take time, testing, feedback, and improvement. Agreed, D'accord.
All of that has nothing to do with the pervasive attitude that RRF and DSF are two separate things. From the viewpoint of the end user they are one thing with defined external interactions (Gcode, Web API, etc).
There are numerous examples of this mis-perception. All of which are seriously complicating the ability to build, deploy, test with the community, upgrade, downgrade, and generally "deal with" the product that fits under the general header of Duet V3. And the folks at Duet appear to be unable to see or acknowledge this is even happening.
When I said "sort of." above, this is what I meant. I don't believe I am ranting anymore; yet there is still more to discuss. I sincerely hope these strong words are read with the intent they are written: To help Duet get better.
Delta / Kossel printer fanatic
-
@droftarts said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I agree. It's just taking time to get DSF (which is pretty much brand new) up to speed with the rest of the firmware (painstakingly developed over many years). But without community interest and expertise getting it working, reporting bugs and fixing, it will take much longer. So once again, thank you all for your continued support.
Sadly, RRF3 (Duet3 standalone) is significantly more functional than RRF3 (Duet3+SBC.) As long as this is the case, people (such as myself) will use (and test) the standalone code and ignore the SBC/DSF/etc.
For example, do a search for threads where people request PanelDue working properly (for file commands) with a SBC attached to the duet. I've seen "it's easy", "will add that soon" and "it's already there, just need the duet to send the command." Yet.. it hasn't happened. Until that "easy", "will be added soon" and "is already there" bit of functionality works, I won't attach the ribbon cable to my RPi4. (I don't have a computer near my printer, and I won't start a print or macro unless I'm standing near the printer.)
How about the conditional gcode stuff? Is that working in SBC mode yet?
The lack of SBC functionality isn't about community interest, reporting bugs, etc. It's about getting DSF up to a more usable state. I'd happily attach my RPi4 to my duet3 board if I could get a similar level of (even untested) functionality - assuming, of course, I'd have reasonable expectations of bugs getting fixed as fast as dc42 fixes RRF3 bugs. (Which is another gripe: There have been long spans of time where DSF has gone untouched while RRF3 has been moving along.)
I just think it's important to get the ordering of "cause" and "result" correct. The lack of community is a result of lack of development. Not the other way around.
Edit: Just to be clear, I'm not really complaining. I'm happy using my duet3 in stand-alone mode while things move along. However, don't imply that I'm part of the reason that DSF (collectively used to mean all the duet s/w running on the SBC) is lagging so far behind RRF3.
-
I'll just chime in with one more thing:
When Duet 2 was being developed, near the beginning, it was much like this (except not separated so much -- only DWC and RRF, with the original wifi server or whatever too).
I waited very patiently until the code was mature. I bought several Duet 2 boards (before they were called Duet 2) immediately in their infancy. However, RRF was not at a point that it could really be used for what I wanted to do (IDEX printer).
I just waited! I worked on my own stuff and waited. I felt this was fine. I didn't feel I was owed anything by the developers. If anything, I was super gracious that the developers were working so hard on the code to make it work.
Finally, RRF2 got to a point where it was complete enough and reliable enough to use! Hallelujah!
Then, immediately, all the developers decided to abandon RRF2 in favour of RRF3! RRF2 is not as stable a rock as we think it is, but the developers are going full-bore restarting the "wait and see" cycle for RRF3 users.
What about us RRF2 users? Why abandon that so abruptly?
We need a team that is still working on RRF2, while RRF3 is developed! I don't think RRF2 can or should be left in the state it is in.
*not actually a robot
-
@Danal said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
All of that has nothing to do with the pervasive attitude that RRF and DSF are two separate things. From the viewpoint of the end user they are one thing with defined external interactions (Gcode, Web API, etc).
Surely not ideal; but RRF and DWC were two separate things before DSF as well, just more mature, and I don't see any reason to suspect it will not return to that state. I'm also pretty sure its on the Duet3d agenda to unify things as much as possible - the new duet3d github is probably a sign of things to come. As such given maturity who wrote what or who supports what will matter less when the resources to develop and support have a workload thats more matched to the capability.
Meanwhile the user can choose how to deal with.
@Danal said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
I withdraw my comment regarding sudo. It diverted attention from the real issue: What is the GCODE to restart the system ?
This is also as far as I recall a conscious decision to limit gcode's ability to affect the Pi on a system level . At least M550, M552 and and a few others was at least a topic. And to some degree it boils down to lacking SUDO M997 gcode.
-
@bearer said in Incident report: RRF 3 RC6 DWC 2.1.0 Lockup during print.:
This is also as far as I recall a conscious decision to limit gcode's ability to affect the Pi on a system level. At least M550, M552 and and a few others was at least a topic.
I don't doubt that was a conscious design decision. It fits very firmly with the blind spot that Duet sees these two as somehow separate or different. Again, gcode in one end, movement out the other. Gcode configuration codes in one end, immediate effect on the running device out the other.
Given the statements in the image below, gcodes should "affect the Pi on the system level". M550 (set name) absolutely should set the name of the Duet system network interface, i.e. the Pi itself. Same with 552 (set IP address). And many more such codes.
Or, is Duet explicitly changing the philosophies stated below? Particularly "All settings are done through G-Code"?
