What do they actually do at the moment when you move? Vibrate or make sounds? As I said changing microsteps does not change much except you might have wrong distances due to wrong steps per mm or stall if it will now move too fast, but increasing is rather too slow.
What happens if you set microsteps back to old settings? In case driver just does not work with that combination you used as that is when it started to fail.
The old settings doesn't seem to work either. At the moment while in the MKS GEN, they do nothing. When I send commands, they do lock up for while but then they stop. I sensing micro-stepping isn't the reason. So I suspected the drivers.
I tested the stepper drivers individually and they work fine but for some reason they dont move backward. I dont know if that could be the issue.
So to elaborate, I connected the drivers to an Arduino got some online code, and build a schematic. As I said the steppers motors move but when programmed to move in the opposite direction they just make a beeping sound. So the change the direction to set the dir pin to either high or low. In my case with the dir pin is low, the steppers move but when they are high, I just get a beeping noise.
This is the circuit I followed, I used a 220uF capacitor instead.
Is this for all motor drivers or only just one? With test script and loose motor I see no reason to stall in one direction. If motor is mounted somewhere the force required for back direction might be different. The high pitch sound comes from motor I guess and that happens when motor is loosing steps. Easy to produce when you start with a too high speed. Then it stalle directly and only beeps until steps stop.
I did this for all motor drivers to check if I destroyed them at some point. Reset and sleep were connected to each other. I left enable disconnected. I 'll try what you recommended and see if there is a difference.
Watchdog does nothing to your firmware. Only if the watchdog is not triggered it will reset firmware. So if you are not seeing resets that is not the cause.
I also find that on the screen the value that indicates how many mm the axis has moved flickers between the number and question marks. Could this be siginificant? This didnt occur in the original firmware.
OK just realized the question marks are from not homing. And as you said disabling watchdog didnt do anything either.
I checked the enable signal and it reads 0.05v which is basically GND and that's what it should be.
Stepper drivers aren't dead, stepper motors are good. So maybe it has to do with the mks gen L board somehow?
I programmed it as a ramps 1.3 since the pins are basically the same. So how does the code know if a pin is analog or digital? I mean it seems to know for the LCD
UPDATE: For some reason, the mirrored stepper (EXT1) works fine. I tried switching drivers and the same result. The only difference I can tell from the code is that it used all digital pins and no analog pins.
I also just noticed from comparing the working drive and the non working x axis drive. I found that the step pin for the non working driver isnt reading anything while the working one does.
So this would imply that the step signal isnt being sent. Why? the pin number is correct
When board enables all pins are digital inputs I think just to protect the connected parts. Then pins assume the function you assign. You are in big trouble if you use a pin for several functions. E.g. if step pin is for stepper but also defined as analog input which is last than it is analog input and changing digital output won't do anything.
From your last comment I read that all motors work except one? I though changing the microswitch made all not function at once. I also think you might want to use RAMPS1.4 instead. Not sure what exactly the difference is but most clones are ramps1.4 clones.
So one thing would be to run your test script with the board and the pins from ext0. Then you know board and socket are ok. Then problem is in firmware is either another function uses the pin or wrong pin number in pins.h or a parameter for extruder is bad (0 steps/mm, nan or 0 for jerk/acceleration or cold extrusion not enabled). In any case it narrows down where it comes from.
You should check configuration.h to not use one of the pins used at that extruder motor. Normally this is not the case as we don't use motor pins for any function. So you must have written it your self between the time where it worked and afterwards. If you did not change config pins or config in between that is unlikely the problem.
Comments
What happens if you set microsteps back to old settings? In case driver just does not work with that combination you used as that is when it started to fail.
With test script and loose motor I see no reason to stall in one direction. If motor is mounted somewhere the force required for back direction might be different. The high pitch sound comes from motor I guess and that happens when motor is loosing steps. Easy to produce when you start with a too high speed. Then it stalle directly and only beeps until steps stop.
Then pins assume the function you assign.
You are in big trouble if you use a pin for several functions. E.g. if step pin is for stepper but also defined as analog input which is last than it is analog input and changing digital output won't do anything.
From your last comment I read that all motors work except one? I though changing the microswitch made all not function at once. I also think you might want to use RAMPS1.4 instead. Not sure what exactly the difference is but most clones are ramps1.4 clones.
So one thing would be to run your test script with the board and the pins from ext0. Then you know board and socket are ok. Then problem is in firmware is either another function uses the pin or wrong pin number in pins.h or a parameter for extruder is bad (0 steps/mm, nan or 0 for jerk/acceleration or cold extrusion not enabled). In any case it narrows down where it comes from.