Speed offset between X and Y directions

Interesting problem I just came across:

It seems like my machine is moving in different speeds in the X and Y directions, within the same CAM contour operation (so same feed rate).

Initially thought this was a bug in kirimoto, so I switched to carbide create v6, and am seeing the same behavior, which points to some quirk with my machine.

Anyone have any thoughts on what could be causing this? See math below for the speed differences:

Michael

havent started cutting so its not immediately apparent if the scale of the movements are off as well, will run a test for that next to see if its a simple scaling factor issue

Test run, it’s moving the correct distances within 0.33%, which is definitely within my measurement accuracy of the sled while its moving.

Interesting problem stands. Sled moves the correct distances in X and Y, but at different speeds in each direction, when CAM tells them the same speed. Any thoughts?

Michael

1 Like

This is a super interesting observation! I looked into the code a little bit and at least the AI seems to think that there is a possible reason for it, I’ll need to dig deeper on Monday, but I think that this is a great thing to call out. Thanks for pointing it out!

mfinn wrote:

Interesting problem stands. Sled moves the correct distances in X and Y, but
at different speeds in each direction, when CAM tells them the same speed. Any
thoughts?

note that the feed rate in the gcode is the max speed allowed during this move.
The firmware ramps up to that speed, and in a wide rectangle with belts to each
corner (the typical maslow), pulling at the same speed on the top two belts will
move the sled faster than pulling at the same speed on the two side belts.

If the maslow is never getting up to the specified feed rate, you will see this
difference.

(the wider the angle between adjacent belts, the more you will move when those
two belts change length)

David Lang