Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moire issue disappears after power recovery. #766

Closed
TheBrigandier opened this issue May 24, 2018 · 33 comments
Closed

Moire issue disappears after power recovery. #766

TheBrigandier opened this issue May 24, 2018 · 33 comments

Comments

@TheBrigandier
Copy link

TheBrigandier commented May 24, 2018

Update: If you want to discuss this with a lot of people working on the same issue: https://discord.gg/rchZGUg - we're up to like... 67 people in Discord now? Please only use this issue for information relevant towards a fix! Thanks!

Stumbled on this one, didn't want it buried in #602. While printing a test single wall cube, I had a power flicker that caused my MK3 to initiate a power recovery. After the recovery, the print continued as normal; however, the usual moire was gone completely.

power-recovery-moire

To ensure this wasn't a fluke thing, I tried this again by intentionally pulling the power plug.

In the bottom half of the print, you can see sharp moire lines angling from the top right to bottom left. On the upper half of the print, you can see this is gone. It is hard to capture in an image, but if you try it in person you can definitely see the difference.

Thanks!

@TheBrigandier
Copy link
Author

image

This was from the Discord server we have going for this issue. HUGE improvement. :)

@TheBrigandier
Copy link
Author

@ctilley83 I have no idea really. Our first guess was maybe it was memory related, buffer overflow or some such being fixed by the recovery. Don't know where to begin with this, but PLEASE verify this if you guys can. Would like to see more than a couple people noticing improvement.

@JasonETrowbridge
Copy link

@ff8jake What size cube did you use for the above test? I want to try it once my MK3 is done printing something else.

@uepsie
Copy link

uepsie commented May 24, 2018

@ff8jake did you try to pause and resume the print with getting the same effect on the result?

@Gybb
Copy link

Gybb commented May 24, 2018

This is very interesting, what do change after a power recovery?
Is the buffer expanding?
Are the stepper voltages changing?

Will try this when I get home from work.
Cheers

@murphy2712
Copy link

I tried this morning 2 times and to my surprise, power recovery didn't trigger (no movement on power loss, and no special message on power on).
Is there a setting to enable it (I can't find one)? It was working previously so I must have changed something.

@stahlfabrik
Copy link
Contributor

You must pull the plug and not flick the switch

@Panayiotis-git
Copy link
Contributor

Panayiotis-git commented May 24, 2018

@stahlfabrik What is the difference?

Edit: I think that this is valid only if the power outage detector is placed before the switch.

@stahlfabrik
Copy link
Contributor

Well according to the manual it is by design that a willful switching off the power is not triggering power panic.

It is how it is designed. A good choice if you ask me.

@murphy2712
Copy link

murphy2712 commented May 24, 2018

Thanks! I only tried by using the power switch.
I didn't know about this being official.
Indeed at page 36 of the Handbook manual:

Power panic doesn't work if you interrupt the print with the on/off power switch.

@TheBrigandier
Copy link
Author

@Skywatchr I tried pause to no effect. Moire only disappears when I yank the plug.

@leefla
Copy link

leefla commented May 24, 2018

This is truly bizarre. Fantastically interesting but truly bizarre.
I'd count this as 100% proof that it's a software issue, but why the software is in a better state after a power recovery is ... bizarre.
I'm assuming (and this really is just an assumption, since I haven't looked at how power-recovery is implemented in code yet) that it's either because it's using stored calibration values rather than actually doing any calibration before the print, or perhaps there's some memory trashing or something going on during normal startup, in code that it skips over when doing power-recovery, or maybe because it's never run the normal menu code.
All pure speculation on my part, but I'll try to find time to take a look at the code (very busy with work at the moment, so might not get much time for this in next few days unfortunately).

Regardless, EXCELLENT find. This should definitely help track down the issue.

@TheBrigandier
Copy link
Author

Before you guys end up wearing out your power plugs/strips/rewiring things so the switch can do this:

image

It seems there's a DEBUG option in the firmware to trigger this via the menu. I saw this get posted in Discord late last night before I hopped in bed so not sure what it entails, but we probably want to test this out and see if it clears the effect as well. If it has the same effects we can abuse it until this gets worked out in the software, if a power plug pull is actually required then this issue just got 100x more interesting. :)

@leefla
Copy link

leefla commented May 24, 2018

@ff8jake That will actually be very informative, because simulating a power recovery will do whatever that tries to do normally, presumably without actually resetting the board, and without cleaning up fully after whatever it did before starting the print.
That will tell us whether it's something that it's doing as part of the power recovery that's fixing the issue, or whether it's something that it's skipping when doing the power recovery (but does before starting a print normally) that's causing the problem

