Steppers moving at different rates

bugilt · October 25, 2020, 8:58pm

It’s the Archim 1.0a board. I tried to find a setting that might have been configured improperly. I’m no expert on Marlin though.

bugilt · October 26, 2020, 6:20pm

I guess I’m getting an Archim 2 and turning this board into a single stepper per a axis controller.

jeffeb3 · October 26, 2020, 9:11pm

The archim 2 won’t help. Can you share some pictures of how you have it wired? Maybe a video too showing how it is moving? It’s very odd.

We just worked this out about 2 weeks ago and Ryan was testing firmwares with an archim, and they aren’t magic, so I don’t know how it would fail in this way. Maybe some photos and a video will show me something I wasn’t expecting (or one of the other smart people here).

bugilt · October 26, 2020, 10:40pm

Yeah, I’ve never seen a failure of electronics in this manner. It seems to be something else. I’m not sure where to look. I appreciate you taking the time. I’ll get some video and pictures uploaded later tonight.

update: had a few things come up. I’ll try to get the pics and video later today.

bugilt · October 28, 2020, 2:25am

I loaded on a slightly older version and got a lot more noise and a lot less movement. I switched back to the newest version and took the video and images.

jeffeb3 · October 28, 2020, 2:45am

How weird.

@mattinglot and Ryan and I were working on this a little while ago, and I thought we had all the fixes into v506:

I just started a build on v507. That should be up soon. It shouldn’t be more than a day’s difference, but it would be great to know if this version is still doing it.

There is another archim user (@mperino) with suspiciously similar issues: Tuning Drive Strength and Steps per MM on Archim 1 for V506

And I know @vicious1 has one. We worked pretty hard to get the last one up and running. It is disappointing this one isn’t just working.

jeffeb3 · October 28, 2020, 2:47am

It’s also very clear from the video that the fast motors are wrong. Are those plugged into X and Y or E0 and E1? I wonder if we are missing a microstep setting on the extra motors.

jeffeb3 · October 28, 2020, 2:52am

It looks like we are setting “MICROSTEP_MODES” to 32,32,32,32,32,32. That might be looking at a bit closer (should it be 6? Is 6 enough? Does the X2, Y2 get set with those?).

Oh, This is set in the EEPROM…

Can you send M350 and see what that prints?

vicious1 · October 28, 2020, 2:53am

let me see if any changes were made to marlin after the fix.

Shoot there have been a few digipot changes. Probably need to test this on tomorrows build and release 208…

bugilt · October 28, 2020, 3:25am

X and E1 are the ones moving more than they should.

jeffeb3 · October 28, 2020, 4:07am

Those don’t seem important to me.

Here is my theory. That microstepping setting might be saved to eeprom. For some reason, it has junk in Dave’s eeprom. I’d like to confirm that with an M350. But an M502 should fix it.

Dave, do you have a computer you can connect with repetier host or cncjs or something?

bugilt · October 28, 2020, 4:19am

It’s still doing the same thing after the command.

Send: M350
Recv: MS1|2|3 Pins X:000 Y:001 Z:000 E0:111 E1:000

Send: M502
Recv: echo:Hardcoded Default Settings Loaded

bugilt · October 28, 2020, 4:33am

Anyone have a link to an 1.9 version of marlin that is dual endstop archim I could try and see if it’s the software. I’d hate to be wasting your time if the endstop shorting has something to do with it.

jeffeb3 · October 28, 2020, 11:14am

I think this is good news. Does Z also go very fast?

I think this should set them to 32nd microstepping:

M350 S32

That won’t be persistent. You need to also send M500 to save it.

M502 is supposed to read the default settings from the firmware. It doesn’t save it either.

So, try this:

Send M350 S32.
Send M350 again to show me what it says.
Try jogging 0.1mm on all axis.
If that works, send M500 to save.

bugilt · October 28, 2020, 4:37pm

Yes, Z also moves fast.

Send: M350 S32
Recv: Error:Microsteps unavailable
Changing monitoring state from “Operational” to “Error: Microsteps unavailable”
Send: M112
Send: N2 M11235
Send: N3 M104 T0 S034
Changing monitoring state from “Error: Microsteps unavailable” to “Offline (Error: Microsteps unavailable)”
Connection closed, closing down monitor

jeffeb3 · October 28, 2020, 4:40pm

Weird. What about M350 S16?

Or maybe M351? That looks much more annoying to use.

bugilt · October 28, 2020, 4:44pm

Send: M350 S16
Recv: MS1|2|3 Pins X:110 Y:110 Z:110 E0:110 E1:110

jeffeb3 · October 28, 2020, 4:46pm

Interesting.

Your steps/mm will be wrong, but that should work. Have you tested a movement?

bugilt · October 28, 2020, 4:46pm

I’ll do that now.

jeffeb3 · October 28, 2020, 4:47pm

I think the last bit might be able to be set with:

M351 S3 X1 Y1 Z1 E1 B1

The code for M351 (as future reference for me or anyone curious):

github.com

MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/gcode/control/M350_M351.cpp#L56


void GcodeSuite::M351() {
  if (parser.seenval('S')) switch (parser.value_byte()) {
    case 1:
      LOOP_XYZE(i) if (parser.seenval(axis_codes[i])) stepper.microstep_ms(i, parser.value_byte(), -1, -1);
      if (parser.seenval('B')) stepper.microstep_ms(4, parser.value_byte(), -1, -1);
      break;
    case 2:
      LOOP_XYZE(i) if (parser.seenval(axis_codes[i])) stepper.microstep_ms(i, -1, parser.value_byte(), -1);
      if (parser.seenval('B')) stepper.microstep_ms(4, -1, parser.value_byte(), -1);
      break;
    case 3:
      LOOP_XYZE(i) if (parser.seenval(axis_codes[i])) stepper.microstep_ms(i, -1, -1, parser.value_byte());
      if (parser.seenval('B')) stepper.microstep_ms(4, -1, -1, parser.value_byte());
      break;
  }
  stepper.microstep_readings();
}

#endif // HAS_MICROSTEPS