Losing Y steps - but odd

[twehr]

I have noticed (somewhat lately) that I am losing steps in the Y axis part of the time. Oddly, it is only when running at SLOWer speeds. At higher speeds, there is no problem. In all cases, it is only when doing engraving - vector cutting does not seem to be affected.

I could understand losing steps at higher speeds, but losing at lower just has be baffled.

In the photo, the hand written numbers are the speeds, in mm/sec. Notice that once I get down to 100 or lower, the image is greatly foreshortened. The vectors all remain the same height.

Ideas?

Lost Y Steps.png (775.41 KiB) Viewed 28287 times

[whmeade10]

I have noticed (somewhat lately) that I am losing steps in the Y axis part of the time. Oddly, it is only when running at SLOWer speeds. At higher speeds, there is no problem. In all cases, it is only when doing engraving - vector cutting does not seem to be affected.

I could understand losing steps at higher speeds, but losing at lower just has be baffled.

In the photo, the hand written numbers are the speeds, in mm/sec. Notice that once I get down to 100 or lower, the image is greatly foreshortened. The vectors all remain the same height.

Ideas?

Lost Y Steps.png

That is very interesting Tim, when I get my Lightobject DSP going this week I can verify if it is a software issue. If it was hardware I would imagine you would hear the belt slipping on the steppers. What version DSP software are you using? Is it the new version with auto focus?

= Bill

[BenJackson]

It's possible that your Y stepper driver is overheating. These modern one-chip solutions generally have builtin thermal protection. When it trips they cut out. When you are going slower you are more likely to be pausing the Y axis at a partial step. If the driver cuts out the motor will snap to one of the full step detents. If you can turn the machine off for a while and try a quick test right after you power it up you might see it work just fine before the stepper comes up to temp (assuming the engrave is pretty quick).

When the driver is in this state you can try moving the axis by hand. The thermal protection cuts in and out very quickly so it will let you move it along with a juddering motion as the holding torque cuts in and out.

I would try turning down the current on your Y stepper to see if it goes away.

[lovebugjunkie]

I do not have a laser (yet) but do have a cnc wood router so what I suggest might not apply.

The 12 and 1 look too unfirom to be caused by a machanical error/problem, if it were, I would expect to see the 12 and 1 made up of shorter/longer, darker/lighter or overlapping lines. Would also expect the vectors to not come out as nice as they are.

If my cnc wood router was doing this I would suspect software. To me it looks like it is being commanded to cut the way it is.

[bdring]

Sometimes this can happen when the image pixels and the laser resolution are way out of sync. It has to throw away image lines. Try scaling the image to the exact resolution of the laser.

[twehr]

I spent the last couple of hours running tests to try and narrow down the issue and hopefully come to some resolution. I appreciate the comments from everyone - they helped me in thinking about the tests and the results. Here are the tests and what I found.

Tests 1, 2, and 3 were run to hone in on the exact speed at which the issue occurs or ceases to occur. It appears that 113 mm/s fails and 114 mm/s succeeds.

Test 4 was run to confirm by alternating back and forth between 113 and 114 mm/s. Tests confirm the boundary.

Assumption: software issue, since it is so consistent.

However: An interesting thing to note here. The point of origin is always the upper left corner of the left-most block. The blocks are run one at a time from left to right. That means they should all be aligned at the top. As you can see, they are not. In fact, the top of each block (2...5) is exactly 1 inch above the bottom of the preceding block. If it is a software issue, meaning the software is intentionally (for whatever reason) rasterizing differently at speeds less than 114 mm/sec then it should know where it is and return to the correct y value to start the next block. But it obviously THINKS it has traveled 1 inch in Y, then it returns 1 inch in Y to start the next - thus "moving" the starting Y position of the next block exactly the distance it DID travel PLUS the distance is did NOT travel in the preceding block.

It could still be a software issue - of the "bug" type - meaning it does not know it is doing it.

Test 5 was a repeat of test 4 but done after I updated my DSP software with the latest version just released last week. The results of test 5 were identical to test 4, so the new software did not help.

Test 6 was run to determine if I can compensate for the loss of steps. It appears I can. The DSP software allows you to, when engraving a vector object, to set the distance between scan lines. By default, that distance is .10. That is what all the previous tests were run at. In test 6, I ran the 113 mm/sec blocks at a scan rate of .09 and the 114mm/sec blocks at .10. While they are not perfectly matched, they are visually close enough. So the solution is likely to be that I have to run make adjustments when rasterizing vectors, based on the speed I am rasterizing. Most of the time, I can run above 114 mm/sec without issue, but some materials require a slower processing.

I will send my test files and results to Marco, so he can pass it on to the engineers. I doubt that they are aware of the issue.

When anyone else gets the DSP up and running on their 2x, it would be interesting to see if you can duplicate my results on your system.

Thanks, again, to everyone who took the time to think about the issue and come up with some helpful comments.

[bdring]

Do you think the speed actually affects the Y? I would think the software would treat that as a rapid since the laser is off.

[bdring]

What motor driver are you using? I had similar result with the FSE controller very early on that were traced down to short length step pulses. The driver was missing the pulses. That does not sound like it would change based on speed, but I thought I would mention it.

[twehr]

What motor driver are you using? I had similar result with the FSE controller very early on that were traced down to short length step pulses. The driver was missing the pulses. That does not sound like it would change based on speed, but I thought I would mention it.

I am using some 5042's from LightObject. They are manufactured by the same people that make the Kelling drives (like the 4030's, etc).

[LeonS]

Do any of the engraving options (single direction left to right, scanning up and down on the Y axis, etc.) change the symptoms?

Regards,
Leon