@HeySideburns
Copy link

HeySideburns commented May 24, 2018

If that works we can just implement a gcode that triggers the power recovery debug option. Problem solved! 🔨 8)

@leefla
Copy link

leefla commented May 24, 2018

haha, hey buddy, 'sideburns' has a hammer for every problem :)
If the debug option really does work too (I suspect it might not, but I haven't had time to look at what the option does in code), then that might actually be a super-quick (temporary) hacky workaround. Call that func at the start of each print ;)

@ctilley83
Copy link

This method didn’t make a difference in my tests. Maybe because I’m running a MeanWell PSU?

@leefla
Copy link

leefla commented May 24, 2018

@ctilley83: pulling the power plug ? or using the debug option ?

@TheBrigandier
Copy link
Author

@ctilley83 this only affects the moire, not the fat line issue in #602. Try a print like a 50mm single wall cube (no infill). At the default 95% flow rate and 280 E steps, the moire is pretty sharply defined.

I am also using e-correct of 1.035.

@MTJC
Copy link

MTJC commented May 24, 2018

@HeySideburns ...as a temporary solution only you mean? lol.

@HeySideburns
Copy link

@MTJC Of course :)

@devilhunter84
Copy link

What values are gone after a power panic trip?

I suppose mesh bed leveling is gone, perhaps also pinda temperature adjustment, and...?

@alientek
Copy link

I see no difference after power panic in silent mode
img_20180524_175919 1

@stahlfabrik
Copy link
Contributor

Devilhunter, afaik the pinda temp thing is calculated into the mesh bed leveling values and are not used or saved after their use during building of the mesh bed leveling.

That said are you sure that power panic does not save the bed mesh/ mesh bed;-)

@devilhunter84
Copy link

After the panic trips, are you still connected to Pronterface? Then we could check.

@matthew-humphrey
Copy link

I bet it's the mesh leveling.

@bubnikv
Copy link
Collaborator

bubnikv commented May 25, 2018

I bet it's the mesh leveling.
The bed leveling is recovered after power up as well, otherwise you would see a scar on the print.

@DevDocX
Copy link

DevDocX commented May 25, 2018

I can add something interesting to the mix, but note that this I am still testing (currently). I found that firmware 3.1.1 - 143b(testing/debugging) had the opposite effect. I had no moire by default and then after power panic, moire appeared. I am working on a theory that my case may be that the default firmware (this version) has a flow rate of 95% and after power panic, it goes to 100%. So this may not be telling much, but it is interesting that it changes when power panic kicks in. It's at least one thing that can change. I will show pics when available.

@DevDocX
Copy link

DevDocX commented May 25, 2018

One thought I had is that once power panic is tripped, the starting code from the current file with all of the parameters is no longer present, such as relative settings, k values, etc. I would suspect that you are running the remaining code with the firmware defaults. I think there is some fruit here. We just need to find it. It would be awesome to solve this and the inconsistent extrusion many are plagued with.

@TheBrigandier
Copy link
Author

TheBrigandier commented May 25, 2018

example

This is a much better pic I got off a piece last night showing the effect. Bottom portion has sharp moire, top portion has none.

To further confuse the issue, it's only been a couple of us that have seen the power recovery affect things. I've done a lot of testing with Prusa experimental builds (like XYZ linearity correction), and it makes me wonder if power recovery is restoring a setting from eeprom that isn't normally getting applied in a normal startup. Maybe something I have hiding out in memory that most people don't.

That said, it may be interesting to find a way to dump eeprom in a readable way and diff it against someone who's not seeing an effect from the power cord yank?

@PavelSindler
Copy link
Contributor

Power panic doesn't store flow rate correctly. Gcode files for MK3 contains setting flow rate in start sequence. After power panic slightly different flow rate is used and that is why moire looks different. But moire can be more visible after power panic or less visible. It depends on printed object. We will fix storing flow rate in power panic asap. Thank you.

@TheBrigandier
Copy link
Author

@PavelSindler Go figure that the flow rate would change to the exact value to make moire disappear on the part I happen to test with. It's a little humiliating, but I am glad it exposed another issue that needs fixing. Thanks you guys for your work.

Will leave this open to be closed by the pull.

-Jake

@PavelSindler
Copy link
Contributor

It has been fixed in PR #790.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests