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.
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.
@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.
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.
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.)
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.