search

InsanityAutomation / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform.
http://www.marlinfw.org/
GNU General Public License v3.0
448 stars 220 forks source link

CR-10S Pro V2 - CrealityDWIN_7.3 Babystepping not working #193

Closed Ericvf closed 3 years ago

Ericvf commented 3 years ago

Description

Babystepping doesn't work. The value changes on the LCD and is saved. But the nozzle doesn't move. I need to make adjustments, stop the print, restart the print and only then it uses the new Z-offset. Configuration looks OK to me.

Steps to Reproduce

  1. Clone this repo from source
  2. Checkout the Creality_DWIN branch
  3. Configure BLTOUCH
  4. Flash
  5. Flash TM3D_SingleExtruderDwin_V3.7z to the LCD controller

Expected behavior:

Changing the Z-offset during print (babystepping) moves the nozzle

Actual behavior: [What actually happens]

Changing the Z-offset during print doesn't move the nozzle

20210408_CR-10sProV2.zip

Ericvf commented 3 years ago

https://user-images.githubusercontent.com/7957203/116441109-6ed1e980-a851-11eb-8c55-4ba9e4976538.mp4

InsanityAutomation commented 3 years ago

Slowing the print speed may delay application of babystepping. The steps are now added to the planner rather than immediate to avoid potential issues with TMC driver step pulse limitations with both babystepping and mesh bed leveling. Because of this, typically a few seconds of movement is needed before it applies, however with the speed so low im not sure exactly when it will actually move.

Ill run a few quick tests here this afternoon to confirm.

Ericvf commented 3 years ago

Allright. This problem is not due to slowing down the print. I'm only doing that in the video. My skirts are usually set at around 30mm/s so I wanted to make sure I could capture it.

InsanityAutomation commented 3 years ago

Ok, just taking a guess based on what I could see before testing again. From the leveling screen is definitely working, and they call the same code path with a different argument so it's possible it's something rounding it off somewhere... I'll find out shortly if I can reproduce it.

Ericvf commented 3 years ago

Thanks a lot for the help. And the quick responses. It does work fine in the levelling screen. I'm looking at the changes at Babystep.cpp but nothing significant there recently. I did find a similar issue from 23 feb 2020:

https://github.com/MarlinFirmware/Marlin/issues/16941

If there is anything I can do to help, let me know.

InsanityAutomation commented 3 years ago

Prepare a coffee funnel!! Lol there has been some other discussion on changing the fine adjustment from .01 over up to .025, I may do that while I'm in this area and if it is something being rounded down too far to hit zero that would also eliminate it right away.

Ericvf commented 3 years ago

Yeah that sounds good. I usually babystep in increments of 5 steps. However I do love doing those 1/10th precision steps to top it off. Hope it becomes a flag in the config somewhere.

InsanityAutomation commented 3 years ago

It is rounding down to below a full step so the planner is dropping them.. Fixed and will be pushed after a bit more testing.

Ericvf commented 3 years ago

Nice. So you have been able to reproduce it? Sounds like you already fixed it 👍 I'd be more than happy to get the commit and test it as soon as I can.

Let me know where I can find it. I'm using the CrealityDwin_2.0 branch.

InsanityAutomation commented 3 years ago

https://github.com/InsanityAutomation/Marlin/tree/CrealityDwin2.0_Bleeding Dev branch here is updated

Ericvf commented 3 years ago

Sorry for the delay, different time zone. Unfortunately it still doesn't seem to work. I've switched to the CrealityDwin2.0_Bleeding branch, pulled the changes and recompiled. The behavior is identical.

This branch is giving me even more issues. If I abort the print and restart the print, it will go to the Back Right corner after homing and just stay there. Powercycling the machine solves that.

InsanityAutomation commented 3 years ago

That's odd, nothing that major has changed.. I ran it on 2 machines here through successive prints. Is there any error messages on the terminal? Only thing I've seen cause it to just sit was a probe failure, with the bltouch flashing.

Ericvf commented 3 years ago

How do I inspect these messages on the terminal, via Serial Montitor? I've just flashed 7.2 from a month ago and baby stepping is working again.

Edit: additionally it might be interesting to know that this machine is completely stock. It was running the latest Creality firmware (1.1.9) without any issues. Babystepping was working for sure.

Ericvf commented 3 years ago

https://github.com/InsanityAutomation/Marlin/issues/194

Seems to describe the same issue. This one is flashed from prebuilt binary.

InsanityAutomation commented 3 years ago

Yes, serial monitor should do it

Ericvf commented 3 years ago

Allright. I'll see if that turns up anything. Please advice on how to proceed with the baby stepping. Not being able to dial in the first layer completely breaks this firmware version for me.

InsanityAutomation commented 3 years ago

I just made another attempt, followed you're process as best as I can understand : Start print from local display, wait halfway through first layer, abort print, back to file browser, start same print again. I built a hex file here to be sure 10SProV2_BIL_DW7.3.1.hex.zip

InsanityAutomation commented 3 years ago

