-
Notifications
You must be signed in to change notification settings - Fork 29
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
Improved vp3 file trim handling #73
base: master
Are you sure you want to change the base?
Conversation
…ich really is a trim)
…rblock changes which are implemented within the colorblocks, using special sequences (END, END-TRIM-JUMP)
I'm a little confused by what's going on here. As far as I understand it, Have you actually seen |
Another issue is that, from what I can tell, once we see |
Yes. The reason that the whole file, as uploaded here, was showing in Ink/Stitch as only a small part, followed by another small part, and then a third part, was that Ink/Stitch tried to interpret "END" as end. And it is. But not end of the colour block, that is decided by the separate byte length of color block. Rather End of this specific stitch block. Look at comparison picture in issue defined in #74. Both Wilcom TrueSizer and Husqvarna/Pfaff Premier and my own machine Husqvarna Topaz 50 accept the file (which was created by TrueSizer). The file consists of a long colorblock, which has its length defined in the file. Within that length is a number of Trims happening. They have different patterns, one is "END", followed by a new stitch in a new group. So END does not mean "end of a colour block" it means "end of this stitch block within this color block" and is at the same time interpreted as some kind of TRIM. It does have Trim followed after it as well. Also, colorchange exist in the file. so patterns are "END" as well as "END-TRIM" as well as... I have actually added some "previous command" and "previous stitch block" as well as "next" for them to the embroidery simulator. So it is very easy to see what a file contains after read by pyembroidery. This is also the reason I added "END" to stitch, what is in the file cannot be interpreted by using trim only, or end only. I have actually created an interpretation in colorblock (on my way to get it to becomes stitchblocks) which works both in read_file and in input, to split the colorblock into stitchblocks only where "END" exist inside file, or "END-TRIM" exist after each other, or "END-TRIM-JUMP" exist after each other. I beleive it will only trigger in some specific files (like vp3). The nice thing with that is that the vp3 file itself is read and interpreted stitch block by stitch block, thus editable or replacable using Ink/Stitch stitch block by stitch block. My aim is to experiment a little more. Currently I can read and understand the files. Now I want to write them. When that is done, we get to know what a Topaz accepts in a vp3 format. Likely, there is some unneeded stuff. But END is not one of those. |
Does an END in the middle of a color block in a VP3 always mean to trim the thread and keep sewing? |
If I am to guess (and until I can produce output and test on a machine I have to guess): I believe not. From the manual I know there is a number of alternatives (but nothing on file format), and nothing really detailed. My only way to experiment so far has been Wilcom TrueSizer:
So I intend to test and see what is the difference END vs END-TRIM vs END-TRIM-JUMP vs JUMP vs TRIM-JUMP. All combinations exist in the file I uploaded, I am just going to intentionally place them and see differences. |
Oh right! I forgot Husqvarna machines can trim the top thread only. I still think we should not use END for this. If we have to introduce a TOP_TRIM command, then so be it. END marks the end of the design in all other formats though. I think your concern is that you want Ink/Stitch to split to a new svg path when it sees the 0x03. We can definitely make that happen even without using END. |
That is simple, it is your project, your decision. Whatever you think is right is the way I will do it. I have been trying to achieve something similar by introducing sequences in read-file and input (END inside color block, END-TRIM inside color block, and END-TRIM-JUMP inside color block). Should work for vp3 and not confuse anything else. Translating husqvarna 0x03 to TOP-TRIM if that is what it is should be easy. I am already preparing for whatever is your decision by breaking out the simulator stitch block and placing besides stitch-plan so all handling of commands are easy to change.
We can, just tell me what you want to call the Husqvarna 0x03, and I will use that instead. I am already assuming an END within a color block is unique for Husqvarna, much better to have it named something unique. |
Great! Go ahead and do what you need to in order to create test files to run on your Husqvarna. Once you know how the file format really works, then we can figure out how to structure the code. |
… longer splitting color blocks, instead adding point blocks inside stitch plan
…tand where I created the miss where the face is broken and appears wide and non connected
…mmand may well have a move
Were you ever able to figure out what was needed to make trimming work on your machine? |
Partly. I did lot of tests together with owner of the separate project for file translations. We found how to make it work to same level as all examples we could get our hands on. All of that he put into his code, and I put it into the code in your library as well. It means that it locks the thread before and after jumps. Even cuts the over-side thread, a feature Husqvarna has. All of that is in the branch on your side. Which also included to be able to read full other format input files and translate them back to husqvarna without losing cuts, and including automatically creating inkscape/inkstitch objects corresponding to all incoming parts from the read format. |
Awesome! I'll give this another review when I get a chance, and maybe we can finally get this merged. 2020 was a hell of a year... |
@MatsIBengtsson with this latest version, do we still need any changes in Ink/Stitch? |
I mean, aside from the obvious need to pull in the latest version of pyembroidery. |
Would be useful to have this fix merged |
@chrisyelf Would you be willing to test this on a machine that reads VP3 files? |
I don't have a machine, sorry :( |
This one starts to solve the pyembroidery side of the changes needed to handle trim in vp3 files. There are at least two issues known which will be part of this work: