Should M999 terminate the DSF core application?
-
@Danal said in Should M999 terminate the DSF core application?:
And, "security" keeps coming up. I'm really not sure why. sudo gets mentioned, etc. None of that needs to enter into an implementation of duetcontrolserver restart. Perhaps folks are thinking that duetwebserver would need to kill duetcontrolserver? There is a tested pull out there that does not do this... (tested by two end-users)
Partly because the problem goes way beyond M999, and you still end up with an unprivileged user affecting a privileged process.
-
@Danal said in Should M999 terminate the DSF core application?:
Personally, I'd be in favor of a full SBC restart as a result of an M999. In my opinion, this should also be the default.
...And again, what should the default behavior, no options, of M999 be?
I think I disagree with the default rebooting the entire SBC operating system. First, that would require su permissions (while terminating processes running as 'duet' would only require the duet user.) Second, it creates possible unintended side effects.
In other words, rebooting the entire SBC takes "duet" functionality outside of the "duet" sandbox.
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
@bearer said in [Should M999 terminate the DSF core application?]
Partly because the problem goes way beyond M999, and you still end up with an unprivileged user affecting a privileged process.
I truly don't understand that statement. EVERY SINGLE g-code handled by duetcontrolserver is "an unprivileged users affect a privileged process".
If you mean things like changing the hostname or IP, that is (still? once again?) seeing the Pi as somehow 'separate' from the Duet system. It is, in a D3+Pi configuration, literally, the WiFi network interface for the Duet system, and the "Gcode everywhere" core principal says that M552 "has the correct level of privilege" to set that IP.
-
I agree with @Danal with respect to why M999 should case a rest of some sort on the SBC. While running RC6 I frequently had to restart DCS because the system became unresponsive and this solved it, and I did this by SSHing into the Pi to do this. This is okay while I'm sitting next to the printer with a laptop testing stuff, but long-term this isn't an acceptable way of recovering control (the alternative being a power cycle) not only because most users aren't going to now how to do this or even care about learning how to do this, but because even "power users" aren't always going to the tools immediately to hand to do this. So it makes sense that M999 / Emergency Stop on DWC should be able to recover control quickly and efficiently.
As for whether this should be in the form of resetting DCS or a full restart of the SBC, personally, I'm not keen on the idea of having to reset the whole SBC. My guess is that typically it'll only need to be DCS that needs a restart and if the SBC really needs a whole reboot then the system probably has bigger issues that need addressing.
-
@garyd9 said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
Personally, I'd be in favor of a full SBC restart as a result of an M999. In my opinion, this should also be the default.
...And again, what should the default behavior, no options, of M999 be?
I think I disagree with the default rebooting the entire SBC operating system. First, that would require su permissions (while terminating processes running as 'duet' would only require the duet user.) Second, it creates possible unintended side effects.
In other words, rebooting the entire SBC takes "duet" functionality outside of the "duet" sandbox.
Yeah, I don't have much hope of actually getting broad consensus to make that the default.
People still see the SBC as somehow separate from the Duet system. Example: "Sandbox". Example: "SU permissions". That entire way of thinking is very Pi centric. It stopped being a Pi the moment it got bolted into the printer.
Again, I don't really expect to convince people of this. So let's ask the broader community:
Assume M999 can reset:
- just the board
- board + DSF
- board + DSF (somewhat implicit in the reboot) + Pi (reboot)
What should the default, M999 with no arguments, be?
Delta / Kossel printer fanatic
-
Just throwing in a few thoughts: There could be a parameter for M999 that tells DCS to restart provided M999 only resets the Duet 3 + expansion boards. In addition, we will need a new M-code to either shut down or restart the Pi on demand. All of these actions could be made easily accessible on the Machine Settings page of DWC for users of DSF.
PS: I agree more G-codes should effect the machine configuration if users are on DuetPi. We will come up with a new DSF plugin to achieve that. I don't want to distract too much from the actual question though: What should M999 do by default?
-
@chrishamm said in Should M999 terminate the DSF core application?:
ll come up with a new DSF plugin to achieve that. I don't want to distract too much from the actual question though: What should M999 do by default?
Personally, my vote would be for:
- M999 resets the board, expansion boards and DSF by default
- M999 with some parameter can reset the board, expansion boards and the whole SBC
- M999 with some other parameter runs some *.g file to "park" the physical system and then safely shuts down the SBC
-
@ChrisP said in Should M999 terminate the DSF core application?:
@chrishamm said in Should M999 terminate the DSF core application?:
ll come up with a new DSF plugin to achieve that. I don't want to distract too much from the actual question though: What should M999 do by default?
Personally, my vote would be for:
- M999 resets the board, expansion boards and DSF by default
- M999 with some parameter can reset the board, expansion boards and the whole SBC
- M999 with some other parameter runs some *.g file to "park" the physical system and then safely shuts down the SBC
Sounds great. Q: Is that third one really the existing "pause" or "stop" g-code followed by an M999 with the shutdown param?
Delta / Kossel printer fanatic
-
@Danal said in Should M999 terminate the DSF core application?:
People still see the SBC as somehow separate from the Duet system
i wonder why; where did you buy your SBC?
-
@Danal said in Should M999 terminate the DSF core application?:
@ChrisP said in Should M999 terminate the DSF core application?:
@chrishamm said in Should M999 terminate the DSF core application?:
ll come up with a new DSF plugin to achieve that. I don't want to distract too much from the actual question though: What should M999 do by default?
Personally, my vote would be for:
- M999 resets the board, expansion boards and DSF by default
- M999 with some parameter can reset the board, expansion boards and the whole SBC
- M999 with some other parameter runs some *.g file to "park" the physical system and then safely shuts down the SBC
Sounds great. Q: Is that third one really the existing "pause" or "stop" g-code followed by an M999 with the shutdown param?
Hmm, yeh, very possibly somethings similar, but I'm not sure the same. Take for example the case where you want to shutdown the system and walk away - pause.g or stop.g won't necessarily wait for heaters to be cool etc. The thing I had in mind I guess is similar to setting all setpoints to 0 and then doing M116... but you'd need an M code or some means of defining the "safe" temperature when it's okay to shutdown the SBC etc. Just an idea.
-
@bearer said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
People still see the SBC as somehow separate from the Duet system
i wonder why; where did you buy your SBC?
Duet specifies a range of hardware/software choices to go in that spot as a component of the Duet system.
Delta / Kossel printer fanatic
-
Holy Moly. You sleep in and look what you miss.
I don't actually care what M999 can do as long as I can configure it either with gcode parameters or entries in config.json. I'm kinda hesitant to recommend the default be "restart everything" but after thinking about it, maybe it should. @Danal and @gloomyandy I -1's your posts but after I wiped the sleep from my eyes I'm OK with it. I can't remove the -1's though.
My big concern is that there's no one-size-fits-all solution for this except to make it configurable.
For instance, I'd never want my Jetson Nano SBC to be restarted. I also think that even a 5 second restart delay is too much for the DCS. In this case, it should start immediately. That, however, I can override in a duetcontrolserver.service.d conf file. -
@Danal said in Should M999 terminate the DSF core application?:
@bearer said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
People still see the SBC as somehow separate from the Duet system
i wonder why; where did you buy your SBC?
Duet specifies a range of hardware/software choices to go in that spot as a component of the Duet system.
I don't look at it like that, and I don't think many other people do/will. If it's nothing but a simple component of the duet, it's an incredibly .. clunky.. component. It would be like spooling up a Windows 10 Pro machine with the sole purpose of driving a USB webcam.
I'd suggest that if the SBC is actually a "part of" the duet system, it's a downgrade of the system due to making the duet harder to use. With the SBC connected, I can't just flip the power switch to turn everything off. I have to gracefully shutdown. With the SBC connected, I have more parts I have to maintain (in terms of both hardware and software.)
Typing this makes me realize that the SBC can be seen as being a reversion to the older printer controller boards that require a PC to be attached when printing - and the PC sends single gcode commands over the USB link. (Of course, the DSF/Duet combo is much faster than that.) Is that a good thing?
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
@garyd9 said in Should M999 terminate the DSF core application?:
With the SBC connected, I can't just flip the power switch to turn everything off
This is an open question among many people. I have a Pi on a CNC, a Duet printer, and a couple of monitors. I haven't done a shutdown on any of them, I've just yanked power, in years. One of the monitors in particular is under heavy development, and I must have power cycled that thing eight or ten or a dozen times a day since I started the github, which shows to be about 9 days ago.
Let me be clear, I am not trying to re-open the "pi shutdown" debate, nor convince anybody to do anything different. Everybody do what they believe to be right.
However, don't take the need to shutdown as "carved in stone" either.
Who knows, maybe I'll get burned tomorrow.
Delta / Kossel printer fanatic
-
@garyd9 said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
@bearer said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
People still see the SBC as somehow separate from the Duet system
i wonder why; where did you buy your SBC?
Duet specifies a range of hardware/software choices to go in that spot as a component of the Duet system.
I don't look at it like that, and I don't think many other people do/will. If it's nothing but a simple component of the duet, it's an incredibly .. clunky.. component. It would be like spooling up a Windows 10 Pro machine with the sole purpose of driving a USB webcam.
I'd suggest that if the SBC is actually a "part of" the duet system, it's a downgrade of the system due to making the duet harder to use. With the SBC connected, I can't just flip the power switch to turn everything off. I have to gracefully shutdown. With the SBC connected, I have more parts I have to maintain (in terms of both hardware and software.)
Typing this makes me realize that the SBC can be seen as being a reversion to the older printer controller boards that require a PC to be attached when printing - and the PC sends single gcode commands over the USB link. (Of course, the DSF/Duet combo is much faster than that.) Is that a good thing?
I believe I understand your perspective, at least in some ways.
I would nit-pick the "more parts to maintain", given that the upgrade activities for a D3+Pi are much simpler than for any past duet. No finding files, no figuring out which combinations you need. Just choose your feed, and run the same two commands whenever you wish to advance. (assuming this technique becomes reliable, and I believe it is already there).
Having said that, more/less clicks to maintain is probably not all that relevant to the philosophic question of "part of the system" or not.
I would also challenge the metaphor to old USB. Having a PC or Mac with all of its functionality drive a printer is very different than a dedicated SBC. Various "embedded" use cases are one of the big reasons that SBCs were invented.
Again, fun discussion, but not all that relevant to the underlying question.
So let me ask it this way. A popular use for RPi is a "whole home" or "home automation" controller. Would anyone consider running this function on the physical Pi embedded in their 3D Printer? Probably technically possible... but it would seem very non-optimal to combine these things. That leads back to the philosophic question: Is the SBC bolted into a given printer part of the Duet implementation on that printer? or is it somehow separate?
-
@Danal said in Should M999 terminate the DSF core application?:
So let me ask it this way. A popular use for RPi is a "whole home" or "home automation" controller. Would anyone consider running this function on the physical Pi embedded in their 3D Printer? Probably no technical reason you can't... but it would seem very non-optimal to combine these things. That leads back to the philosophic question: Is the SBC bolted into a given printer part of the Duet implementation on that printer? or is it somehow separate?
I think it's "part of the printer" BUT it may be doing things nor directly involved in printing, like running your DuetLapse
or maybe later, even slicing. I'd hate to send M999 and have the SBC restart in the middle of combining all those jpegs into an mp4 or aborting a slice. -
@gtj0 said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
So let me ask it this way. A popular use for RPi is a "whole home" or "home automation" controller. Would anyone consider running this function on the physical Pi embedded in their 3D Printer? Probably no technical reason you can't... but it would seem very non-optimal to combine these things. That leads back to the philosophic question: Is the SBC bolted into a given printer part of the Duet implementation on that printer? or is it somehow separate?
I think it's "part of the printer" BUT it may be doing things nor directly involved in printing, like running your DuetLapse
or maybe later, even slicing. I'd hate to send M999 and have the SBC restart in the middle of combining all those jpegs into an mp4 or aborting a slice.So if the default M999 is "board + DSF" and it takes an extra parm to reboot the SBC, would that would be a good balance?
-
@Danal said in Should M999 terminate the DSF core application?:
@gtj0 said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
So let me ask it this way. A popular use for RPi is a "whole home" or "home automation" controller. Would anyone consider running this function on the physical Pi embedded in their 3D Printer? Probably no technical reason you can't... but it would seem very non-optimal to combine these things. That leads back to the philosophic question: Is the SBC bolted into a given printer part of the Duet implementation on that printer? or is it somehow separate?
I think it's "part of the printer" BUT it may be doing things nor directly involved in printing, like running your DuetLapse
or maybe later, even slicing. I'd hate to send M999 and have the SBC restart in the middle of combining all those jpegs into an mp4 or aborting a slice.So if the default M999 is "board + DSF" and it takes an extra parm to reboot the SBC, would that would be a good balance?
Works For Me!
-
Yeah, I think that's a pretty good balance spot.
I also think it answers the question that Chris originally asked. Fun discussions... and a conclusion! Will wonders never cease!.
-
@Danal said in Should M999 terminate the DSF core application?:
This is an open question among many people. I have a Pi on a CNC, a Duet printer, and a couple of monitors. I haven't done a shutdown on any of them, I've just yanked power, in years.
This is like saying "I manually spin my stepper motors really fast all the time while they are still plugged into the duet, and never once have I experienced a problem."
Frequently not having a failure doesn't mean it's not a reckless thing to do, and your argument could even encourage other people to do the same reckless thing. There is simply no (reasonably feasible) way to ensure a clean shutdown of a raspbian included read/write filesystem on sudden power loss. It might even be a good idea on these SBCs to disable the filesystem write cache, and force all the logs, etc, to be written to a tempfs.
@Danal said in Should M999 terminate the DSF core application?:
So let me ask it this way. A popular use for RPi is a "whole home" or "home automation" controller. Would anyone consider running this function on the physical Pi embedded in their 3D Printer? Probably technically possible... but it would seem very non-optimal to combine these things. That leads back to the philosophic question: Is the SBC bolted into a given printer part of the Duet implementation on that printer? or is it somehow separate?
On a current Raspberry Pi, no - but only because of the limitations of the board. If I had a SBC with a better processor, and much faster file I/O, I'd have no problem whatsoever doing that. I could justify it as both are functions that control physical appliances.
