[bcmaint]

We are using NEMA23 Steppers, KFlop/Kanalog, KmotionCNC. My problem is I'm losing .002 in the axis each time I perform a move. I set up a repeating Z move from 0 to -5. After a few moves it hits the limit.

Attachment 322720

I determined the amount it was off by homing the axis, them manually jogging it away from the limit, then back to the limit. Each time it hit the limit was a .002 to .003 difference.

[CitizenOfDreams]

Well, it sounds like you are losing steps. Too much load on the Z axis? Too much speed? Too much acceleration (did you mean to type 600 instead of 6000)?

[bcmaint]

That probably should be 600, but it's happening in the X axis as well

[m_c]

714 is a pretty low count per inch, which makes me wonder if the step/direction pulse timing is correct for your stepper drivers?

If the direction setup time is too short for the drive, then the drive could potentially move one step in the wrong direction each time the direction changes. Which given your low count per inch setting, would mean over a 0.001 error every time the direction changes.

What drives are you using?

[TomKerekes]

Acceleration of even 200 in/sec^2 is quite high (over 1/2 G).

Velocity of 160in/sec is crazy high as well (but probably not causing the problem as long as you aren't specifying a crazy feedrate). What feedrate are you commanding?

Do you really have a Kanalog?

Regards

[bcmaint]

The machine we built is using a timing belt. The drive is set for 2000 counts/rev. I can change it to a higher count. I'm using Kanalog because we had purchased it previously for a servo maching but that project fell through. I opted to use it now because it's more convenient with all the connections. I just used the ethernet connection to command the steppers. The machine this is on is being used as a part picker, so I was trying to get it to move as fast as possible without losing counts. The commanded speed for these moves was 600. The drives and motors were purchased from Amazon from Longs Motors.

[TomKerekes]

Hi bcmaint,

The machine we built is using a timing belt. The drive is set for 2000 counts/rev.

We'd need to know the timing belt/pulley specifics to be able to calculate the system resolution.

The commanded speed for these moves was 600

If GCode is in inches then that would be 600ipm or 10in/sec. If that is the fastest your machine can move then you should reduce the trajectory planner settings from 160in/sec to 10in/sec. But again this isn't the cause of your drift. It would only be a problem if someone specifies a Feedrate too high.

Drift in stepper systems can be cause mechanically by stalling/skipping steps or electronically by missing a step pulse or interpreting a step pulse in the wrong direction. Mechanical skipping will always result in being off by a multiple of the stepper's motor poles (1/50th of a rev). Electronically missing a step pulse will result in being off by a multiple of 1 microstep (1/2000th of a rev in your case). A pulse interpreted in the wrong direction will result in being off by 2 microsteps (1/1000th of a rev in your case).

I suspect your issue is electronic rather than mechanical (as m_c suggesteed).

It would have been nice to include a link to the drive specifications for your drives. I Googled and found this which may or may not be your drives:
http://www.longs-motor.com/productin...12_80_137.aspx

It doesn't seem to include any timing specifications for the Step/Dir signals. You should set the KFLOP Step Pulse timing to maximum 63 (3.78us). with:
FPGA(STEP_PULSE_LENGTH_ADD)=63 + 0x80; // set the pulse time to 3.78us and pulse the Step High
in your Init C Program. Are you doing this?

What Version of KMotion Software are you using? Newer Versions such as V4.33 provide more Direction Setup Time than earlier Versions.

HTH
Regards

[bcmaint]

The timing belt is an xl with .200" pitch. The pulley is 14 tooth.

The driver i have is this one http://www.longs-motor.com/productin...12_80_131.aspx

I changed counts/rev to 20000.

I do not have that line in my init C program. Should I just copy paste what you have there?

[m_c]

Yes, just copy the code into your init.c main function.

The following code should make copy and pasting easier -

FPGA(STEP_PULSE_LENGTH_ADD)=63 + 0x80; // set the pulse time to 3.78us and pulse the Step High

[bcmaint]

I changed the drive to 20000 counts/rev and have the following settings. I was able to run the repeating gcode 500 times without hitting the limit, so I'm going to assume I'm not skipping poles as much as before. I also pasted that code into my init file.

[TomKerekes]

Hi bcmaint,

Increasing the steps/rev may have only reduced the problem and made it harder to solve. It might have been better to change the pulse period first to see if that would have solved it.

Increasing the drive steps/rev should have increased your axis resolution counts/inch but from the screen shot I don't see that you changed it.

The Velocity and Acceleration values seem much more reasonable for X and Z. But the Y values are still huge.

Regards

[bcmaint]

Thanks Tom,

I changed the steps/rev from 714 to 7140. It's not exact, but it's close. This machine doesn't have to be very precise, it's only picking parts from a press and placing them on a tray. However, it does have to stay consistent. I ran my program 900 times yesterday without it hitting the limit switch. Each tray has about 100 parts, so it should stay consistent long enough to fill a tray, then I can have them re-home it before each tray.

I haven't changed anything on the Y axis yet since it's not assembled yet. Will be working on it this week. It uses a ballscrew since it will be supporting the tray which could get heavy and it only moves a few times after each row of parts is filled.

This is a video of a machine similar to what we are building. It's at 0:45 and only last a second, but should give you an idea of what we're trying to do. It's looking like we won't be able to achieve the speed that this one moves at, but we should be able to get it moving at a reasonable speed without skipping poles.

https://www.youtube.com/watch?v=MkUjP2wPTY8

Mike

[coherent]

First I wouldn't do the zero off of the limit. Limit switches have a small error factor and unless they are very expensive high precision switches, you will have reputability errors. Start from a specific point marked on your table or on an axis rail etc. Start movement in the X direction, mark the point, then continue in the same direction (this eliminates the backlash factor) for a known distance, then measure it. The compute actual steps per. Do the same for the other axis. If you are off, (and everything is tight and there is zero play in your couplers/bearing mounts etc) it's likely your steps per. Even though your math may give you a certain number, the exact steps per over a distance may be a few or even dozens of steps off. I know Mach has a wizard build to test and reset the steps per whereas I haven't used the software you are using. If you travel out and back to the same place you now have to factor in backlash when you reversed the motors direction. You may have already noted this and I missed it. Slow down your movement speeds also to ensure the motors aren't missing steps during the moves. After everything is correctly set and no steps are lost, then slowly raise speeds to a working level.