Cancelling a print "un-homes" axes
-
Can you at least post your config.g, pause.g, cancel.g?
-
@Phaedrux honestly, it's nothing to do with my scripts. I've printed thousands of prints that I've cancelled because I'm tweaking and tuning quality for intricate functional prints. It happens randomly, less than .1% of the time. Please just take it as face value that it's a bug. Though it has happened twice in the last 3 days, which is odd.
-
@gnydick said in Cancelling a print "un-homes" axes:
@Phaedrux honestly, it's nothing to do with my scripts. I've printed thousands of prints that I've cancelled because I'm tweaking and tuning quality for intricate functional prints. It happens randomly, less than .1% of the time. Please just take it as face value that it's a bug. Though it has happened twice in the last 3 days, which is odd.
Great. Thanks for the single data point with no context. We'll just have to wait until it affects someone else so we can see the relevant files.
-
@gnydick said in Cancelling a print "un-homes" axes:
It's none of that. I print TONS of stuff. This, and other weird behaviors just seem to happen after the unit has been on for several days.
Power brownout? Or Duet resetting for some other reason? Next time it happens, run M122 and look at the time and reason of the last reset.
-
@Phaedrux my files have been reviewed umpteen times and there's never anything wrong with them. I'm posting a bug that is most likely some sort of race condition/buffer overflow/underrun, etc. Having my config will not help with anything. I'm not running any unusual configuration.
-
@dc42 nope, no brown out or other power issues. The machine wasn't reset, as the heaters didn't turn off. I'll run M122 and see if anything shows up.
-
@gnydick said in Cancelling a print "un-homes" axes:
Having my config will not help with anything.
It will if there is something particular to your config that is the base cause of this. Since this is not happening to everybody else, at least not enough that anybody is recognising and reporting it, it is doubly important that you give configs and all relevant background, so that the discussion has context.
That way, when/if someone else experiences this in the future, support can do the basic triage where they look for commonality between the setups.
I've done years of supporting hard-core software issues with customers who tinker, let me assure you that insisting you have a really important bug, while nobody else can see it, and then refusing to provide expanded context will generally result in dissatisfaction. You need to decide if this is really important to you, if it is, please be helpful when people make reasonable requests.
-
@gnydick said in Cancelling a print "un-homes" axes:
@Phaedrux my files have been reviewed umpteen times and there's never anything wrong with them. I'm posting a bug that is most likely some sort of race condition/buffer overflow/underrun, etc. Having my config will not help with anything. I'm not running any unusual configuration.
Even if there is no issue with your config having it available to help narrow down which subset of conditional code is relevant for your setup will greatly reduce the troubleshooting effort, so show some respect and comply with the request made, not just whatever pleases your highness.
-
@bearer I know. I've been a bit crispy. My apologies to everyone. I'll post it when I get a chance.
-
FWIW the only times that axes get set to not-homed are:
- when a reset occurs, due to power up, emergency stop, exception, or any other reason;
- when M18 or M84 is used to turn off the motors;
- when a G28 command has been started and the homing switches have not yet been triggered
Of course I can't exclude the possibility of a firmware bug causing axes to be set to not-homed at other times, but I don't think anyone else has reported anything similar.
EDIT: I just double checked the code. M665, M666, M667 and M669 also flag the axes as not homed. So will M500 if the config-override.g file contains M665 and M666 commands.