This should be fixed now. Please retest with 18.104.22.168
Confirmed that gcode files on SD are presenting in LCD in order by most recently saved gcode file.
Tested on Mini2 and Taz6 using Marlin 22.214.171.124
A few thoughts on using SD cards for power save. I recently learned that SD cards may or may not have wear leveling (entirely up to the vendor), and that if the card has wear leveling, a power loss event may cause corruption outside of the location which was most recently written (see this thread: https://electronics.stackexchange.com/questions/27619/is-it-true-that-a-sd-mmc-card-does-wear-levelling-with-its-own-controller)
Tested pausing/resuming prints using Marlin 126.96.36.199 with Cura LE 3.2.21 & 3.2.24
TAZ 6 v3 dual - layer shift reproduced
Mini 2 Standard Extruder - No layer shift
TAZ 6 Standard Extruder - No layer shift
Mini Single Extruder - No layer shift
Mon, Aug 13
I was only able to replicate this original issue with the Mini2 printer using m.188.8.131.52. Have not been able to replicate it with any of the Taz6 printers or a Mini with the LCD attached.
Tried again on Mini2 using m.184.108.40.206 and received home xyz message after moving axis, then message went away after Home ALL.
Fri, Aug 10
2.0 bugfix Gladiola single extruder. After turning off power and resuming print, it attempts to go through the G29 process again when resuming.
Marlin 2.0 bugfix from 8/10/18 does not recognize the Button Switch on TAZ when first going through the probing sequence
@b-morgan Ahh great to hear, the 1.1.8 branch is what we currently have loaded into Cura LE as stable. Glad to hear it is working!
I did not do the same experiment with 1.1.8 but I have been using the released versions of the firmware without incident. Is there something specific about 1.1.9 you would like tested?
Please test on 1.1.9 marlin, and see if the most recent saved Gcode file appears at the top of the list
@Yahuba please test if a layer shift happens when pausing in 1.1.9.x (most recent)
@Yahuba please test on the latest 1.1.9 branch of Marlin
@logan: True. I guess we haven't really ruled out that the motors were off. One other possibility is that the brake board is shorting out the windings on the motors when it should not.
if the compression bushings were usable we'd be able to eliminate that drop. But we cant prevent the axis from falling under its own weight without making print quality issues so the compression bushings are typically left loose
@marcio that doesn't apply if the motor drivers are off and the machine is on, though. Power on a machine and disable steppers, the side with more weight (left) will fall
@logan: Well, electrically the motors are inlined in series at the brake board. So your should not see one side droop and not the other, unless the pully or belts are slipping.
@marcio to have the left side drop like that after a slight delay? doesn't sound likely to me, if the pulley were loose it likely wouldn't be visually level as the customer describes as it returns to the top
@logan: Sounds like that user may have a loose pulley.
Still cannot recreate this customer's issue entirely: https://forum.lulzbot.com/viewtopic.php?f=43&t=7717
After fresh flash of 220.127.116.11 if I level the X-axis after the motors have turned off, they remain engaged after the leveling is complete
@marcio So far I have only been able to recreate on a fresh FW flash of 1.1.9.xx on the first connection. If the machine is powered off and then reconnected the issue doesn't recur and I cannot recreate on 1.1.8.xx
@logan: That's weird. Still can't reproduce on my machine. Can you try M500/M502?
@marcio Here is the M122 output from that occurrence:
@marcio I managed to recreate this by doing the following:
@logan: I uploaded FW 18.104.22.168, which adds the M122 command, which allows you to check the state of the drivers. Please confirm that the Z drivers are being turned off and if so, call me over to take a look.
@logan: I am unable to reproduce this. Are you sure the Z motors are being disabled?
The configuration options to suppress the deactivation are still in place, so this may point to a regression in the Marlin code itself. There are three situations in which Marlin turns off the steppers and we need to find out which of these situations applied:
Thu, Aug 9
For that we would probably need to add our own GCODE command, or add an argument to G38.3
@marcio Would there be a way to pull the set marlin offset using gcode commands? We have a lot of customers tweak their offset and store to eeprom
Actually, it looks like the correct thing to do would be to use G38.3, followed by G92 to reset the Z height.
It might be possible to substitue the G29 with a single Z probe: http://marlinfw.org/docs/gcode/G030.html
However, my guess is that your Z-offset would be wrong if you actually tried to print. I think you need something a bit more accurate than a Z-max endstop to actually take advantage of not having to have G29
Yes. It is active. If you do a G29, followed by a M500, then that bed leveling matrix will be present the next time you power up.
@marcio Is this activated? What do we need to do to implement on our machines with G29?
This feature already exists in Marlin 1.1.9, possibly in earlier versions as well.
This issue is fixed in 22.214.171.124
Tue, Aug 7
Single Extruder. M119 reports:
Mon, Aug 6
@keebie81 We have an initial build of Marlin 1.1.9 with our changes merged in. We have more testing to do (and likely bugs/tweaks to fix), but after ~ 12 prints I feel comfortable that it won't be damaging any of your hardware. If you would like to give it a test, the latest builds can be found here: http://devel.lulzbot.com/software/Marlin/