Undesirable Centerline text behavior

[DickB]

I have carved several of these 28" x 14" area lake maps as they are popular items. This is a good one from quite a while ago done with Designer 1:


I carved one Tuesday and used Designer 2 as it is supposed to have improved Centerline. Carving proceeded from left to right as you view the board, the the bit was swapped and Centerline started. I was surprised to see that the trailing "e"s of "Little Pine Lake" were not cut. When all other letters were cut, the machine did go back and cut the three "e"s. However, x movement was off a fraction and the lettering was ruined by the "e"s touching their neighbors. If the "e"s had been machined first, this small error would never be noticeable.

I cannot say for certain if Designer 1 shares this behavior, but I will switch back to it next time.

I would like to know if in fact Designer 1 - or is it the older machine firmware - cuts text in order right to left. Also, if a change was made, why, and can it be put back. Or is there some way or trick to reduce long x movements.

[bergerud]

I do not use centerline much but I remember the older centerline doing only parts of letters and then coming back to finish letters. You would think the new centerline, supposed to be more efficient, would finish each local job before moving on.

I am not sure but I do not think the LHR programmers have control over the centerline algorithm. I think it is a 3rd party routine which they incorporated.

My complaint about the centerline I have done is that it is not very smooth. The cutting seems jerky. Riffler files are required for cleanup. It seems like the algorithm is intended for a rigid CNC with no tracking or backlash issues. With the CW, I think it is important to make the letters with smooth passes and, as you say, finish each word before moving on. Maybe LHR should start from scratch and write their own routines tailor made for the CW machine.

[bergerud]

I have been corrected on some of the things I said in the last post. LHR has not just adapted 3rd party software for the centerline but has spent great time and effort to write their own routines from scratch.

[FWMiller]

I have noticed in my projects that the order in which the centerline characters are carved depends in where on the board the machine stopped after finishing with the prior operation. It seems like it is trying to minimize x movement. It starts wherever the board is when you load the bit, continues to the end and the goes back and finished the other end. I have 1.187.

I have no idea how much time they put into their own algorithm but it wasn't enough. I'm not very impressed with it at all. No matter what font I use it doesn't cut a clean line. Licensing a third party algorithm might have been a good idea. But then it probably would cost $200.

[bergerud]

I think the problems are more to do with the x drive backlash and programmer fear of x slippage. As you say, minimizing x travel must be part of it.

[DickB]

Maybe I'm just not as critical, but I don't see an issue with the quality of Centerline, especially in oak or maple. That said, with harder wood, I sometimes see the somewhat "jerky" cut. I would like to see the local continuous cut, maybe each word done continuously, or a general x sweep from letter to letter once only and not a long return x movement, considered, since we learned that the brass wheel encoder can be ignored. I don't think there is a similar issue in the y direction.

[FWMiller]

The machine can cut a pretty smooth curve when doing vector cuts. So it does not seem to be a machine limitation.

[bergerud]

It is the changing of the x direction which I think is the problem. The motion has to stop and wait for the x drive to take up the gear backlash before the movement in the other direction can start. Watch how a circle is routed.

[Digitalwoodshop]

Maybe I'm just not as critical, but I don't see an issue with the quality of Centerline, especially in oak or maple. That said, with harder wood, I sometimes see the somewhat "jerky" cut. I would like to see the local continuous cut, maybe each word done continuously, or a general x sweep from letter to letter once only and not a long return x movement, considered, since we learned that the brass wheel encoder can be ignored. I don't think there is a similar issue in the y direction.

AL is still trying to wrap his head around this from when it was first posted..... The MATAG Guy is taking a sick day.... LOL...

Interesting thread... It would be curious to run the same project, Designer Version, rubber belt, and wood on 2 machines looking to see if this choppy text is mechanical.... and not software....

AL

[FWMiller]

When you look at the text in the software you can see that the herky jerky bit movements are generated by the software before the machine does any compensation for gear backlash. In my experience the designer rendering accurately predicts the results.