My "2 Wifi" is un-baby-stepping

gnydick

@phaedrux Yeah, they're getting hot. They're undergeared, 20 teeth on the motor, 60 teeth on the lead screw.

aidar

If you are using Za and Zb for motors, than they are wired in series, that means you must NOT double current. Double current is needed when motors are wired in parallel.

deckingman

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

............... I've tried pretty much every different microstepping setting...............

That must have been a pain because the way you have things configured, each time you change the micro stepping, you have to re-calculate and enter the the steps per mm for that micro stepping. So here is a little tip. Set the steps per mm for 16X in M92 but put that line before the M350 micro stepping line. Then you can change the micro-stepping in M350 and the firmware will automatically re-calculate the steps per mm.

As others have said, if you set micro-stepping too high, especially with the gearing you have, then you'll run the risk of hitting the step pulse frequency limit which is about 200KHz. So I'd suggest you start with 16X with interpolation which should be fine.

wilriker

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

@phaedrux Yeah, they're getting hot.

Depending on how long you have already run them at 171% of their rated current (1.4A according to the linked datasheet and 2.4A maximum current that the drivers on the Duet will put out - even if you command higher values) they might already have gotten to a temperature where their internal magnets have suffered and thus even further reducing their torque. So I would not count on them still being able to provide 13N.cm of torque anyway.

gnydick

@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?

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?