Runaway after switching rotation direction

[rob-mcinerney]

Had to switch default direction when I swapped from X to Y axis on printer. After switching direction via the set up menus, I commanded a short jog motion via the printer interface, it made a short move correct direction then reversed and ran away at a slow speed. I can't duplicate right now as motor isn't on printer any more.
Maybe you can check on your bench.

[CAP1Sup]

When you say runaway, you mean that it kept on moving past the opposite directions distance? What I mean is, when commanded to move clockwise, does it move clockwise first, then turn double that distance back counter-clockwise? I think that I know what the issue is (the hardware counter isn’t inverted when switching direction). The motor counts step pulses in the event that it cannot carry them out at that moment. I think that the motor is moving in the opposite direction like it should, but the hardware step counter is still counting in the standard direction.

[rob-mcinerney]

Well sort of, this is what I can figure out. After changing "Dir. Logic" via the set up menu to "Inverted" and giving it a command (not sure if it CW of CCW - I didn't keep track of the direction - Sorry). The motor moves a commanded direction (I think it is correct as commanded and the distance is as commanded, but more testing would be needed to confirm, I used a short 10mm commanded distance, which should have been a partial motor rotation). After the move, the motor reverses direction and continues to run the opposite direction (I think it is a runaway - I never had it stop when it was going the wrong direction).
FYI I did not try recalibrating after the "Dir. Logic" was changed, would this help?
I do not have the motor connected to the printer right now so further testing is tough to complete.
Hope this helps!

[CAP1Sup]

I think that I fixed the counter issue in 30e565a. I can't believe that I didn't think to test the direction inversion, that's such a basic feature. I'm probably going to set up an automated testing bench if I have time due to the amount of testing for the different features. Probably not going to happen anytime soon :). Take your time on testing, there's no rush. Calibration shouldn't be affected by the direction logic. Let me know the results when you have the time to test.

[rob-mcinerney]

OK, testing is tough, I have to disassemble the printer and reinstall the BTT motor adapter on the mother board. Right now the MKS-42SERVOC's are running a print job.

[svsergo]

After applying the voltage and executing the first command to move, the command is executed correctly. But after executing the command, a slow movement in the opposite direction begins. On the display screen, ERR has a very large value. If, after applying power, press the RESET button, the engine starts working correctly. I suppose it has something to do with initializing variables.

[rob-mcinerney]

Did you use the latest commit?

[svsergo]

the latest version 0.1.0 is used

[CAP1Sup]

@svsergo I think that the issue that you’re seeing is a result of incorrect overflow handling of the timer itself. I’m going to have to do some work with my board there, so is it possible for you guys to switch the direction of the motor in Marlin or whatever other board firmware you’re using for the time being? I don’t want to leave you guys stuck without a solution because I don’t know when I’ll have time to work on it

[svsergo]

The error occurs regardless of the set direction of rotation in the firmware configuration. And disappears if you press the RESET button on the device. And it occurs again only after disconnecting and powering on the device.

[rob-mcinerney]

FYI, I am fine for now, no pressing time line.