.pes file not recognised by Brother innov-is v3

[tatarize]

With regards to, inkstitch/inkstitch#342

@tobiastykvart Does the failure to recognize the pes hold true for wilcom converted files and brother converted files? Here's your file converted to those.

Frankenrechen.zip

[tobiastykvart]

Thanks for your help, it recognized and stitched both converted files. I have used the wilcom converter before but which software did you use for the brother file?

However I have another problem which might be a separate issue: The design gets distorted in a way, so that there are gaps between the red and the white part. The machine starts stitching the white part on the right, where it lines up with the red edge. But the further it goes to the left the bigger the gaps/overlaps become. In the brother converted file this is not as bad, so after stitching the outline it looks fine. But the wilcom converted file distorts so much that even the outline can't hide it.

[tatarize]

@tobiastykvart I used PE-Design 6 to make the brother version. Usually it's best to have the format as made by the manufacturer to test things with. So I have a bunch of different programs that can make a bunch of different files and strongly lean on the the original company's software to test formats.

Secondly, the issue there is, in part, due to software but rather it's due to the software not accounting for pull. Fabrics are a different size when you start sewing than when you finish. The design in this case goes left to right across the top then right to left across the bottom in white. This means that the overall biggest difference in size will be between the first row of red and the last row of white which is where that gapping is the most. There's a few methods of combating this, use additional backing, like add several bits of backing to ensure the pull is minimized. Use a stronger medium something less stretchy will stretch less. Use underlay, it tacks down the design first so it doesn't stretch weird later. Use pull compensation, it offsets the later stitches to be fit more or less where they should end, within the design. I think inkstitch might have underlay, but if not you could simulate it. Start the design with a very light fill that fills the entire area etc. You could also ask over at the inkstitch issues page, wwdrew is a very experienced embroiderer and it might provide a forum for more general embroidery questions. But, basically tight stitches make the fabric tighter which moves where the points in the fabric would have been. It's not a coding issue.

However the pes files being produced sometimes throwing an error rather than sew on some machine actually is:

frankenr-tests.zip

Can you try these? They need not be sewn just checked as to whether or not they hit the same error as before.

• Frankenrechen-p modern pyembroidery, I fixed a couple things if that fixes the problem then I know where to look.
• Frankenrechen-pt modern pyembroidery, truncated. If the problem persisted I can use this to likely rule out the pes blocks altogether.
• Frankenrechen-bp your original file with the brother header and pes blocks attached to it.
• Frankenrechen-bc your original file with the brother pec block attached instead of the generated one.
• Frankenrechen-t your original file with a truncated pes blocks.
• Frankenrechen-bch your file with the brother pec header
• Frankenrechen-bce your file with the brother pec extends.
• Frankenrechen-bcs your file with the brother pec stitches
• Frankenrechen-bcsf your file with the brother pec stitches, fixed count.
• Frankenrechen-bcs your file with the brother pec graphics.

Again, only need to know if they hit the error, not that they sew. And which ones hit the error and which ones did not.

[wwderw]

Secondly, the issue there is, in part, due to software but rather it's due to the software not accounting for pull. Fabrics are a different size when you start sewing than when you finish. The design in this case goes left to right across the top then right to left across the bottom in white. This means that the overall biggest difference in size will be between the first row of red and the last row of white which is where that gapping is the most. There's a few methods of combating this, use additional backing, like add several bits of backing to ensure the pull is minimized. Use a stronger medium something less stretchy will stretch less. Use underlay, it tacks down the design first so it doesn't stretch weird later. Use pull compensation, it offsets the later stitches to be fit more or less where they should end, within the design.

Stitch angle can also play apart with push/pull as well.

How one hoops the substrate as well can play a part.

If the substrate has some stretch, may either want to use a solvy topping or do a contour lattice motif (in the color of the substrate to help "hide" the stitching) to help stabilize the stretchy ness of the substrate.

[tobiastykvart]

Only the -bc file works, same error for the rest.

I don't think the stretching is an issue of inkstitch either. Just seems like a big distortion for a small design. I've read about push/pull effect, that should contract vertically though, not horizontally, since the stitch is going vertically. Also shouldn't both the red and the white part get pulled together the same way? The two shapes are pretty similar, so if both would contract horizontally everything would fit together again. Once I can produce files that are recognized reliably I'll experiment more with underlays etc. and maybe open a separate issue.

