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?
-
@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.
-
Re: Shutdown.
We are going to disagree on this one.
And, no, those two situations are not at all parallel. There is an RPM of steppers that WILL cause damage. This is simply provable, in moments (I won't ask anyone to demonstrate). There is no way to prove or disprove that fsck on startup will or won't handle any possible power down state, simply because you can't prove a negative.
Again, I really didn't want to reopen this debate. Every individual should do what they believe is right. Please, no one should change their habit based on THIS discussion.
Re: Running multiple things.
So you'd keep your printer powered on at all times to run your home auto? (Or maybe power up and down subsections...) And you'd accept interruptions to your home auto when you had no choice than to power cycle the printer? And so on and so forth. There is no right answer here, but this all seems contrary to the mission of "single board, embedded, computers".
I sincerely hope SBCs are headed the other way... more of them (not fewer), single "function" (maybe "area of function" is a better phrase), and so forth. More specialized, not more shared.
Again, we may have to agree to disagree.
-
@Danal said in Should M999 terminate the DSF core application?:
Re: Shutdown.
Again, I really didn't want to reopen this debate.Why keep debating it immediately before stating you didn't want to reopen it?
So you'd keep your printer powered on at all times to run your home auto? (Or maybe power up and down subsections...) And you'd accept interruptions to your home auto when you had no choice than to power cycle the printer? And so on and so forth. There is no right answer here, but this all seems contrary to the mission of "single board, embedded, computers".
If you look above, you'll see that I don't see the SBC as integrated as part of the printer. I see it as something that controls the printer. Just as a computer controls my webcam, and the computer running my home automation controls a light switch. So, I wouldn't power down my home automation if/when I power down the printer: I'd turn off the printer and leave the SBC running. (I already do this.)
"Single board computer" doesn't mean "single purpose computer." As well, it's not embedded within the duet. An embedded system wouldn't be sold separately from a different company with a different physical footprint that's optional. It would be "embedded." As well, most devices that actually embed linux-based OS's (such as home internet routers) configure the OS to be more tolerant of power outages (by not caching filesystem (or NVRAM) writes, and using tempfs for logs, etc) and do other things that essentially make the underlying OS (and general purpose processor) invisible.
-
@garyd9 said in Should M999 terminate the DSF core application?:
Why keep debating it immediately before stating you didn't want to reopen it?
Because you keep posting about it and I do wish that bystanders know there are two, widespread, operational practices. I don't want people to change in either direction without more research on their own.
-
@Danal said in Should M999 terminate the DSF core application?:
@garyd9 said in Should M999 terminate the DSF core application?:
Why keep debating it immediately before stating you didn't want to reopen it?
Because you keep posting about it and I do wish that bystanders know there are two, widespread, operational practices. I don't want people to change in either direction without more research on their own.
That's fair. I hope you don't take offense at my debating with you. Discussion is the best way to share different views/opinions. Once in a while, new and better ideas are the result.
-
@garyd9 said in Should M999 terminate the DSF core application?:
@Danal said in Should M999 terminate the DSF core application?:
@garyd9 said in Should M999 terminate the DSF core application?:
Why keep debating it immediately before stating you didn't want to reopen it?
Because you keep posting about it and I do wish that bystanders know there are two, widespread, operational practices. I don't want people to change in either direction without more research on their own.
That's fair. I hope you don't take offense at my debating with you. Discussion is the best way to share different views/opinions. Once in a while, new and better ideas are the result.
Actually, I enjoy the heck out of these discussions! I'm always a little worried about the person at the other end, so it is very nice to hear your statement.
-
Just to save @chrishamm some reading, a consensus emerged above:
M999 should:
- With no parms restart RRF on the board, and DSF (at least duetcontrolserver) on the Pi.
- With optional parms, it should also be capable of restarting:
- RRF on Board only
- DSF (dcs?) only
- Rebooting the entire Pi.
Anyone correct anything if it is wrong, or even in the slightest misleading.
-
To continue this discussion a bit further...
https://github.com/chrishamm/DuetSoftwareFramework/issues/120The current implementation seems to create a race condition....
- M999 is issued.
- RRF is restarted and DCS is killed.
- RRF looks for config.g from DCS but DCS isn't there.
- RRF hangs at "Off".
- DCS starts but RRF is Off so there's nothing you can do.
- Issuing M999 again restarts the cycle.
I'd like to suggest that on startup, DCS check RRF state and if it hasn't already loaded config.g, load it.
@dc42 is there a way for DCS to tell if RRF has or has not run config.g? I don't think we'd want DCS to restart RRF if it had run config.g but was Off for some other reason. Just if it hadn't initialized the first time.
-
Interesting. Shouldn't RRF, on every startup, look for the SD files first, and if not found, wait in a known state for DSF to contact it? That was my impression of how ordinary power on worked.
On a restart, what would be different?
