Array Tool - The Math Isn't What I Was Expecting (but it isn't the array function)

…it turns out to be (I know this will sound ridiculous) the limitation of dimensions to the 10,000th of an inch. :pleading_face: Don’t back hand me just yet… hear me out.

As I was prepping the intersecting lip for joinery by way of notching, I discovered why doing this in the past has been with challenging result. I will illustrate with an example:

If setting out to joint these two sides together with notches, first I take my material thickness into account: .23" and draw a box for that dimension:

Then I decide that I want 1" notches, so I duplicate the shape and divide its width by 16:

With the array tool, I now create my notch segments:

It works out fine:

Its when the base object isn’t an even number like the example with 16" of width. When working with a width such as this I divided it by 16 (and there lies the problem, the quotient from the first divisor as the result was .9786):

So the resulting array did the math as it should (.9786 * 16 = 15.6576). But that is now longer than my original.

I understand, the width and height appears to be capped at a resolution in the 10,000ths. And it seems rational and adequate. I always thought so. But this is at least one example where it can show itself. You know, maybe it won’t even make a difference. I’ll make the pieces and report back. I’ll probably have more of a challenge with my own laser kerf than 8/10,000 of an inch.

You know what never mind. Back hand away…

Yeah…

It came out just fine. :man_facepalming:

interesting effect and (still) nice result!
… another reason to switch to mm! :wink:

You rounded to 4 decimal places —15.6568 / 16 = 0.9786

If you round to 5 places -------------- 15.6568 / 16 = 0.97855

In Lightburn 0.97855 * 16 is rounded up to 16.6569 if you use the array function on a rectangle that is 0.97855" x 0.230"

If you array a vertical line 17 times with 0.97855" space in “X” it comes out to exactly 16.6568"

I didn’t do any of the rounding. The four places of rounding is applied by the application.

In fact, even when I tried to manually create / set the width of the initial array box, the value was automatically rounded for me.

After writing all of this I decided to post as I thought it would help others (as I ended up helping / realizing myself) understand that unless we are building a mile long (1.609344 km for @bernd.dk :wink:) wide or tall of a project, even a 10,000th of an inch (or even better 10,000th of a mm) is not going to be noticeable.

It was that amazing deep zoom level that caught me. But after writing the post and walking myself through it, I realized… I was nuts.

When I key in 15.6568/16 into the width box, it returns 0.9785


Lightburn only displays 4 decimal places, but is accurate to 7 decimal places in metric and 9 decimal places in imperial units.

If I look at the LBRN code for the above rectangle, it is:

Shape Type=“Rect” CutIndex=“0” W=“24.853899” H=“5.842” Cr=“0”>

24.853899/25.4 = 0.9784999606299213"

Lightburn is accurate when you key the values in. But, because Lightburn used 4 decimal places as the result of itself doing add, subract, multiply, or divide, there are some rounding errors. Might be nice to have a check box in setup that allows you to increase precision in the boxes below in green. The ones in yellow are probably ok.
image

A simple test to do is key in a 3mm square into Lightburn in imperial units. If you do it to 8 decimal places, key in 0.11811023 into the width box with the lock on. Below is the code in the LBRN file.

Shape Type=“Rect” CutIndex=“2” W=“2.9999998” H=“2.9999998” Cr=“0”

If you go back to Lightburn and add 1 more decimal place to make it 9, and key in 0.118110236 to the width box with lock on, the code in the LBRN file is:

Shape Type=“Rect” CutIndex=“2” W=“3” H=“3” Cr=“0”

Basically, Lightburn is accurate to 9 decimal places from imperial units to metric, provided you are willing to key them in :slight_smile:

but, still interesting and amusing… :thinking: :laughing:

There could be a fairly elegant and simple solution to this, being able to set the total movement instead of the incremental movement. Maybe it’s relatively easy to implement as well.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.