My "2 Wifi" is un-baby-stepping

gnydick

@phaedrux I switched my extruder to x16 + 256 interp, and now the surface of my prints are pretty poor. They're rippled along the entirety of the path, not just beginning or end.

deckingman

@gnydick said in My "2 Wifi" is un-baby-stepping:

@deckingman

OOOOOOHhhhhhh. That's a great tip for ordering the commands. Yes, it was a pain, because even though it was powers of 2, it never worked out exactly and I had to measure every time. Luckily, I have a spreadsheet where I just plug in the settings and the measurement and it tells me the new setting to put in to fix it.

But, there seems to be a chicken and egg problem. Are you saying that the default is 16x and that's what I'm measuring if I were to not even specify microstepping?

To save me typing - check this out - https://duet3d.dozuki.com/Wiki/GCode#Section_M350_Set_microstepping_mode

Phaedrux

@gnydick said in My "2 Wifi" is un-baby-stepping:

@phaedrux I switched my extruder to x16 + 256 interp, and now the surface of my prints are pretty poor. They're rippled along the entirety of the path, not just beginning or end.

With your other axis at x16 you have open budget to increase the extruder micro steps. It's recommended to get your extruder steps per mm value in the 400 to 1000 range. Try x64 microsteps.

You can use this tool to determine what your max retraction speed with your microstep settings can be before getting skipped steps.

https://wilriker.github.io/microstep-calculator/

gnydick

@phaedrux gotcha. Thanks!

gnydick

So, it's still happening. It looks as though rapid baby-stepping is undone, but slow, infrequent baby-stepping isn't

dc42

Can you provide a GCode file and a sequence of steps to reproduce this?

gnydick

@dc42 sure, I'll get it to you today.

gnydick

0_1550902843214_Ghosting Test Makers Muse (1).gcode

To reproduce, just rapidly enter baby-steps. Say, 4 clicks, and what the z motors.

dc42

I'm sorry, I can't reproduce this. The only negative Z movements I see are the one at the start where you wipe the nozzle, and the ones that undo Z-hop in the GCode around travel moves.

Tested using the 2.03beta2+1 release.

gnydick

@dc42 can you print with the latest stable release instead of the latest dev version? Do you want me to upload my entire sys folder so you can try it?

dc42

Can you try with the 2.03beta2 release?

gnydick

@dc42 I'm not going to put anything but stable releases on. I have too many prints to go out to worry about new bugs.

gnydick

I'm really having a hard time getting any prints done. I really need a solution. Also, I don't know if it happens this way always, but I noticed it "un-babysteps" during a travel.

dc42

I'm sorry, it it's fixed in the current beta then as far as I am concerned, it is fixed. I don't have time to investigate possible problems in multiple firmware versions when just one user is affected. There were major changes to the babystepping code in 2.03 as a result of other changes, which resulted in the babystepping code being significantly simplified. So it wouldn't be just a case of back-porting a bug fix.

I have had only one bug reported in 2.03beta2, which is that if you use the M575 "Probe Tool" command then custom endstop numbers don't work. You can see the feedback from users in the 2.03beta2 thread.

gnydick

@dc42 so you're saying you did confirm the issue? Or, are you saying that you can't reproduce it in the 2.03beta2?

dc42

@gnydick said in My "2 Wifi" is un-baby-stepping:

@dc42 so you're saying you did confirm the issue? Or, are you saying that you can't reproduce it in the 2.03beta2?

I'm saying that I can't reproduce it in 2.03beta, also that there have been code changes made that could mean that 2.03beta behaves differently form 2.02.

gnydick

@dc42 well I tried the latest beta, it's still happening. Is there any debug mode I can do for you? Maybe hooked up to the serial terminal?

Phaedrux

Were you able to figure out of your motors were cooked? Did you try any of the other suggestions above?

dc42

@gnydick said in My "2 Wifi" is un-baby-stepping:

@dc42 well I tried the latest beta, it's still happening. Is there any debug mode I can do for you? Maybe hooked up to the serial terminal?

That's odd, I took your config.g file, made minimal changes to allow it to work on my bench system, and i was unable to reproduce the problem.

Does the un-babystepping fail only in one direction; for example, if your machine has a lifting bed, does baby stepping to low the bed always succeed and lifting it sometimes fail?

gnydick

@dc42 IIRC, it fails in both directions. Sometimes it's a slow winding back to where it was, other times it's the complete sum of baby steps e.g. if I click it 5 times and it moves .05 x 5times, then it will undo it .25 all at once.