Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to calculate thread length? #121

Open
samsal opened this issue Mar 24, 2021 · 17 comments
Open

How to calculate thread length? #121

samsal opened this issue Mar 24, 2021 · 17 comments

Comments

@samsal
Copy link

samsal commented Mar 24, 2021

This is not an issue, just a question I couldn't find an answer to. I would be really thankful if someone can provide some help with this.
I'm trying to come up with a formula to calculate the thread length needed for a pattern.
I tried the distance formula between 2 stitches ( d = sqrt(a^2 + b^2) ) :

file = "../assets/e4-1053.DST"
pattern = pyembroidery.read(file)

distance = []
for i in range(0, len(pattern.stitches)-1, 1):
    if pattern.stitches[i][2] == pyembroidery.STITCH:
        a_x = pattern.stitches[i][0]
        a_y = pattern.stitches[i][1]
        b_x = pattern.stitches[i+1][0]
        b_y = pattern.stitches[i+1][1]
        d_x = a_x - b_x
        d_y = a_y - b_y
        distance.append(math.sqrt(pow(d_x/10,2) + pow(d_y/10,2)))

threadlen = sum(distance)
print(threadlen)

the result for this example is about 19.2m

I know this is missing the distance the thread has to travel at each stitch point passing through the fabric, but the result is way too far off compared to what I get when I open the same file in Wilcom truesizer where I get 55m.

What am I missing?

@tatarize
Copy link
Contributor

Well, you wouldn't divide by 10 there. The native units within pyembroidery are 1/10th mm. I would assume that that code would actually work. I mean I wouldn't use a list there and I wouldn't use pow but that seems to be about what I'd do. Yeah, you lose a little bit of thread with each stitch but I'd figure that for a somewhat static amount.

distance = 0.0
for i in range(0, len(pattern.stitches)-1):
    if pattern.stitches[i][2] == pyembroidery.STITCH and pattern.stitches[i+1][2] == pyembroidery.STITCH:
        a_x = pattern.stitches[i][0]
        a_y = pattern.stitches[i][1]
        b_x = pattern.stitches[i+1][0]
        b_y = pattern.stitches[i+1][1]
        d_x = a_x - b_x
        d_y = a_y - b_y
        d_x *= d_x
        d_y *= d_y
        distance += math.sqrt(d_x + d_y)
print("%fmm" % (distance * 10))

There's some chance your dividing by 10 there and not checking of both the stitch before and after are stitches could make up some of the difference.

@samsal
Copy link
Author

samsal commented Mar 24, 2021

Thank you! I guess I will try different samples in True Sizer and see how it compares to my calculated values and try to add some constant*stitch_count, maybe I will come up with a constant factor.

@samsal samsal closed this as completed Mar 24, 2021
@tatarize
Copy link
Contributor

Nah, your divide by 10 thing wouldn't change anything and is correct. The naive solution doesn't seem to work. I would guess that Wilcom is adding Bobbin thread too. But, even that doesn't really add up.

wilcome v length

    def pattern_length(self, pattern):
        distance = 0.0
        for i in range(0, len(pattern.stitches) - 1):
            if pattern.stitches[i][2] == pyembroidery.STITCH and pattern.stitches[i + 1][2] == pyembroidery.STITCH:
                a_x = pattern.stitches[i][0]
                a_y = pattern.stitches[i][1]
                b_x = pattern.stitches[i + 1][0]
                b_y = pattern.stitches[i + 1][1]
                d_x = a_x - b_x
                d_y = a_y - b_y
                d_x *= d_x
                d_y *= d_y
                distance += math.sqrt(d_x + d_y)
        return "%03fm" % (distance / 10000)

@tatarize
Copy link
Contributor

My check equals out to about the saem as yours. Wilcom's total thread seems to be about 2x the length fairly exactly. Like double the length you get and you get wilcom's length. I don't know why.

@samsal
Copy link
Author

samsal commented Mar 24, 2021

image

By changing the "Thread fabric thikness" to 0.01mm instead of 1mm we get somewhat closer but still far off.

@samsal samsal reopened this Mar 24, 2021
@tatarize
Copy link
Contributor

Hm. And the bobbin length as percent of other length. I think it's adding 0.01 * 2 per stitch. And 100% of the bobbin thread.

@tatarize
Copy link
Contributor

Which means their length is 2 * (length + 0.01*stitches). --- certainly worth checking.

@samsal
Copy link
Author

samsal commented Mar 24, 2021

I don't think they add the bobbin thread length to the top thread length (changing the bobbin percentage in True Sizer doesn't affect the Top thread length).
I tried length + 0.01 * 2 * count_stitches() but that only adds a small length that still doesn't get near the Wilcom value.

@tatarize
Copy link
Contributor

Seems like we could try scaling the length down without changing the number of stitches and see what that does to the total. It seems like it really is about 2x + change.

@samsal
Copy link
Author

samsal commented Mar 24, 2021

image
It seems there is a big difference between the different Softwares regarding this. So I'm not sure which is more realistic. My family company uses Gis Basepac (which I don't have access to atm) for their production, they should have a pretty good idea which values are the most realistic and what makes sense. I will ask them about this asap and will get back to you.

@tatarize
Copy link
Contributor

Took a design with length 36.251040m and shrank it a bit to 29.370066m
Wilcom went from 75.12m (28.98m bobbin) to 65.84 (23.49m bobbin).

So 81% raw length. Yields a 81% raw bobbin length. But, a 87% total length. With 1mm thickness material at 100% bobbin.

@tatarize
Copy link
Contributor

And I'm getting 81.4 raw length change if I change the material thickness. Also, changing the thickness a bit causes it to spike to amusing levels. So I'm guessing they likely have some other math to account for the bowing of the material and how much extra thread that takes.

I'd say nothing's wrong with your math, but wilcom's doing some additional stuff that is somewhat fancy.

@tatarize
Copy link
Contributor

Adding 1mm thickness adds (stitches * 2 * 1mm) to the raw thread length. So each stitch adds 2 * thickness of thread to the count and nothing to the bobbin there.

@tatarize
Copy link
Contributor

And bobbin length does nothing to the overall thread length. And the min thickness of material is 0.01mm which would be adding 0.02mm * 12757 which would be like 25.5mm. Which might make up some of the extra distance there. But, I dunno why they are still about 2x overall.

@tatarize
Copy link
Contributor

I think wilcom's equation is something like total_length * 1.375 + 2 * thickness * stitches. It seems to be about 37-38% longer than the raw distance. I'm guessing because material floof or they actually measured it and took the average additional length such things did. Since the thread isn't perfectly taught.

@samsal
Copy link
Author

samsal commented Mar 24, 2021

Yes I tested your formula and that's pretty much what Wilcom uses! Thanks again :)
I guess it should be realistic but I will make sure with the company and how it compares to Gis BasePac.

@tatarize
Copy link
Contributor

I would assume wilcom probably actually measured it. And made a pretty good guess. Comparing it to other software is likely fine but the real gold standard should be comparing it to how close it actually comes to being correct with those lengths. If you run a 200m spool, does it die where that estimate suggested it would? Etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants