Lee DeRaud
02-13-2006, 6:07 PM
Something to watch out for if you require very precise cuts...
Here's a simple example of what's happening:
1. Set 'snap-to-objects' on, 'snap-to-grid' off, and set the display precision to five digits.
2. Draw a rectangle and size it to 4.00000x4.00000, center it at 3.00000,3.00000.
3. Using the polyline tool, draw a line from one corner node to the opposite corner. Repeat for the other pair of corners.
These two lines should be 4.00000x4.00000, centered at 3.00000,3.00000, same as the square, right? No: on my system, they are 4.00234x4.00234, centered at 2.99017,3.00514. Huh?!?
It gets better:
4. Delete the diagonal lines.
5. Rotate the square 45 degrees.
6. Repeat step 3.
The square is now 5.65685x5.65685, still centered at 3.00000,3.00000. That dimension works out to 4.0*sqrt(2), as expected. The diagonal lines (now vertical and horizontal) should be 5.65685x0.00000 and 0.00000x5.65685, still centered at 3.00000,3.00000. Nope:
Vertical: 0.00002x5.65848 at 2.99369,3.00514
Horizontal: 5.65848x0.00002 at 3.00749,2.99134
The change in dimension is at least consistent in X and Y, the change in position is not.
Lest anyone accuse me of being picky, note that these errors are the same order of magnitude as the "kerf width" of the laser. I discovered this anomaly when some cut parts that should have been identical were not. An example:
1. Draw a 4x4 square.
2. Draw a 2x2 square, centered on the 4x4.
3. Draw four lines connecting each corner of the inner square with the adjecent corner of the outer square.
The four lines drawn in step 3 should be identical except for orientation: they're not. Worse, if you cut out the four trapezoids, they don't match.
My first thought was round-off error, but the numbers involved should survive intact using anything more sophisticated than 16-bit integer math. Then I noticed the errors were different depending on which computer I was using. But it's not the computer: it's the screen resolution. The 'snap-to-object' function is apparently using the coordinates of the nearest screen pixel to the node you're snapping to, instead of the actual node coordinates: if you 'zoom-to-selected' on the 4x4 square, the errors are smaller. Of course, if you're working with large objects, that won't help, since as far as I know, you can't pan/zoom after you establish the first node of a multinode drawing operation.
I realize that CorelDraw is not a CAD system, but this is just plain wrong.
Here's a simple example of what's happening:
1. Set 'snap-to-objects' on, 'snap-to-grid' off, and set the display precision to five digits.
2. Draw a rectangle and size it to 4.00000x4.00000, center it at 3.00000,3.00000.
3. Using the polyline tool, draw a line from one corner node to the opposite corner. Repeat for the other pair of corners.
These two lines should be 4.00000x4.00000, centered at 3.00000,3.00000, same as the square, right? No: on my system, they are 4.00234x4.00234, centered at 2.99017,3.00514. Huh?!?
It gets better:
4. Delete the diagonal lines.
5. Rotate the square 45 degrees.
6. Repeat step 3.
The square is now 5.65685x5.65685, still centered at 3.00000,3.00000. That dimension works out to 4.0*sqrt(2), as expected. The diagonal lines (now vertical and horizontal) should be 5.65685x0.00000 and 0.00000x5.65685, still centered at 3.00000,3.00000. Nope:
Vertical: 0.00002x5.65848 at 2.99369,3.00514
Horizontal: 5.65848x0.00002 at 3.00749,2.99134
The change in dimension is at least consistent in X and Y, the change in position is not.
Lest anyone accuse me of being picky, note that these errors are the same order of magnitude as the "kerf width" of the laser. I discovered this anomaly when some cut parts that should have been identical were not. An example:
1. Draw a 4x4 square.
2. Draw a 2x2 square, centered on the 4x4.
3. Draw four lines connecting each corner of the inner square with the adjecent corner of the outer square.
The four lines drawn in step 3 should be identical except for orientation: they're not. Worse, if you cut out the four trapezoids, they don't match.
My first thought was round-off error, but the numbers involved should survive intact using anything more sophisticated than 16-bit integer math. Then I noticed the errors were different depending on which computer I was using. But it's not the computer: it's the screen resolution. The 'snap-to-object' function is apparently using the coordinates of the nearest screen pixel to the node you're snapping to, instead of the actual node coordinates: if you 'zoom-to-selected' on the 4x4 square, the errors are smaller. Of course, if you're working with large objects, that won't help, since as far as I know, you can't pan/zoom after you establish the first node of a multinode drawing operation.
I realize that CorelDraw is not a CAD system, but this is just plain wrong.