[wwderw]

I've read about push/pull effect, that should contract vertically though, not horizontally, since the stitch is going vertically.

Contraction depends on the angle of the stitch itself, density of the stitching and of the fabric. That can be compensated to a degree from extra (and even heavier) stabilizers.

Smaller designs can actually be more problematic then bigger ones, especially if it's stitch heavy.

If the stitch angle matches the weave angle, that can also present some issues (most notably, "spooning", where the edges of the embroidery bow upward) (I don't think this is related, just worth mentioning).

Also shouldn't both the red and the white part get pulled together the same way?

Depends on what is specifically going on at the machine. How the fabric is responding to the design and the design itself could also be playing a part.

How tightly hooped is it as well? Sometimes shifts like these are more about hooping then anything else.

Is the substrate pill or no pill?

[tatarize]

@tobiastykvart Only bc. Hm. I was hoping for something to narrow it down more, maybe it's several things together. Okay, let's try the reverse. Rather than copying in the various parts of brother version trying to get it to work, I'll copy in the various parts of the pyembroidery into the brother to try to break it.

Frank-tests-2.zip

-pe: Pyembroidery extends -pg: Pyembroidery graphics -ph: Pyembroidery header -psb: Pyembroidery entire stitch block -psc: Pyembroidery stitch code. -pscf: Pyembroidery stitch code fixed (changed the end pointer to be correct) -pse: Pyembroidery stitch end-bytes.

[tatarize]

I'm way way less informed on the topic than wwdrew is but, code-wise those numbers add up. Instructions given didn't overlap and gap like that, given that they did mean it's physics rather than code.

[tobiastykvart]

If the stitch angle matches the weave angle, that can also present some issues

The stitch angle is 90°, so it stitches from top to bottom, so it can stitch each shape in one go without any jumps. The weave angle I'm not sure about, how do I find that out? I can't set that in inkstitch I think.

How tightly hooped is it as well?

It is actually not hooped at all. The stablizer is hooped but the fabric is a pretty thick felt just laying on the stabilzer. I don't think I can fix it with the hoop because of the thickness and it's usually too small (the felt is cut before being embroidered, my mother is making bags out of it, I'm more like the tech support :) We embroidered 100s of times like that, mostly with bought embroidery files, but stretching like that was never an issue, even without hooping. But we'll test it with a hooped fabric, fix it as tightly as possible, and see how it looks then.

Is the substrate pill or no pill?

The substrate is the thing that moves the hoop, isn't it? But what makes it pill or no pill? Haven't heard about that before, sorry.

Frank-tests-2.zip

I'll also test the other files and let you know.

[wwderw]

The stitch angle is 90°, so it stitches from top to bottom, so it can stitch each shape in one go without any jumps.

I'm not really following this.

Since you only have 2 fill objects and each their own color, there shouldn't be a jump stitch, no matter what angle it's at.

I tend to not suggest always having the same angle on the fill objects in the same pattern for a couple of reasons:

1. Push/pull is actually more a concern if everything is stitching at the same angle.

and

2. Visual appeal/interest

If it was just the last one, then muh, can just ignore as that's based on preference, but with that first one in the mix, that adds another dynamic to it.

It is actually not hooped at all. The stablizer is hooped but the fabric is a pretty thick felt just laying on the stabilzer.

The only time that I would suggest floating the substrate like that is if it was a pre finished blank patch that was being embroidered. Then I would use a stabilizer that had an adhesive top to it to stick the patch on for embroidering.

I don't think I can fix it with the hoop because of the thickness and it's usually too small (the felt is cut before being embroidered, my mother is making bags out of it, I'm more like the tech support :)

There are different hoops to help hoop different substrates.

If these are being pre-cut individually, cut to where there is overhang outside of the hoop to make it easily hooped.

The substrate is the thing that moves the hoop, isn't it?

Substrate is what is actually being embroidered. The shirt, hat, swatch of fabric etc.

We embroidered 100s of times like that, mostly with bought embroidery files, but stretching like that was never an issue, even without hooping.

Each file is going to be unique as well as each substrate that is being embroidered on.

[tobiastykvart]

Since you only have 2 fill objects and each their own color, there shouldn't be a jump stitch, no matter what angle it's at.

Not a jump stitch, but a running stitch to continue to the next part of the shape. It's very specific to this shape, but I had problems with the running stitch being offset too, outside of the actual shape.

[wwderw]

Ok, I get what you are talking about now.

Since you are wanting to put a thick satin outline around everything, I wouldn't worry about it for this design. If the fill stitches had exposed edging (which sometimes is the case, but preferable not), then I would be worried about it.

That traveling stitch isn't any different then when putting in traveling stitches yourself to go from one fill stitch object to the next that will be covered up by future stitches in the pattern in order to minimize trims.

The biggest question if something like this is going to be a concern or not is if there is going to be stitches covering it up later or not.

[tatarize]

@tobiastykvart I figured out a likely fault for the original "bug". Pyembroidery is built specifically to not lose information. This includes the actual absolute location of the stitches. In .PES files this means the initial trim at 0,0 and then it jumps to the real location of the embroidery stitching. You actually put the embroidery bit in the lower left hand corner. So consequently it trims and makes a massive jump to that location, then proceeds to stitch there. That could likely breach the bounds of the hoop. Wilcom and Brother do not do this, they go ahead and lose the absolute positioning of where the embroidery is.

It could simply be a valid .pes file but because the actual embroidery is not centered it trims and jumps to that location, and the machine says that's not permitted because it would require jumping out of the hoop at the very first stitch.

This would also explain why it worked for you before, you previously centered the designed in inkscape.

Frankencentered.zip

I loaded your original .svg file, centered it, and exported it as an embroidery. If this file loads then that's the error. The center of the hoop is the center of the svg viewport, when you actually put it in the corner like that, it actually tries to put it there and can't.

[tobiastykvart]

Frank-tests-2.zip

Those all worked.

You actually put the embroidery bit in the lower left hand corner.

I think that's it! The file you sent didn't show up on the machine at all, not even an error. But I made a new file, just a rectangle with the same dimensions and a fill. I exported it once in the center of the canvas and once in the corner, the one in the corner had the error while the other one worked. I didn't think it was important, where the design is on the Inkscape canvas. I had just put it in the lower left corner, because that's 0,0 in Inkscape and the rulers showed me the size of the design then. Do you think there is a way to avoid this error for other people in the future?

Also when stitching it on a tightly hooped fabric the gaps disappeared, it only showed the expected pull effect (slight contraction vertically), which I can find some workaround for.

[wwderw]

Also when stitching it on a tightly hooped fabric the gaps disappeared, it only showed the expected pull effect (slight contraction vertically), which I can find some workaround for.

When you digitized those fill objects, did you digitize them to where they go halfway underneath the outer satin border or do they just butt up against the border flush?

If it's the former, a little extra ump from another sheet of stabilizer should help, if it's the later, then move the fill nodes to where they go halfway underneath that outer boundary.

I always digitize with overlaps on objects like this to help compensate for push/pull. For lettering, when you have say an "I" and and "o" right next to each other, I make the "O" slightly bigger, so then when it contracts it should be the same height as the "I" (this does apply to more letters, I just mention these for examples).

[tobiastykvart]

It's overlapping, just not enough I guess, I don't know if my mother wants to spend twice the stabilizer :) But at least I know the cause of this stretching, so I can adjust the size.

[tatarize]

@tobiastykvart "Do you think there is a way to avoid this error for other people in the future?"

Yes, tell @lexelby at inkstitch/inkstitch#342 what the actual error is. While preserving all the data I possibly can is part of the pyembroidery philosophy there's a number of very easy methods to center the design when it's passed to pyembroidery (Calling pattern.move_center_to_origin() works on the modern version, etc.), or center it beforehand.

Pyembroidery preserves the absolute positioning of embroidery. So an off-center embroidery is properly converted to an off-center embroidery. Centering it in the hoop will prevent it from throwing an error for "the-first-thing-it-did-was-jump-way-outside-the-hoop", I don't automatically center an offcenter pattern, because doing that is by definition lossy and pyembroidery preserves as much data as it can.

However, given the nature of the error, it's not a pyembroidery bug. It's not even a bug at all, it's a undocumented feature (which I since added to the documentation). Tell Lex about it, and have him give you a default-checked checkbox for centering the embroidery on export.