Archim 1 issues after software update

Hello everyone.

After about a year, I now decided to update the firmware on my Archim 1, as I had some issues with homing ( I would get a “homing error” and I would need to restart to board and re-initiate the homing) and once during a cut, the LCD just blacked-out after a few minutes, and the cutting stopped…

Please correct me if I am doing something wrong in the following steps.

So I downloaded PlatformIO, followed the indicated steps, flashed, turned on the Archim - the new software number appears on the LCD ( v508 2.0.7.2) - so far so good.

The issue I have is that once I try to move the axis manually (through the LCD), the movements are extremely rough an non-symmetrical, and on the X or Y axis, only one stepper is moving…
I saw in the comments on v508 that there are some micro stepping issued on the Archim 1, so I downloaded v507, and have exactly the same issue.

Each time I downloaded the " V1CNC_Archim1_Dual-…) as I have dual end stops and an LCD.

Would anyone have an idea how this can be fixed?

Thank you very much.

There seem to be some eeprom settings that aren’t getting reset.

Can you check with gcode the microstepping settings? They should all be 16.

Yes, I can try. Do you eventually have a quick manual on how to do it? :slight_smile:

Thanks a lot.

This is the other user that dealt with this. If you post what M350 says, we can see if it is the same problem and work out a command to fix it.

1 Like

Si when I type M350, I get the following: MS1|2|3 Pins X:000 Y:001 Z:000 E0:111 E1:000

Does not seem right? I am on v507 currently

Yeah. That seems bonkers. I don’t think the firmware version matters, except that it is not clearing the eeprom properly.

M351 S1 X1 Y1 Z1 E1 B1
M351 S2 X1 Y1 Z1 E1 B1
M351 S3 X1 Y1 Z1 E1 B1
M500

That should set all the bits.

2 Likes

Great thanks! It works, but only until I shut the board off. Once I start it again, I have the same issue.

Is there any way I can save this permanently on be board?

Sorry I am not very knowledgeable in coding… I’m more into cutting stuff :slight_smile:

Hmm. That’s not cool. The M500 should save it, but that is clearly the issue that caused it to be broken in the first place.

You can play some games to work around it. You can put all that in a gcode file and run that right away. If you have a server like octoprint attached, I think you can define gcode to send on connect. If you have an sd card attached, I think there is one special filename, like autostart.gcode that will be played as soom as the machine is powered on and sees the sdcard.

1 Like

@vicious1, this is the second report of this. I think it might be an easy fix in Marlin. Maybe we should just post an issue?

From what I can tell, flashing with an older version and then a newer version (2.0.7.2+). The settings for microstepping are wrong. Even though we set them in the firmware and the M502 didn’t fix it. Now, it looks like it isn’t being saved/restored properly from M500 either. This must just be an eeprom read/write issue.

I had marked this thread to follow as well as the other couple. I have no idea how to approach this problem but I believe I have a board here to test with. I guess Marlin would be the best place to start.

Thanks, I will research this. I’m usually using an SD Card, so I will try the have the gcode automatically played at startup, until there is a permanent fix.

Thanks again for your support!

It just crossed my mind, but do you think that it might help if I flash the Archim through the Arduino app instead of PlatformIO?

Yeah. I think that might help. I think that is what Ryan was using.

This was on a different board, but I have had issues with odd behavior driven by eeprom values when flashing to a new version of the same Marlin firmware. New settings didn’t seem to “stick” and it was very frustrating to work through. Running an M502 to reset the eeprom to “factory defaults” (actually the values entered in the config.h and config-adv.h text files prior to compilation) resolved all the odd behaviors I was experiencing.

You might want to dump all your eeprom values to a text listing with M503, then revert to factory defaults with M502, change the settings that need adjustments (by comparing current to the 503 list) and the save them fresh with M500.

The Marlin online documentation lists an M504 to validate eeprom contents, but I can’t tell exactly what that does.

1 Like

In my experience, Marlin is pretty good about noticing a change in version and clearing the eeprom if you flash a new version, but it can’t if you just change the settings in conf.h on the same version. YMMV

when I type M350, I get the following: MS1|2|3 Pins X:000 Y:001 Z:000 E0:111 E1:000

I had the identical problem and M350 response. “Brand new” Archim 1.0a (bought last spring, had v418 installed on it. I flashed it to v507 using Arduino 1.8.13.)

M503 dumps

>>> M503
SENDING:M503
echo:  G21    ; Units in mm (mm)
echo:  M149 C ; Units in Celsius
echo:; Filament settings: Disabled
echo:  M200 S0 D1.75
echo:; Steps per unit:
echo: M92 X200.00 Y200.00 Z800.00 E200.00
echo:; Maximum feedrates (units/s):
echo:  M203 X50.00 Y50.00 Z15.00 E25.00
echo:; Maximum Acceleration (units/s2):
echo:  M201 X180.00 Y180.00 Z80.00 E180.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P180.00 R3000.00 T180.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 B20000.00 S0.00 T0.00 X3.50 Y3.50 Z0.30 E5.00
echo:; Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:; Material heatup parameters:
echo:  M145 S0 H180 F0
echo:  M145 S1 H240 F0
echo:; PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:; Stepper motor currents:
echo:  M907 X1125 Z1125 E1125

Resetting with M502 and then rerunning M503

>>> M503
SENDING:M503
echo:  G21    ; Units in mm (mm)
echo:  M149 C ; Units in Celsius
echo:; Filament settings: Disabled
echo:  M200 S0 D1.75
echo:; Steps per unit:
echo: M92 X200.00 Y200.00 Z800.00 E200.00
echo:; Maximum feedrates (units/s):
echo:  M203 X50.00 Y50.00 Z15.00 E25.00
echo:; Maximum Acceleration (units/s2):
echo:  M201 X180.00 Y180.00 Z80.00 E180.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P180.00 R3000.00 T180.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 B20000.00 S0.00 T0.00 X3.50 Y3.50 Z0.30 E5.00
echo:; Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:; Material heatup parameters:
echo:  M145 S0 H180 F0
echo:  M145 S1 H240 F0
echo:; PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:; Stepper motor currents:
echo:  M907 X1125 Z1125 E1125

which is identical to before the reset. So M502 did not affect the results from M350.

Following @jeffeb3’s excellent instructions:

M351 S1 X1 Y1 Z1 E1 B1
M351 S2 X1 Y1 Z1 E1 B1
M351 S3 X1 Y1 Z1 E1 B1
M500

and then M350

>>> M350
SENDING:M350
MS1|2|3 Pins X:111 Y:111 Z:111 E0:111 E1:111

After this, I can confirm that the motors function correctly. Thanks!

However, I can also confirm that the settings are lost after a reboot. That’s more problematic because it requires workarounds which will be somewhat opaque and difficult to track 5 or 10 years down the road.

What happens with the current version v510? I swear we fixed this. There was just a missing comment.

Yes, I see now it was fixed after 507. The github issue is now closed out.

For 507, the process detailed in https://github.com/V1EngineeringInc/MarlinBuilder/issues/44#issuecomment-809606234 will enable a (semi)permanent workaround.