Allright. I'll see if that turns up anything. Please advice on how to proceed with the baby stepping. Not being able to dial in the first layer completely breaks this firmware version for me.

Agreed, thats why I got a resolution in quickly last night. Right now though, it appears to be working on 2 machines here with that last push last night so if something isnt working right there, we need the serial logs to find out why.

Ericvf commented 3 years ago

Allright. So I am seeing an error when starting a print after I had aborted it.

Check it out:

//action:notification 20mmbox.gcode
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
X:177.00 Y:150.00 Z:12.78 E:120.19 Count X:14160 Y:12000 Z:4313
echo:Invalid mesh.
Error:Failed to enable Bed Leveling
echo:Bed Leveling OFF
echo:Fade Height OFF
X:177.00 Y:150.00 Z:12.78 E:0.00 Count X:14160 Y:12000 Z:4313
X:218.00 Y:310.00 Z:15.90 E:0.00 Count X:14160 Y:12000 Z:5141
X:218.00 Y:310.00 Z:17.90 E:0.00 Count X:14968 Y:16003 Z:6025
X:218.00 Y:310.00 Z:17.90 E:0.00 Count X:14969 Y:16013 Z:6025
echo:busy: processing
echo:busy: processing

I'm using the 7.3.1 hex file provided by you above

Ericvf commented 3 years ago

https://user-images.githubusercontent.com/7957203/116557950-3c7ec580-a8ff-11eb-9fa7-259ef2896dd2.mp4

This video demonstrates the problem of not being able to print after an abort.

I'm using the 7.3.1 hex file provided by you above

InsanityAutomation commented 3 years ago

It seems there is a call to enable mesh leveling, but there is no valid mesh stored to do so. Have you run leveling yet? If not, can take the M420V out of the gcode to avoid the error for the moment.

InsanityAutomation commented 3 years ago

Can you attach the gcode file?

Ericvf commented 3 years ago

Good point. I did not set that up. The fact that a powercycle does allow it to print the same file (with the same command) was throwing me off. I'm going to enable bed levelling and try again.

Ericvf commented 3 years ago

20mmbox.zip This is the GCode. Sliced with Cura 4.7.

InsanityAutomation commented 3 years ago

Also, did you attempt any z offset adjustment / babystepping while connected to the terminal?

Ericvf commented 3 years ago

Also, did you attempt any z offset adjustment / babystepping while connected to the terminal?

On it. I'm waiting for the bed levelling now and testing the M403 again. See if that no longer fails when having set up levelling. Then I will be able to test the baby stepping. Give me 15 mins

InsanityAutomation commented 3 years ago

Youre gcode causes my machine to exhibit the same.. lemme read it and see why

Ericvf commented 3 years ago

Thanks for the update. Just tested it with levelling setup. Same problem. No error in the Serial.

InsanityAutomation commented 3 years ago

Youre gcode contains G90 and G91 commands, it seems when it faulted it was left in relative mode. Changing back to absolute mode with G92 injected in youre starting code after G28 solved the issue in youre gcode.

Ericvf commented 3 years ago

Allright. Thanks. Is this problem introduced by this change? https://github.com/InsanityAutomation/Marlin/commit/6ff92f32157299bebe837abe893d2061f2aea206#diff-c7a3fa925098d81e51840820898b66e3d3e48f121a83e4d0b6c65e5ab4f2fba0

Perhaps it needs fixing there instead of my GCode.

Ericvf commented 3 years ago

Allright. Can confirm that baby stepping is indeed working again. I'm using the binary provided by you as opposed to building it with Arduino IDE nightly. Couldn't use PlatformIO due to another bug in configuration. I've resolved that and am now going to compile and flash from source (bleeding).

InsanityAutomation commented 3 years ago

Arduino IDE is not currently in use by any active Marlin developers so honestly we have no idea how that's going to work! Yes I did see that just a minute ago, made the change on my laptop and I'll push it as soon as it is off this VPN that locks me off the rest of the world... That will cause the finished button to force absolute mode, although it is best practice to have it in the start gcode to be safe as well. Every one of my files do and that's why the issue was hidden.

Ericvf commented 3 years ago

Allright. The custom build is also working. I'm not sure why I concluded something else this morning? Did I forget to clear the EEProm? Did I not test properly? Might Arduino IDE using another toolchain?

I'm going to assume I didn't test that properly this morning, hope you don't mind. So that solves baby stepping as well.

InsanityAutomation commented 3 years ago

No problem at all, truly appreciate anyone doing any form of testing and feedback! Going back and forth did fine one other thing to fix so still a win!

InsanityAutomation commented 3 years ago

By the way that gcode name lies! It is not 20mm lol

Ericvf commented 3 years ago

Please let me express my sincere gratitude on solving these issues with me. I've been using the TM3d firmware since 2019 now on 3 machines and even though I have had some issues setting them up, like today, they run beautifully.

You are doing gods work, hats of to you sir and thank you on behalf of all of us. | Greetings from a fellow software developer

Ericvf commented 3 years ago

By the way that gcode name lies! It is not 20mm lol

Haha. True you are. Not a very interesting print I know. Have a great day!