Steps on Y and Z not working as expected

[dolence]

Hi!

I'm trying your port and noticed while steps on X axis are doing fine (nice smooth movement!) on Y and Z it's it's jerky, somewhat noisy and incorrect. It's a known issue? What's the stats of this port? You are doing a great work so far. Thanks!

[MechaSteve]

Honestly, I primarily posted this to show my current progress. It has not been significantly updated.

This is very much a work in progress. I haven't tested Limit switches, probing, operator buttons, or much else.

What kind of machine are you testing this on? What are you using to connect the launchpad to your motors?

[dolence]

Steve, I'm building a vinyl cutter plotter from an 132 columns matrix printer. I can help testing those features. Launchpad is connected to easy drivers and steppers using Dupont connectors. I tried the same setup using an STM32 port and yours have noticeable smoother movement. Sadly, I don't know why only X is working, thought. I will investigate more tomorrow, but it seems to be on software side. If I switch the working X step output signal to the easy driver wired to Y motor it runs fine. It's something on step output of those two axis.

Thanks for your fast reply.

[MechaSteve]

I took a real quick look, and there is a good chance it has something to do with the STEP_MASK const or one of the X/Y/Z_AXIS_MASK const. I made a significant change with how those are used, and I don't think I got all the changes right in all the places.

The change I made was the masks are no longer dependent on IO pin assignment. X axis is always 0x01, Y is 0x02, and Z is 0x04. The same masks are used to select Step pins, direction pins, and will be used for limits and other functions. The actual IO pin mapping is handled in the inputs and outputs includes.

The mistake I have made several places is not using the correct masks, or not reading them correctly. If you find more places with that mistake please let me know!

[dolence]

Thanks Steve. I will try it!

[dolence]

Steve, I didn't find any inconsistences between how X masks axis is being handled and Y/Z. This portion is expected to be this way? Here X is different compared to Y/Z:

        //X Step
    SysCtlPeripheralEnable(X_STEP_PORT);
    GPIOPinTypeGPIOOutput(X_STEP_BASE, X_STEP_PIN);
    //GPIOPadConfigSet(X_STEP_BASE, X_STEP_PIN, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_OD_WPU);
    //GPIODirModeSet(X_STEP_BASE, X_STEP_PIN, GPIO_DIR_MODE_OUT);

    //Y Step
    SysCtlPeripheralEnable(Y_STEP_PORT);
    GPIOPadConfigSet(Y_STEP_BASE, Y_STEP_PIN, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_OD_WPU);
    GPIODirModeSet(Y_STEP_BASE, Y_STEP_PIN, GPIO_DIR_MODE_OUT);

    //Z Step
    SysCtlPeripheralEnable(Z_STEP_PORT);
    GPIOPadConfigSet(Z_STEP_BASE, Z_STEP_PIN, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_OD_WPU);
    GPIODirModeSet(Z_STEP_BASE, Z_STEP_PIN, GPIO_DIR_MODE_OUT);

[MechaSteve]

Yeah, that could certainly do it. That configures the Y/Z axis as open drain outputs, and the X axis as push/pull. Looks like I was testing a simplification and have not implemented it on Y and Z.

No reason the Y/Z can't be push/pull as well.

[dolence]

I tested changing Y to be like X. Didn't work. Something I noticed is that no matter if I jog Y+ or Y- the direction is always the same.

[MechaSteve]

Have you checked that the direction signals are connected to the pins specified in cpu_map file? Have you put a probe or scope on the direction pins?

[dolence]

Direction was wired to the wrong pin, my bad, direction is fine. Steps still acting weird. I tried long distance, 2000mm and 2500 feed rate (1/8 microsteps) and it worked almost as expected. If I change feed rate a little bit up to 2530 the problem occur. I have the impression that acceleration isn't working. When I reduce distance to 1000mm stepper stalls. This night I will investigate further, using an scope and will upload a video showing what happens. Have you tried your port in real hardware before? I really liked your port, I think we can make it fully functional.

[MechaSteve]

I have a Ball Screw / Linear Rail axis I have been using to test. The electronics are External Stepper Drives (DQ542MA by Wantai) The steppers themselves are NEMA 23 4A/ph motors by US Digital. They aren't available anymore, but they are designed for low EMF to allow for high speed (at the expense of torque constant.) Everything is powered by an industrial 24V/20A power supply. I made a custom interface board that puts an open drain buffer between the mcu and the stepper drivers.

I would suggest tuning down your acceleration, and see if the problem persists. I usually aim to tune things by this method:

1. At minimum acceleration (10mG or less) increase speed until motor skips. Set max velocity to half this value.
2. Increase acceleration, give a short linear motion, and increase accleration until motor skips. Set acceleration to half this value.

That should give you a good starting point.

One major improvement is I plan to increase the acceleration frequency from 100Hz to 1kHz. I have done other experiments that show this can make a large difference. In the longer term I plan to implement per-step acceleration, at least at low speeds. The controller will calculate each step period up to about 3kHz, then switch to planning blocks of 3 or more steps up to about 100kHz.

[dolence]

I will try to tune the motor this night. When you have time, would you please test if your Y is working the same way as X? Once I figure out what is hapenning I will test homing, keys, etc

[MechaSteve]

I will test that on Friday.

[dolence]

I did the tuning as you said and after a fine adjustment both axis works fine. I'm really sorry for any inconvenience. I'm going further, do you wish my feedback?

Thanks for helping me.