Marlin writes to SD card every layer regardless of PLR Pin defined

[blueeagle69]

Hi.

I could be mistaken, but Marlin appears to be writing to the SD card for Power Loss Recovery, even though I have a Mini UPS and a pin defined for loss detection.
I looked at the output of Pronterface during an SD card print, and this continuously shows in the output window.
echo:Unknown command: "0.9"
echo:Unknown command: "1.5"
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:Unknown command: "1.8"
echo:Unknown command: "2.1"
echo:Unknown command: "2.4"
echo:Unknown command: "2.7"
echo:Unknown command: "3"
echo:Unknown command: "3.3"
echo:Unknown command: "3.6"
My layer height is was at .3, so it does appear to be that.
I then commented out
//#define POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data
and it still appears to be writing layer info.
My lower loss detect is working fine, with this line disabled but I was under the impression that Marlin only wrote to the PLR file when a power outage is detected, when a power loss module was installed with a pin defined?

Thanks.
Config.zip

[ellensp]

"CONFIGURATION_H_VERSION 020005" in provided configuration files.

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[GMagician]

Not sure but power loss input isn't used to signal a power fail? AFAIK Marlin will save data continuosly because when powerfail occurs it has no time to write to SD....and ups is not always present

[ellensp]

"#define POWER_LOSS_PIN 44 // Pin to detect power loss. Set to -1 to disable default pin on boards without module."

[GMagician]

That's ok then, pin is to signal a power loss, not an ups presence. So Marlin needs to write info continuosly to be sure it has updated info when a power loss is detected

[ellensp]

no, that is how is is meant to work if you don't have a pin. If you have a pin it is only meant to write when triggered..
And this always writing has been seen before and I believe fixed in bugfix, which is why they need to test current bugfix.

[GMagician]

Ah ok, my fault in thinking how it works!

[thierryzoller]

Nice way to spend your limited write cycles on an SD Card.

[sjasonsmith]

Labeling as needs more data, until @blueeagle69 reports back results when testing with bugfix-2.0.x.

[blueeagle69]

Cheers guys, I will give bugfix a try and test.

[blueeagle69]

Okay, I am on the latest bugfix.
Same configuration, I also still have that #define _POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data disabled, but Marlin still appears to be writing to the SD card on every layer regardless.

Just to add.
I disabled Power Loss Recovery, and ran another test print, and looked at the log output in Pronterface.
I'm still seeing;
echo:Unknown command: "0.54655"
echo:Unknown command: "0.84655"
echo:Unknown command: "1.14655"
echo:Unknown command: "1.44655"
echo:Unknown command: "1.74111"
echo:Unknown command: "2.0033"
echo:Unknown command: "2.26387"
echo:Unknown command: "2.54783"
on every layer change etc.
So I'm stumped.
It's definitely outputting layer information of some sort.
It's whether or not this is being written to the SD card.

[thierryzoller]

Your GCODE may have particular commands at a certain layerheight, can you check ?

[sjasonsmith]

@blueeagle69 can you upload your updated configurations that compile with bugfix-2.0.x?
Also, it would be nice to upload a g-code file that causes those errors to be printed. The smaller the better.

When I look at the bugfix code, it seems like it should not save on ever layer if you have a pin defined, but several G-Code commands can trigger it.

[sjasonsmith]

@blueeagle69, after fixing another recovery issue I tested this. I am not seeing it write to the file on every layer.

If you add the following line to your configuration file you can enable some prints from the power-loss code.
#define DEBUG_POWER_LOSS_RECOVERY

Without POWER_LOSS_PIN, you see a print like this at every layer change:

Write Job Recovery Info...
valid_head:1 valid_foot:1
current_position: 120.25,117.93,3.50,123.24
home_offset: 0.00,0.00,0.00
position_shift: 0.00,0.00,0.00
feedrate: 906
target_temperature: 197
target_temperature_bed: 60
fan_speed: 173,0
leveling: 1
 fade: 0
sd_filename: /WOLF~1.GCO
sdpos: 43298
print_job_elapsed: 216

When I add a POWER_LOSS_PIN I only see this when the pin is triggered.

So, I don't think your errors messages indicate anything wrong with power-loss recovery.
We can leave this open for a day or so. If you upload a gcode file along with the errors, perhaps we can identify what might be causing the errors.

[blueeagle69]

I will do that.
However, I now feel like a total idiot.
After seeing a reply, I delved into my Prusaslicer Gcode a bit closer, and found two entries;
{Before Layer Change}
;{if layer_num == 1}M220 s20
;{elsif layer_num ==77}M220 s100
;{endif}

{After Layer Change}
;{if layer_num == 1}M220 s20
;{elsif layer_num ==77}M220 s100
;{endif}

I removed both just for the hell of it, and so far, no weird outputs in the terminal during printing.
I still have that line disabled in Marlin;
//#define POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data
I also killed power during the print, my UPS/power detect module kicked in and raised Z, and the print resumed as normal. I then noticed a "Writing to file //PLR" in my terminal as expected.
So it looks like one of my slicer lines of code was causing it.

I plan to whip myself profusely.
Apologies to all, I will close this 🙄

[thierryzoller]

I'll add this to my pile of "I was right" ;)

[blueeagle69]

:)

On Mon, 6 Jul 2020, 20:18 Zoller Thierry, [e-mail] wrote:

I'll add this to my pile of "I was right" ;)

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/18518#issuecomment-654418727,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMASZCZBJDUYWWQNNIVPKLR2IPP5ANCNFSM4OPLPIGQ
.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.