scyto
January 5, 2022, 9:13pm
1
I have A350, i upgraded the rails and head, firmwares auto updated, i noted that the numbers in M501 were different, assumed that was right because of upgraded rails and head.
I have been having odd printing issues (severe under extrusion on first layer) and i am struggling to know what changed because i have replace rails, head, hotend, filament batch, updated all my slicers, etc) so trying to go back a little.
I have put the old head back on, i reset from touchscreen and reset using M502. I am confused by output of M502 because its seems to have reverted to the old rails settings…
Before resetting with M502
Recv: echo:Steps per unit:
Recv: echo: M92 X160.00 Y160.00 Z400.00 B888.89 E228.18
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X300.00 Y300.00 Z12.00 E120.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X1000.00 Y1000.00 Z1000.00 E1000.00
after resetting with M502
Recv: echo:Steps per unit:
Recv: echo: M92 X400.00 Y400.00 Z400.00 B888.89 E212.21
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X120.00 Y120.00 Z40.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000.00 Y3000.00 Z100.00 E10000.00
(i expected E212.21 as thats what a factory reset always did)
the other numbers are confusing me… my suspicion is M502 just did the wrong thing…
–edit–
could someone with upgraded rails see what their setting are as i no longer trust the ‘upgraded’ settings
scyto
January 5, 2022, 9:16pm
2
i am reapplying firmware in hope this fixes
scyto
January 5, 2022, 9:19pm
3
no it doesn’t and the huge clonk noise from X and Y during a home is very concerning
FFS snapmaker get it together, your QC and testing just stinks
i opened a guthub issue for you snapmaker, i expect to see this resolved ASAP
Executing M502 on upgraded A350 sets wrong settings, risks damaging new v2 linear rails. · Issue #201 · Snapmaker/Snapmaker2-Controller (github.com)
What looks like is supposed to happen is this flag gets reset:
/**
* M502 - Reset Configuration
*/
void MarlinSettings::reset() {
static const float tmp1[] PROGMEM = DEFAULT_AXIS_STEPS_PER_UNIT, tmp2[] PROGMEM = DEFAULT_MAX_FEEDRATE;
static const uint32_t tmp3[] PROGMEM = DEFAULT_MAX_ACCELERATION;
uint8_t temp_axis_to_port[X_TO_E] = DEFAULT_AXIS_TO_PORT;
LOOP_X_TO_EN(i) {
axis_to_port[i] = temp_axis_to_port[i];
}
planner.is_user_set_lead = false;
LOOP_X_TO_EN(i) {
planner.settings.axis_steps_per_mm[i] = pgm_read_float(&tmp1[ALIM(i, tmp1)]);
planner.settings.max_feedrate_mm_s[i] = pgm_read_float(&tmp2[ALIM(i, tmp2)]);
planner.settings.max_acceleration_mm_per_s2[i] = pgm_read_dword(&tmp3[ALIM(i, tmp3)]);
}
planner.settings.min_segment_time_us = DEFAULT_MINSEGMENTTIME;
planner.settings.acceleration = DEFAULT_ACCELERATION;
planner.settings.retract_acceleration = DEFAULT_RETRACT_ACCELERATION;
planner.settings.travel_acceleration = DEFAULT_TRAVEL_ACCELERATION;
And then on next power on the steps/mm is set based on what’s read from the linear module:
if ((mac_index_[LINEAR_AXIS_Y1] != 0xff) || (mac_index_[LINEAR_AXIS_Y2] != 0xff)) {
axis_steps_per_unit[Y_AXIS] = mac_index_[LINEAR_AXIS_Y1] != 0xff ? lead_[LINEAR_AXIS_Y1] : lead_[LINEAR_AXIS_Y2];
}
if ((mac_index_[LINEAR_AXIS_Z1] != 0xff) || (mac_index_[LINEAR_AXIS_Z2] != 0xff) || (mac_index_[LINEAR_AXIS_Z3] != 0xff)) {
axis_steps_per_unit[Z_AXIS] = mac_index_[LINEAR_AXIS_Z1] != 0xff ? lead_[LINEAR_AXIS_Z1] : mac_index_[LINEAR_AXIS_Z2] != 0xff ? lead_[LINEAR_AXIS_Z2] : lead_[LINEAR_AXIS_Z3];
}
LOOP_XYZ(i) {
if (!planner.is_user_set_lead) {
planner.settings.axis_steps_per_mm[i] = axis_steps_per_unit[i];
}
SERIAL_ECHOLNPAIR("axis index:", i, " pitch:", planner.settings.axis_steps_per_mm[i]);
}
planner.refresh_positioning();
// check if all linear modules are the same generation
for (i = LINEAR_AXIS_X1; i < LINEAR_AXIS_MAX; i++) {
if (mac_index_[i] == 0xff) continue;
It requires a power cycle - did you try that by chance?
If that works you might clarify in your github issue that maybe M502 should force a reboot afterwards, or otherwise read the values from the linear module again.
Just found another edge case they missed:
The is_user_set_lead flag is set for any axis, including the E axis.
It’s possible that someone calibrates e-steps, then upgrades to the new linear modules - that will not be correctly handled also leading to this problem.
1 Like
scyto
January 5, 2022, 10:44pm
6
I think it did that when i tried to fix reapplying the the firmware?
Try M502, then M500 to save, then power cycle? M502 used to immediately write to EEPROM but I’m not seeing that at the moment.
scyto
January 6, 2022, 12:13am
8
This is indeed correct.
Doing this, then hard power reboot, M503 then reports right settings.
2 Likes