Saving as DST and PES does not product the same results

[styloInt]

When I save the same pattern in DST and PES, I don't see the same result.

Most of the times for dst files there is a wire who go from the center to the first stitch. Here an example, the first image is a dst file and the second one is a pes file. They were saved from the same pattern.

Also, sometimes, the pes file is not centered even I use "move_center_to_origin". Here an another example :

Is there something I should do differently depending on the format ?

EDIT : I am not sure if the issue is with pyembroiderdy or if Wilcom True Sizer is not displaying correctly the files ...

[tatarize]

In the first element. What's happening is that the DST file is jumping to the location of the pattern. I'd have to look at the DST itself to see if Wilcom is visualizing it wrong. Or if the pattern was recorded correctly as such. The distinction is that DST files have a JUMP command which tends to mean move needle dx, dy then block the needle bar preventing the stitch. Usually this means move, but sometimes, if you already stitched somewhere, it means MOVE so it can make a very long stitch. And sometimes it's kind of ambiguous as to which you'd get.

For the second question it's actually a bit odd. The call to center the design did so. But, since it didn't have any reason to keep the non-stitched center to before hopping over to the position of the first stitch. Somebody either pyembroidery or Wilcom just went ahead and removed that. As a result the start location is not in the direct center of the pattern. And the initial position became the position of the first stitch. Generally because within DST you move dx, dy and then stitch. So the position of the first stitch does not need to be at the initial position. Since there is no requirement that 0,0,stitch be the first command it might have ended up being -20,-14 stitch which means the first stitch is at -20,-14 but started at position 0,0 which is something you can check for a dst file since the header will declare the initial start position.

[tatarize]

Also, there's some chance that it's simply not trimming. You can call get_pattern_interpolate_trim and get it to trim. Depending on how the pattern is being built. Usually the export routine will interpret that properly when it runs it through the encoder. But, sometimes it'll start from a format that takes the starting location as a stitch and then moves vs. moves and then stitches. It weirdly differs between formats.

[tatarize]

I'll check into a bit more. I know there are some edge conditions with a lot of the software where some of it calls some initial move stitched when the machine itself was not told to stitch anything and thus shouldn't have drawn that line. Like you start at 0,0 and are given the command stitch 20,20. Somethings will wrongly think there's a thread going from 0,0 to 20,20 when there's not. It moved to that location and then stitched there. I usually opted for what the manufacturer's software and sometimes, when available the actual machine behavior. Some encoding calls for a JUMP 20,20 then STITCH 0,0 which in DST is actually a waste, it will do a movement then a stitch and if you're within range you can merely call the relevant stitch. Pyembroidery has a FULL_JUMP option that could be used to turn that off. If you tell it to save a dst with the options { "full_jump", True } it should actually fully jump to the new location and stitch there.

But, I'll double check that that is totally what's going on here. I should finish work on #62 first since it's a fairly easy and basic set of things to do.

For what it's worth, thank you your feedback it's fantastic.

PS The merge patterns got added to pyembroidery. I also overloaded the + for the EmbPattern objects so you can just use that to merge things. Not that it's that needed.

pattern1 += pattern2 will merge pattern2 into pattern1. I also added a bunch of other elements that you could add to a pattern pattern1 += "red" and pattern1 += COLOR_BREAK or pattern1 += [(25, 25), (-25, 25), (25, 25)] and a few more. Things where it makes sense to add that to a pattern. And some other things like equals and not equals for EmbThread objects and EmbPattern and you can do some direct get_item and set_item on patterns now. So pattern1['name'] = "my pattern" or if pattern1[-1][2] == END

[styloInt]

Hi,

Thanks for getting back to me. I just added {"full_jump": True} and it seems to work now ! I'll tell you if I find a case which does not work.

Also, thanks for your updates, it's amazing ! :)

[tatarize]

Yeah, if full_jump fixes it, I think it's just Wilcom. It's valid in DST to simply stitch at a location as the move command sequence of events is MOVE then STITCH. But, since you didn't stitch at the start location, it certainly didn't anchor the thread and shouldn't actually draw the line. There might be something I'm missing like it being safer to run in full_jump because maybe some machine gets it backwards and stitches and then moves. Though it might just be dumb luck that the stepper motors go faster than the needle goes down, and they actually try to happen at the same time. Which is why there are jump stitches so that it can block the needle bar if it won't make it to the next location before the needle hits.