Trims do not work in pyembroidery when written from Ink/Stitch

[MatsIBengtsson]

I have a Husqvarna viking Topaz 50 machine, which does trims. When doing designs in inkstitch exported through pyembroidery, my trims does not work as I expect (they do not trim at all).

Free version of Premier (Husqvarna/Pfaff embroidery software), tells me there are no trims in the generated vp3 file. The free version of truesize e4, tells me there are only two trims in the vp3 file (a file with two colors).

Saving to formats like dst or pes, generates the trims as expected.

The issue is also described in Ink/Stitch ( #https://github.com/inkstitch/inkstitch/issues/495). Enclosing a zip file containing a number of files to give details outline cat face p0.0-006.zip

The files are described below, and contain information on the difference when using Premier/trueview or going through pyembroidery.

• The inkscape svg file which contains the design, as done with inkscape and Ink/Stitch (done more or less from scratch, however, the paths are imported from a drawing done in illustrator). That does not seem to have ill effects.
• The vp3 file as created by Ink/Stitch (outline cat face p0.0-006.vp3). It does not manage to convince my embroidery machine to do any trimming, neither does it make Wilcom truesize believe it should.
• A screen dump of Wilcom truesize interpretation of the vp3 file created by Ink/Stitch (Wilcom truesize interpretation of InkStitch vp3 file.PNG). It seem to accurately describe all trims not occuring (color changes are trimmed, but they are always trimmed independent on what commands the vp3 file contains, so likely not due to a trim command in Ink/Stitch vp3 file)
• The dst file created by Ink/Stitch. It convinces Wilcom truesize that there are trim commands defined in the file, just as claimed by Ink/Stitch.
• The vp3 file created by taking the Ink/Stitch dst file into Wilcom truesize, and export as a vp3 file (outline cat face p0.0-006 wilcom from dst.VP3). That vp3 file, according to Wilcom, does contain a number of the wanted trim commands (not all of the ones defined from the beginning in the dst file, but many). It convinces my embroidery machine to trim the thread in many of the wanted places. Side note: Taking the Ink/Stitch vp3 file and saving from Wilcom truesize as vp3 does not produce any visible trims. It does add one extra line, likely a start thread, so something is missing in the vp3 file as saved by Ink/Stitch.
• A wilcom truesize screen dump of its interpretation of the vp3 file Wilcom truesize created using the Ink/Stich dst file (Wilcom truesize interpretation of InkStitch dst file saved as vp3 with lines.png). With lines showing the differences between Wilcom truesize view, and final results on the embroidery machine:
• Wilcom was almost right. There is an extra start thread it expects, which does not show up (encircled in black in the screen dump). Wilcom expects same extra thread when just saving the InkStitch vp3 file using Wilcom truesize. Likely something I have extra in my svg file. Three threads which are not trimmed, although Wilcom expects them to be (shown as three black lines on the screen dump). One up in top left corner of the eye, and two connecting to and from the nose.

[tatarize]

In the writer this should equally correctable.

The line:

        elif flags == TRIM:
            continue

becomes:

        elif flags == TRIM:
            f.write(b'\x80\x03')
            continue

Here's a zip of the output.

cat.zip

The only oddity I found was that it creates an extra stitchblock at the which contains no stitches. But, that seems like an error in the encoder. Since it ends with COLOR_CHANGE, END it oddly doesn't clip the color_change even though there is no more stitching to be done. Seems like the lookahead should have caught that and not bothered.

[tatarize]

On review the oddity that made that extra stitch block is seemingly valid, but it shouldn't have read that extra color_change into the stitches to begin with. I'll fix that. Also, I'm not sure the trims then color change is appropriate between color blocks. It seems like the other files didn't have them before given I took 0x80 0x03 as an end. But, I'll check the file you sent and do what it does.

[tatarize]

This should be generally more correct, reading color changes as between blocks and trims at x80x03. Your file generally said jump, trim, stitch or trim, stitch or color_change. So just writing what it says seems fine. Pretty sure explicit_trim is set to false.

cat_no_extra_block.zip

[MatsIBengtsson]

This should be generally more correct, reading color changes as between blocks and trims at x80x03. Your file generally said jump, trim, stitch or trim, stitch or color_change. So just writing what it says seems fine. Pretty sure explicit_trim is set to false.

cat_no_extra_block.zip

NICE! Yes, it worked perfectly. The threads wilcom said would be there were there. It clearly trimmed after the ends, and cut the overside thread. Underside thread seem uncut, so all as expected.

[tatarize]

Okay, actually sewing it out is good enough for me. It's the gold standard of functionality. Since it literally means it functions. I've pushed the pull request here. Bumped the version to 1.4.3, and updated the version on PyPI. You can go ahead to inkstitch/inkstitch#495 and notify them of how to fix it. It's a bit of an odd way of doing things but I can't do it myself. I'm permabanned there for constructive criticism.

So post to the thread you started there, that it's corrected and they should eventually move the correction into the inkstitch version of pyembroidery.

The only small hanging issue is whether one of the values in the VP3 format that I called stitches - number of (ends) actually has the correct value. It sewed out so it's clearly not important and the file jumps to the next block based on position-in-file indexes so it's only likely to display that info, not actually use it for anything. But, if it's supposed to be number of STITCH commands, without trims, I might need to correct that. But, again it can't matter much since it sews correctly and it didn't before.

[MatsIBengtsson]

So post to the thread you started there, that it's corrected and they should eventually move the correction into the inkstitch version of pyembroidery.

I will, thank you.

The only small hanging issue is whether one of the values in the VP3 format that I called stitches - number of (ends) actually has the correct value. It sewed out so it's clearly not important and the file jumps to the next block based on position-in-file indexes so it's only likely to display that info, not actually use it for anything. But, if it's supposed to be number of STITCH commands, without trims, I might need to correct that. But, again it can't matter much since it sews correctly and it didn't before.

Yes, I believe there is more to it. There should be a way to get bottom thread cut as well (since it can do it at color changes). Also the file you got from me, created by TrueSizer, has two jumps without cuts in it where trims where expected. Your file handles it exactly as expected by TrueSizer. But TrueSizer should not have created them like that.

[tatarize]

Well, I know that as a thing the U01 FDR formatting does have a bottom trim function as well as a top trim. And clearly VP3 has a command space with an entire byte worth of commands.

0x80 goes into command mode.

0x01 does begin long stitch mode. 0x02 ends long stitch mode. 0x03 causes a trim.

If you think there's some other commands that just aren't done yet, I'm pretty sure they'll be 0x80 0x04, etc. I had wwderw try a bunch of cooked up files since his machine specifically said what the commands were, it was the easiest way to figure them out. They were stitch, jump, fast, fast_jump, slow, slow_jump, T1 top trim, t2 bottom trim, stop, needle_changes etc. If there's anything on your machine that'll tell you what a stitch does, I'd be happy to code you up some files that will just invoke unknown commands.

If you're right that there's some other commands that might exist as such, then I'd be happy trying to map them out if there's some kind of workable methodology for doing so.

[tatarize]

Here, I made a copy of a chunk of additional commands that I do not know actually exist. My copy of PREMIER+™2 says they are all corrupt. I could potentially map out VP4 but I am unsure it has anything else that is seemingly helpful.

vp3-commands.zip

[tatarize]

If Wilcom didn't have the trims, and I processed the Wilcom file then I wouldn't have them either. I think VP3 just has really long stitches count as jumps was the best I could figure when I mapped out the format. Unless something says to add in some trim it shouldn't really do it. In theory if the code is corrected for inkstitch, it should be able to add some trims and write those more directly into the vp3 file and hopefully get everything right from the get-go. A lot of embroidery is lossy in terms of saves and conversions to different formats which is why a lot of pyembroidery is written to minimize that.

[MatsIBengtsson]

If Wilcom didn't have the trims, and I processed the Wilcom file then I wouldn't have them either. I think VP3 just has really long stitches count as jumps was the best I could figure when I mapped out the format. Unless something says to add in some trim it shouldn't really do it. In theory if the code is corrected for inkstitch, it should be able to add some trims and write those more directly into the vp3 file and hopefully get everything right from the get-go. A lot of embroidery is lossy in terms of saves and conversions to different formats which is why a lot of pyembroidery is written to minimize that.

True, you did what should be done based on the Wilcom file. I do not have anything telling me what each command does, except the color change. I do have buttons for slow, fast, stop, start, trim, cut,... which all work, but when sewing. Seem reasonable they should be reachable in embroidery as well. I tried to load your file "04", which contained 6 stitches. It indicated moving when I stepped. Did not try to run it.

Premier have a "right click" menu, which, if used on a vp3 file, contains "convert", where it is supposed to add trim commands. I did try it on one file, and the trims looked different (yours do 4 in one place, the ones that it did was 4 in a forth-back pattern. But it did not cut bottom thread.

[MatsIBengtsson]

0x01 does begin long stitch mode. 0x02 ends long stitch mode. 0x03 causes a trim.

Strange. I have seen that in your write code. You write trim as end. And you write jump as jump, stitch, trim. Meaning that the normal written order should be end-jump-trim. Yet, when reading the file, you return it as end-trim-jump. The code in the reader corresponds with that:

if abs(x) > 255 or abs(y) > 255:
    out.trim()
    out.move(x, y)

This feels wrong. The order read should be the same as the order written? Specially if we think of it as stitch blocks. One block ends with a "trim". Then it is complete. Then we jump to a new, and start with a trim. We do not end with a trim, then do a trim in the next block before jumping there?

[tatarize]

I'm more than happy to map out anything else the format may have or correct any errors made.

Wilcom always seemed to cut when you exceeded 255. And so if that's what a really long stitch does that's how a really long stitch actually does. Obviously with a physical machine you can always trump this. Both Premiere and Wilcom E3 take this to mean trimmed. E4 Wilcom actually doesn't tho.

long_stitch.zip

There's some chance that 0x80 0x01 and 0x80 0x02 do something different than I think they do. It might be that they invoke jump mode and those aren't long stitches but jumps and if close enough together could just do a long stitch, but I can't really know and tried my best. If you have better info or ways to get better info then I'd be happy to go with that.

[tatarize]

I must admit that the reader section there does stick out as bad code. First I didn't set a mode. I automatically assume that the 16 bit mode will by definition include only one stitch which I don't think is a sure bet. It's just that with a 8 bit mode you can go 12.7 mm in any direction. And in 16 bit mode you can go 3 meters in any direction, so there's usually just one of those. But, it could just be the case that the meaning 8 bit mode vs 16 bit mode, and the trims beyond the 8 bit limit either happen or don't happen or happen on some specific kind of machine or something.

16bit.zip

I cooked up that file to show the point but both Premier and Wilcom didn't take those as all 16bit jumps but only the first one. The rest got 8 bit interpretation. So apparently that's wrong. Which means I don't have a clue what 0x80 0x02 actually means. 0x80 0x01 seems a shoe in for JUMP. But, then apparently 0x80 0x02 doesn't have a meaning even though I always saw it as an end bit.

[tatarize]

Yeah, pretty consistently in Premier 2™ Embroidery Free, I get really long lines showing up as missing and it doing that 80 01, jump x, jump y, 80 02 pattern. Which is what I copied. So it should be pretty close to correct even if my underlying understanding is wrong. I don't write end as a trim, I trim at the end there. It might actually be correct to remove that line though.

[MatsIBengtsson]

I'm more than happy to map out anything else the format may have or correct any errors made.

Wilcom always seemed to cut when you exceeded 255. And so if that's what a really long stitch does that's how a really long stitch actually does. Obviously with a physical machine you can always trump this. Both Premiere and Wilcom E3 take this to mean trimmed. E4 Wilcom actually doesn't tho.

long_stitch.zip

There's some chance that 0x80 0x01 and 0x80 0x02 do something different than I think they do. It might be that they invoke jump mode and those aren't long stitches but jumps and if close enough together could just do a long stitch, but I can't really know and tried my best. If you have better info or ways to get better info then I'd be happy to go with that.

I do not have any knowledge, only a machine we can test on. But I did read on a discussion forum on trimming and Wilcom, where it was stated that Wilcom were to release a version which did trim vp3 for real in next version. If that was e3 or e4, I do not know. https://sewing.patternreview.com/SewingDiscussions/topic/96844

It was rather your read function towards Ink/Stitch I was thinking of. If you always write in the order Jump-Trim, due to the format, should not the read also return that order to Ink/Stitch, to keep it symmetric?

[MatsIBengtsson]

I cooked up that file to show the point but both Premier and Wilcom didn't take those as all 16bit jumps but only the first one. The rest got 8 bit interpretation. So apparently that's wrong. Which means I don't have a clue what 0x80 0x02 actually means. 0x80 0x01 seems a shoe in for JUMP. But, then apparently 0x80 0x02 doesn't have a meaning even though I always saw it as an end bit.

It could mean Trim? Normally, after Trim-Jump, you would start with Trim in the new place? At least the overt thread is cut...

[MatsIBengtsson]

Yeah, pretty consistently in Premier 2™ Embroidery Free, I get really long lines showing up as missing and it doing that 80 01, jump x, jump y, 80 02 pattern. Which is what I copied. So it should be pretty close to correct even if my underlying understanding is wrong. I don't write end as a trim, I trim at the end there. It might actually be correct to remove that line though.

Yes, your code works, we tested it. I was most thinking of the read not returning the same sequence as the write, that is, not mimicking the order you know you need.

[tatarize]

It was rather your read function towards Ink/Stitch I was thinking of. If you always write in the order Jump-Trim, due to the format, should not the read also return that order to Ink/Stitch, to keep it symmetric?

Ah. That's not really a needed thing. Basically such symmetry is impossible. Not only would it need to exist between VP3->VP3 but DST->VP3 or JEF->VP3 or DSB->XXX or any of the various plausible conversions. It's entirely possible that the file being read is correct and in the order in which the information is given in one file format but that that format will be a disaster in another format. Often between stitch blocks there'll be something a trim, a color change, and some jumps but basically these can happen in a lot of different orders and if the file writer expects one order and gets a different one it will cause problems. And account for every possible order in these basically would result in writers that are massive and account for a bunch of stuff or would break. This is actually the case with Embroidermodder. I realized this was a problem and accounted for it. That's why the code is entirely fed through the encoder. It makes sure to allow the writer format to specify what it accepts, and how it wants things to be, and then the encoder entirely processes every way of writing that stuff and gives it to the writer in exactly the one way it requested.

So there is no difference between Trim-Jump and Jump-Trim per se. It's typical that you trim the thread then jump without the thread. And most of the readers will give the commands in that order. Since literally it would jump, with thread attached, then cut after moving to a new location leaving extra thread. So the order could matter, but I tried for mere consistency there. There's no need for symmetry since when you feed it to the writers, it'll get encoded and it will give you a consistent form. After the trim, it knows it's not sewing anymore, and if it jumps it didn't sew that either, so it treats that stuff as basically the same thing regardless of the order.

I have some pretty considerable formats expertise. And knew this stuff was going to be a problem since I had already run into a lot of problems with such things before, and so pyembroidery was written from the ground up with these issues in mind. And my goal wasn't merely Inkstitch. After all, that project could be a flash in the pan. But, a properly and fully realized IO library for embroidery so anybody could use such things. Even around my first comment on inkstitch, inkstitch/inkstitch#24, was generally that the formats problem is harder and you need to standardize the input or you'll have freakish and very many bugs. And would need to pay attention which format you're coming from and which you're going to.

It's also the case that you can't tell that long-stitch that you called trim+move because that's what it does should be converted back into long-stitch. So many elements of embroidery are lossy that you really can't tell the which should be turned into 0x80 0x03 0x80 0x01 x x y y 0x80 0x02 and which should have been 0x80 0x01 x x y y 0x80 0x02. These sorts of things come up a lot. Like when you perform a stop and you can't tell the stop from a color change, and you can't get that data back. Or when a stitch is too long to be encoded into a format so it's broken into multiple segments, there's no way to know that happened even if you converted back into a format that could encode the original longer version. It's why preservation of information is in the philosophy, because it's actually a harder problem than most would think about.

[tatarize]

It could mean Trim? Normally, after Trim-Jump, you would start with Trim in the new place? At least the overt thread is cut...

It could mean trim. But, nothing seems to treat it that way. I added one a bunch of stitches as such, and it doesn't seem to have any effect. I'm not sure it does anything. I see it consistently by Pfaff's own software to put it after a big jump, so I'll keep doing that but adding it without that context doesn't seem to do anything to anything.

02.zip

[MatsIBengtsson]

Ah. That's not really a needed thing. Basically such symmetry is impossible. Not only would it need to exist between VP3->VP3 but DST->VP3 or JEF->VP3 or DSB->XXX or any of the various plausible conversions. It's entirely possible that the file being read is correct and in the order in which the information is given in one file format but that that format will be a disaster in another format. ...

Ok. I understand that is true. But let me then turn it around to the problem I would like to solve with it. When a VP3 file is read, we know a lot of it. Through the ending trim (end) we know the last stitch in the group. From the jump/trim after that, we know the first stitch in next group. So we know all groups. But when it has passed Ibk/Stitch and is written again as vp3, those groups are gone. It comes out without trims. I would like to be able to detect start and end of each group, so it can be stored.

Even around my first comment on inkstitch, inkstitch/inkstitch#24, was generally that the formats problem is harder and you need to standardize the input or you'll have freakish and very many bugs. And would need to pay attention which format you're coming from and which you're going to.

Ok, but then my thought would be to add some standardized info to preserve more than colorblocks. Stitchblocks or point blocks or whatever is a good name for the groups within the color should be preserved in some way. That must be doable?

[tatarize]

Most all embroidery is cut into color blocks by color_change commands and various stitch_blocks by jump/trim commands. This is true for embroidery not just VP3. When it's written again, it will again divide into these elements and write out correctly into those kinds of groups.

The various stitchblocks tends to be preserved within the color_blocks because they trim and jump and do a bunch of non-stitching commands. There are some methods to iterate elements like this. These tend to take large groups of stitches as a single unit. Sometimes formats will include jump stitches, where their purpose is gauged from context to be a really long stitch by not stitching at a point. Rather than moving around not stitching because the thread is trimmed. But, these tend to be detected and dealt with in a consistent manner.

Typically the demarcation between stitchblocks is a trim. Some formats lack an overt trim, and need a post processing step to interpolate a trim, but these are pretty common and are generally included. The main point between these different areas within the same color of thread are trims, and these are included when they are needed. And the encoder will add them if it believes these to be different blocks.

---

I do notice that the current version doesn't terminate with a END which tends to be in error. It's not a really important thing but should be consistent.

[tatarize]

The stitchblocks are demarcated by either a color_change or some number of jumps and trims. These tend to mean the thread is cut and it's moving to a new area. In rare cases a jump or two is part of a sewn area and these are a bit harder to detect, but they ultimately don't differ much. Within the VP3 format, it only contains a trim for these elements and that can certainly be used to tell the various blocks within the colorblocks (which no other format actually has as a literal block). They are written to the pattern in the order they are given by the format. They have trims within the color block, and consequently those are passed along to the pattern. --- That's data is preserved.

I'm not sure how some trims are special. If the 0x80 0x02 is a jump command, and this is notably not proven, it seems like beyond 12.7 mm it forces a trim. Thus any jump that large gets a trim. If it's less than that amount it gets recorded as a stitch. There's a functional difference and it might be worthwhile to see which it actually is, but whether the trim is caused by being too large of a distance or the trim is an overt command, it's still trimmed.

Don't get me wrong, this information could be encoded. Strictly speaking the commands are supposed to be masked off with the last 8 bits being the actual command. So 255 commands. The upper bits are permitted to encode other things. This is typically only done for color_change/needle_set commands. Where sometimes you might want to tell a Barudan machine to use needle 3, then needle 6, then needle 2 and doing this with different commands for each needle would be pointless.

It could likewise flag things based on their origin. So you could say this trim is interpolated by having too long of a jumps, or this trim is interpolated because this format has 3 commands in a row, or this trim is overtly real and existed in the actual file. But, I cannot for the life of me figure out any distinction between those. I might be able to determine why the machine would cut at that point, and I didn't pass that information along, but it'll still rebuild correctly when you convert from VP3 to VP3. If there's a really big jump that would force a trim in the middle of a colorblock, it would get rebuilt with an overt trim in addition to the large jump rather than just the large jump. But, that wouldn't change anything when you sew out the embroidery.

[tatarize]

VP3 to the best of my knowledge is the only format that makes color blocks an thing within the format. In most they are just a conceptual understanding of something to call all those commands between a color_changes. Likewise the stitch_blocks are also conceptual but they are trimmed/jumped blocks of data. Even in VP3 there's no real demarcation for them other than a trim. And it would be entirely permitted to have no trim and a large jump or a trim with no jump at all.

The blocks as such, are entirely conceptual but should be built again on the flipside. But, also, if somebody modified something about the pattern, they might need to get built again slightly differently. So it's not simply a matter of saving the data the same way you loaded it. If there was a trim-less really long jump somewhere that would trigger a trim, processing it with pyembroidery would make that an explicit trim when it was previously an implicit trim, but the overall functionality wouldn't change at all.

This sort of thing is needed for things like converting from DST, you have trims produced by series of jumps, that will on a DST reading machine force a trim. But, on a different machine might not cause a trim, and it would simply add long connected threads between them. But, reading the implicit DST trims and writing the explicit trims on those formats which actually use them, would keep the functionality of the file, what it actually wanted done to be the same.

If the file currently does TRIM, then a long jump, it'll get called TRIM TRIM JUMP. But, if you wrote it again it would get called TRIM JUMP. Now there's something to the idea of having the reader not record 2 trims like that. Because Explicit-TRIM, Implicit-TRIM JUMP, is kinda of odd. I could certainly suppress the implied trim if it follows an explicit trim. That's be perfectly reasonable.

[MatsIBengtsson]

The blocks as such, are entirely conceptual but should be built again on the flipside. But, also, if somebody modified something about the pattern, they might need to get built again slightly differently. So it's not simply a matter of saving the data the same way you loaded it. If there was a trim-less really long jump somewhere that would trigger a trim, processing it with pyembroidery would make that an explicit trim when it was previously an implicit trim, but the overall functionality wouldn't change at all.

This sort of thing is needed for things like converting from DST, you have trims produced by series of jumps, that will on a DST reading machine force a trim. But, on a different machine might not cause a trim, and it would simply add long connected threads between them. But, reading the implicit DST trims and writing the explicit trims on those formats which actually use them, would keep the functionality of the file, what it actually wanted done to be the same.

Ok, got it. But is there no way to say "block" in such a way that we can differ a block with an explicit trim at end (the END command) and a block with an explicit JUMP-TRIM at_start (the jump-TRIM). Then we know that there are two blocks, and they should be kept as separate blocks inside inkstitch, one to end with trim, and one to start with jump trim.

If the file currently does TRIM, then a long jump, it'll get called TRIM TRIM JUMP. But, if you wrote it again it would get called TRIM JUMP. Now there's something to the idea of having the reader not record 2 trims like that. Because Explicit-TRIM, Implicit-TRIM JUMP, is kinda of odd. I could certainly suppress the implied trim if it follows an explicit trim. That's be perfectly reasonable.

It is worse, we do actually change behavior as it is now. I am more looking to record the explicit trim as explicit in block 1, and the Jump-implicit trim as that in block 2. As it is now, the explicit trim info (the END) disappears. As long as an implicit trim is translated to an explicit trim in the writer, and coming before the jump it used to follow, and then an explicit JUMP is translated to a JUMP followed by implicit TRIM we get the TRIM behavior remaining if it was there to start with.

But this comes from a series of reinterpretations. Removing one thing (END), recording the other thing in the wrong order (TRIM), translating the wrong order last part to the first thing (END), and then adding the implicit trim at the end of the JUMP. Not differing between a file which started without explicit TRIM (not having an END before the JUMP). That file would not trim. Yet, that very same file will now get trimmed due to an END being inserted where there was no End before.

[tatarize]

Then we know that there are two blocks, and they should be kept as separate blocks inside inkstitch, one to end with trim, and one to start with jump trim.

But the end result of both of those is you're talking about a single strand of thread, from starting sewing to trimming at the end. There's literally no distinction with regard to why the thread was cut. If I translate that to a different format, I need a trim where it trims so it trims where it trims. "A difference which makes no difference is no difference at all."

I am more looking to record the explicit trim as explicit in block 1, and the Jump-implicit trim as that in block 2. As it is now, the explicit trim info (the END) disappears.

You get the exact same stitching output regardless why the trim exists. Whether the machine would cut there because it sent a trim command or whether it would because the jump attempted is longer than it can manage between needle penetrations there's no distinction in the end results. The END is supposed to simply be at the end of a read. It means generally that it read to the end of the pattern and didn't have an error or anything. The command would be used to demarcate different patterns in the same file as VP3 can do. But, currently a trim is a trim.

As long as an implicit trim is translated to an explicit trim in the writer, and coming before the jump it used to follow, and then an explicit JUMP is translated to a JUMP followed by implicit TRIM we get the TRIM behavior remaining if it was there to start with.

It doesn't matter which order the trims or jumps come in the end result is that it trimmed and moved to another location, so it will just be encoded in a consistent manner.

But this comes from a series of reinterpretations. Removing one thing (END), recording the other thing in the wrong order (TRIM), translating the wrong order last part to the first thing (END),

The end should be in the file, I'm going to add it back in short order. It's a fluke it's missing. The trims are in the correct order. There might be a need to check whether we explicitly trimmed and not adding an implicit trim if we did. The END commands belong at the end of the pattern. The commands for TRIM were confused with them but they are typically fine. They seemed to be there at the end of the last block so they were read as ENDs.

All the files I studied whether they ended with a trim before or not, got a TRIM command at the end. I suppose I could remove the line that treats END command as a TRIM command. That would be perfectly reasonable and more consistent.

As is, I plan on:

1) Adding an END command to the read for VP3. 2) Not adding an implicit trim for a long jump if there was already an explicit trim. 3) Not writing a TRIM command when I see an END command.

I think I'm missing your line of reasoning here. There doesn't seem to be any meaningful distinction between a trim that happens because of a real trim command added or a trim that happens because the machine was specifically told to trim. The end result is the same and it will sew the same thing.

Also, I'm not sure what you think END commands do but they just happen at the end of a pattern. They don't do much of anything in reality. I debated omitting them, but figured they'd be useful for things like VP3 which could contain multiple patterns in the same file.

Not differing between a file which started without explicit TRIM (not having an END before the JUMP). That file would not trim. Yet, that very same file will now get trimmed due to an END being inserted where there was no End before.

If you END it won't jump. The pattern should be over. There's no difference between a file without an explicit trim that trims because it jumps and a file that trims because it was told to trim. They both trimmed. Every stitch will remain the same. There are some formats where you could tell it to trim a dozen times each time it jumps to a new stitchblock, and for some machines it'll trigger that little knife thing the dozen times, but the stitches themselves won't differ at all. So this doesn't tend to get counted as important. The encoder would, consequently, drop all but 1 of those TRIM commands.

[MatsIBengtsson]

But the end result of both of those is you're talking about a single strand of thread, from starting sewing to trimming at the end. There's literally no distinction with regard to why the thread was cut. If I translate that to a different format, I need a trim where it trims so it trims where it trims. "A difference which makes no difference is no difference at all."

If it is not trimmed before cut, then it does not sit securely in the first block. This is what "END" does in vp3. If it is not properly secured after the cut, then it does not sit securely in the second block. Doing or not doing that is a difference.

You get the exact same stitching output regardless why the trim exists. Whether the machine would cut there because it sent a trim command or whether it would because the jump attempted is longer than it can manage between needle penetrations there's no distinction in the end results. The END is supposed to simply be at the end of a read. It means generally that it read to the end of the pattern and didn't have an error or anything. The command would be used to demarcate different patterns in the same file as VP3 can do. But, currently a trim is a trim.

Not true. If there is a TRIM with a cut in the file, inserted through an arbitrary action, not coming from a trim with a cut being there before, then it differs from that cut not being performed. Very visibly. That is how your sequence currently acts.

As long as an implicit trim is translated to an explicit trim in the writer, and coming before the jump it used to follow, and then an explicit JUMP is translated to a JUMP followed by implicit TRIM we get the TRIM behavior remaining if it was there to start with.

Yes, but that is not the case currently. Currently, you generate a cut where none was, because you translate the TRIM which was inserted after the JUMP to a trim inserted before the jump, and then translates that to an end. After that, you translate the JUMP to a JUMP followed by TRIM.

It doesn't matter which order the trims or jumps come in the end result is that it trimmed and moved to another location, so it will just be encoded in a consistent manner.

It would be true if the behaviour was the same, but it is false since the behavior is not the same. You add an END command that was not there, by interpreting your own trim after jump as an end before jump.

The end should be in the file, I'm going to add it back in short order. It's a fluke it's missing. The trims are in the correct order. There might be a need to check whether we explicitly trimmed and not adding an implicit trim if we did. The END commands belong at the end of the pattern. The commands for TRIM were confused with them but they are typically fine. They seemed to be there at the end of the last block so they were read as ENDs.

The END should be there if it was there. But not if it was not. Currently, if it was, you do not add it. But also, it it was not, since yuo read your own trim added after the jump as a trim before the jump, and translates that trim as an end when writing, you add one where there was none.

All the files I studied whether they ended with a trim before or not, got a TRIM command at the end. I suppose I could remove the line that treats END command as a TRIM command. That would be perfectly reasonable and more consistent.

I would say the opposite. The only thing that cuts is the END. If there was an END, see to it is there. If it was not, do neither add it, nor interpret your own trim as an END.

As is, I plan on:

1. Adding an END command to the read for VP3.
2. Not adding an implicit trim for a long jump if there was already an explicit trim.
3. Not writing a TRIM command when I see an END command.

1 and 2 is perfect. 3 is wrong, please see previous comments about being able to handle files also not having an END command, without writing them as having one (and thus cutting).

I think I'm missing your line of reasoning here. There doesn't seem to be any meaningful distinction between a trim that happens because of a real trim command added or a trim that happens because the machine was specifically told to trim. The end result is the same and it will sew the same thing.

Yes, we are trying to describe something we see differently. But just take a file not having an END (thus not cutting). Feed it to your reader, your interpreter, and write it again, and you will see you now have a cutting en written in the file.

Also, I'm not sure what you think END commands do but they just happen at the end of a pattern. They don't do much of anything in reality. I debated omitting them, but figured they'd be useful for things like VP3 which could contain multiple patterns in the same file.

Wrong. This is the reason we discuss from different views. If the END command is not there, the thread is not cut on the machine before doing the jump-trim.

[tatarize]

Also, I'm not sure what you think END commands do but they just happen at the end of a pattern. They don't do much of anything in reality. I debated omitting them, but figured they'd be useful for things like VP3 which could contain multiple patterns in the same file.

Wrong. This is the reason we discuss from different views. If the END command is not there, the thread is not cut on the machine before doing the jump-trim.

I can't really be wrong about that. I wrote the program, I know the fundamental meaning of the END command. It's basically only ever a flag that says the reading or writing is over. Most VP3 files tend to end with a TRIM and it might be correct to make sure the VP3s it writes end with a TRIM command too. But, that's not what END does. The cut bit is what TRIM does. So if it should cut at the end of the file, then it should have TRIM at the before the END. END is not supposed to cut, it's a hold over that I wrote it as a TRIM that is in error, hence #3 there, namely removing it.

[tatarize]

If it is not trimmed before cut, then it does not sit securely in the first block. This is what "END" does in vp3. If it is not properly secured after the cut, then it does not sit securely in the second block. Doing or not doing that is a difference.

The blocks are largely conceptual. If the command ends up in the first block or second block or is before or after a TRIM command does not actually change anything. If you divide things into blocks at the TRIM command and do JUMP then TRIM, you get the same thing as TRIM then JUMP, even though the JUMP ends up in a different block. They don't change anything. You can even add a TRIM before or after the COLOR_CHANGE and it'll literally end up in a different block in the file and again, won't change anything.

[MatsIBengtsson]

Wrong. This is the reason we discuss from different views. If the END command is not there, the thread is not cut on the machine before doing the jump-trim.

I can't really be wrong about that. I wrote the program, I know the fundamental meaning of the END command. It's basically only ever a flag that says the reading or writing is over. Most VP3 files tend to end with a TRIM and it might be correct to make sure the VP3s it writes end with a TRIM command too. But, that's not what END does. The cut bit is what TRIM does. So if it should cut at the end of the file, then it should have TRIM at the before the END. END is not supposed to cut, it's a hold over that I wrote it as a TRIM that is in error, hence #3 there, namely removing it.

Good, we now know where and why we differ in meaning. Look at the pictures I have included in top of this issue, also referred on Ink/Stitch. Looking at the picture, you will see two long "jump stitches". All others will be trimmed after each "stitch block". Now check the data in the file generating it. You will find that the file is missing "END" for the two places where the machine does not trim the thread. The END command causes the cut:

Originally posted by @MatsIBengtsson in https://github.com/inkstitch/inkstitch/issues/516#issuecomment-519061634

[MatsIBengtsson]

If it is not trimmed before cut, then it does not sit securely in the first block. This is what "END" does in vp3. If it is not properly secured after the cut, then it does not sit securely in the second block. Doing or not doing that is a difference.

The blocks are largely conceptual. If the command ends up in the first block or second block or is before or after a TRIM command does not actually change anything. If you divide things into blocks at the TRIM command and do JUMP then TRIM, you get the same thing as TRIM then JUMP, even though the JUMP ends up in a different block. They don't change anything. You can even add a TRIM before or after the COLOR_CHANGE and it'll literally end up in a different block in the file and again, won't change anything.

Blocks may be conceptual. But cutting thread is not conceptual, it is factual. Where the Jump is not preceded by END, cut does not happen.

[tatarize]

I checked. Again, firstly END is a command that should be after the pattern. You're talking about TRIM. I checked with EmbroidePy. Those extra long stitches qualify as STITCH.

"","310","STITCH","-147.0","-67.0" "","311","STITCH","89.0","-86.0" 310: F9 FD 80 01 00 EC FF ED 80 02 04 05

and

"","1279","STITCH","-63.0","101.0" "","1280","STITCH","147.0","56.0" 1279: FC 03 80 01 00 D2 FF D3 80 02 06 FC

You will note that the WILCOM e3, also leaves in long stitches there. I cribbed their methodology when I mapped out VP3.

            if abs(x) > 255 or abs(y) > 255:
                out.trim()
                out.move(x, y)
            else:
                out.stitch(x, y)

Now, the hex at 310 says x = 236, y = -45 which is below that threshold. And so pyembroidery interprets that as a stitch.

The reason the two stitches you cited are not trimmed and jumped is because they fall below that given threshold and consequently are treated the way the program suggested they should be treated when they fall below that threshold. Namely they should be treated as an extra long stitch.

Unlike the other notes, this might be certifiable error. Since Premier clearly has those elements cut. It raises a slight mapping question. Is it merely those stitches beyond 127 that get treated cut in Premier? Does this accurately translate on the embroidery machine? Are all 0x80 0x01 16-bit stitches actually cut jump stitches?

You can just replace the section I cited above with out.trim(), out.move(x,y) rather than checking for the distance. If these are all cut-jump-stitches that would be the correct rendering of them. I'll check how Premier renders them, according to length or if they are all merely cut.

[MatsIBengtsson]

I checked. Again, firstly END is a command that should be after the pattern. You're talking about TRIM. I checked with EmbroidePy. Those extra long stitches qualify as STITCH.

Good, this is the other part of misunderstanding we have due to terminology, so we are getting to understand each other better. I talk about the 80x03 occurring before the 80x03 you expected as end of color block. In your code it was referred to as "END" when we started on this improvement. Thus I have called it END. At that time you had 80x02 called TRIM. We can call it whatever you like, as long as we have one name for 80x02, and one for 80x03. Please suggest names so we keep a consistent discussion, and not one name for both. My machine does not cut when it trims, and does not trim when it cuts. They are two different operations.

"","310","STITCH","-147.0","-67.0" "","311","STITCH","89.0","-86.0" 310: F9 FD 80 01 00 EC FF ED 80 02 04 05 ... You will note that the WILCOM e3, also leaves in long stitches there. I cribbed their methodology when I mapped out VP3.

            if abs(x) > 255 or abs(y) > 255:
                out.trim()
                out.move(x, y)
            else:
                out.stitch(x, y)

Yes, this is how Wilcom does it, that is why the file is called "from Wilcom". Your code refer here to a trim, which previously in your file had 80x02, and did not to my knowledge result in any cut of thread. Looking at the line, that line seem to still say 80x02. Meaning that what previously you mapped to a trim, is still mapped to what at that time was called a trim and does not cut the thread.

The reason the two stitches you cited are not trimmed and jumped is because they fall below that given threshold and consequently are treated the way the program suggested they should be treated when they fall below that threshold. Namely they should be treated as an extra long stitch.

They are already coded as 80x02, which at the point of time we started this discussion was called trim. For all what I know, they may still be doing a trim, yet not a cut before trimming (which on my machine is totally different from cut. Trim secures the thread. Cut cuts the thread. I can do many trims without thread being cut at all. So to continue this discussion, you need to decide what we call 80x03 and 80x02, and not one name for both. It may well be that for a jump longer than 255, it both cuts and trims.

Unlike the other notes, this might be certifiable error. Since Premier clearly has those elements cut. It raises a slight mapping question. Is it merely those stitches beyond 127 that get treated cut in Premier? Does this accurately translate on the embroidery machine? Are all 0x80 0x01 16-bit stitches actually cut jump stitches?

I do not know, but I have the machine, and if you give me a file, I can run it. Yet, please keep in mind: trim and cut are two different things, operating independent of each other. Do not test them as one and the same. That is not how the machine handle them, and I believe it is part of our misunderstandings. Only embroidery behavior I know is from that single machine.

You can just replace the section I cited above with out.trim(), out.move(x,y) rather than checking for the distance. If these are all cut-jump-stitches that would be the correct rendering of them. I'll check how Premier renders them, according to length or if they are all merely cut.

I am quite certain that is exactly what your code used to do (when you called 80x02 trim). If you look in the zip file in the start of this issue, you will notice there is a file from ink/stitch (thus your pyembroidery). Generated with direct translations of trims in the svg file (also included) to what you called trims in the vp3 file. The may trim. But they do not cut. I have run them, and described what happens when doing that.

[tatarize]

vp3-cut-len.zip

So mapping out the lengths at which the various programs cut.

• W3 doesn't cut at 254, but will at 255. This is true for either direction.

• W4 will cut at 1821, 1821 but will not at 1820,1820. However, single directionally, it will not cut at 2574 but will cut at 2575. Keep in mind these lines are the same distance as 2574 * sqrt(2) ~= 1820.

• Premier will not cut at 450,0 and 318,318 but will cut at 451,0 or 319,319.

Generally machines are dumb and will usually not calculate the euclidean distance in order to figure out whether they will cut or not. So I am not sure about this stuff. W3 seemed pretty reasonable but W4 removed those limits and I think just has a software line limit at that distance. Same, apparently for Premier. However, the cat image line was x = 236, y = -45 which is only 240.25. So Premier likely has a different criteria in addition to raw distance, or a different metric than I assumed.

I don't know whether these lines are genuinely cut or not. The data seems kinda ambiguous. But, it's an easy thing to properly interpret them as TRIM and JUMP rather than STITCH. (no END here, only END after the pattern).

[tatarize]

As for the ambiguity of terminology. This is because it's actually ambiguous. 0x80 0x03 is pretty clearly through this discussion and looking at the file a TRIM command. It means that that the thread is cut and the the next stitches are part of another stitchblock. However, I do not actually know what either 0x80 0x01 or 0x80 0x02 actually do. It's clear they are commands. But, it's not clear what effect they physically have on the machine. So I call them 0x80 0x01 rather than JUMP because I don't know that that command actually is JUMP. JUMP means that the machine is stitching away and for this stitch it blocks the needle bar preventing it from sewing. This usually means it's a move command. Sometimes the JUMP is moving without any thread connected. Sometimes the JUMP is merely part of a really long stitch where the stepper motors would not have enough time to reach the destination so they toss in a JUMP to give it double the time. A lot of machines at speed couldn't slow down as such but they could certainly block the needle bar and move again.

Now, it is clear from context that 0x80 0x01 is followed by two 16-bit numbers rather than 2 8-bit numbers. This allows encoding distances from -327 mm to +327 mm in either x or y direction. And the manufacterer's software and others always write the command 0x80 0x02 after this command. However, this command does not alter the number of bits being accepted. It is merely that 0x80 0x01 is followed by 2-16 bit numbers. Then is typically followed by 0x80 0x01 but cannot be followed by more than 1 set of 16 bit numbers.

So this means: 0x80 0x01 --- Is followed by 2 16 bit numbers. Is typically rendered as stitches in programs. 0x80 0x02 --- has only been seen following a 0x80 0x01 command and has unknown meaning. 0x80 0x03 --- this was previously only seen at the end of the last block, but you provided conclusive examples of it occurring inside blocks and triggering a TRIM in the files themselves.

So I say 0x80 0x01 and 0x80 0x02 because I'm referring to those commands, whatever they may be. I don't fully understand what they mean, so when I refer to those commands I use that. Since they don't necessarily have a name. And sometimes software, even by the manufacturer doesn't give clear understanding either. So the access to a physical machine is highly important to figure them out, rather than just best guessing them.

Yes, those long stitches are treated as stitches in pyembroidery. However, that file when loaded by Wilcom either E3 or E4 has those lines as stitches too. And Premier has them as having been cut. However, I don't know which is correct, the exact metric Premier is using, or whether that is actually performed on the physical machine or not. If sewing that file does not cut those threads, and those long threads are physically actually there, then it is the case that the pyembroidery is correct to render them like that. It would mean that that is accurate. Is it? I dunno.

[tatarize]

vp3-size-cuts.zip

To see the oddity of the Premier arbitrary cutting I've attached 1600 files from [-200,200)X and [-200,200)Y by 10s. You can see that Premier says it cuts a line at 0,90 but doesn't cut a line at 0,-90. That stuff has got to be a software bug or some other kind of inconsistency. So mapping it out fully to figure out where Premier would take that to mean cut and where it wouldn't seems like it would be a fool's errand.

Maybe you have better software that corrects that beyond my copy of "Premier+™ 2 Embroidery Free". Or would really want to waste some time and effort sewing some of those out. In any event, I can't tell if trims are really forced or where. And without that, I cannot know if the lines in the cat embroidery are being left in there in error, or are actually there and should be left for the sake of accuracy. If I say they aren't there, then they should be cut. Because if you left them in there, maybe somebody would correct them by adding trims and get their desired result.

[tatarize]

" The may trim. But they do not cut. I have run them, and described what happens when doing that." --- I must have missed this. What distinction are you making here. It seems to me there is 1 device on a some embroidery machines that triggers a hook, that sometimes comes down and slices the thread, before moving on to a new location. I call that even TRIM. What are you calling a TRIM and what about it is distinct from a "cut"?

[MatsIBengtsson]

" The may trim. But they do not cut. I have run them, and described what happens when doing that." --- I must have missed this. What distinction are you making here. It seems to me there is 1 device on a some embroidery machines that triggers a hook, that sometimes comes down and slices the thread, before moving on to a new location. I call that even TRIM. What are you calling a TRIM and what about it is distinct from a "cut"?

Starting from the end, since it might clear some fog I unintentionally created. I should have talked about "fixing" and "cutting", which is the proper translation. Meaning:

• Fix: The thread is fixed before whatever happens next. The normal thing to do when you start sewing, or end sewing. Separate command on my machine so I do not have to backstitch. That is what I have guessed the 0x02 (previously called "TRIM") after 0x01 (previously called "JUMP") does. After a cut (previously called "END") I can see the JUMP, then the top thread being dragged, pulled down, and likely fastened.
• cut: Thread is cut. In embroidery, so far we only seem to be able to cut the top thread. This can when sewing be done without fixing before or after.

[MatsIBengtsson]

Yes, those long stitches are treated as stitches in pyembroidery. However, that file when loaded by Wilcom either E3 or E4 has those lines as stitches too. And Premier has them as having been cut. However, I don't know which is correct, the exact metric Premier is using, or whether that is actually performed on the physical machine or not. If sewing that file does not cut those threads, and those long threads are physically actually there, then it is the case that the pyembroidery is correct to render them like that. It would mean that that is accurate. Is it? I dunno.

Yes, Wilcom is better than Premier at forecasting what my machine will do. It will sew them as long threads, not cut them. Yet, what I tried to explain was that the vp3 file, not called "from Wilcom" was created by Ink/Stitch, from an SVG file having a trim defined. So it inserted what it believed was a TRIM command at that time (0x02). It might have "Fixed" but it did not "cut" (see previous answer on the terms). I do not know which.

[MatsIBengtsson]

To see the oddity of the Premier arbitrary cutting I've attached 1600 files from [-200,200)X and [-200,200)Y by 10s. You can see that Premier says it cuts a line at 0,90 but doesn't cut a line at 0,-90. That stuff has got to be a software bug or some other kind of inconsistency. So mapping it out fully to figure out where Premier would take that to mean cut and where it wouldn't seems like it would be a fool's errand.

Maybe you have better software that corrects that beyond my copy of "Premier+™ 2 Embroidery Free". Or would really want to waste some time and effort sewing some of those out. In any event, I can't tell if trims are really forced or where. And without that, I cannot know if the lines in the cat embroidery are being left in there in error, or are actually there and should be left for the sake of accuracy. If I say they aren't there, then they should be cut. Because if you left them in there, maybe somebody would correct them by adding trims and get their desired result.

I can sew some if it helps. If you could tell me a suitable one that should be doing a jump so long that you definitely code it as jump, and it is passed the 255 limit, then it would be good to know if it cuts by itself or not?

[MatsIBengtsson]

To see the oddity of the Premier arbitrary cutting I've attached 1600 files from [-200,200)X and [-200,200)Y by 10s. You can see that Premier says it cuts a line at 0,90 but doesn't cut a line at 0,-90. That stuff has got to be a software bug or some other kind of inconsistency. So mapping it out fully to figure out where Premier would take that to mean cut and where it wouldn't seems like it would be a fool's errand.

I do have a file from Premier (using convert in the free version). It looks to me they use the same cut (0x03). However, two very funny things:

• The reason I looked at it was that it was "fixing" in a different way. When Wilcom or you "fix" at the 0x03, the machine does 4 stitches in a row in same position without moving at all. This one does a zigzag fixing at least at some points. Could it be they write different stuff to the header, affecting the machine?
• This is a file where Wilcom explicitly coded 0x01 followed by 0x02. But you code, at least the copy I took, removes that (at the 0x01 it says "too short" and instead does a stitch. at the 0x02 it says "nah, we never do 0x02 unless decided at 0x01. Meaning that when writing it later again, the 0x01 plus 0x02 are removed. Without knowing why Wilcom had it there? outline cat face p0.0-006 inkstitch from svg18_c.zip

[tatarize]

What you call "fix" is typically called a tie-on. Sometimes when it's done prior to a cut it's called a tie-off. Generally the effect is the same. It keeps the thread where you put it. Pyembroidery has tie-ons built in. They aren't usually used since Inkstitch had their own and used that. I made it an option so more types of them could be used. Where it's reasonable to use different forms since those exist. I haven't had enough demand to implement more than three small lines going back over the last stitch, but there's others like small triangle and several stitches in the same place.

I see no difference in your description between "cut" and TRIM. Or any distinction being made here.

---

Inkstitch previously had no Trim. If it tried to add one it would merely skip and add nothing. This is pretty standard for formats that cannot interpret a given command. 0x02 is a command that appears after 0x01 command and the 2 16 bit values. I am still unsure of it's actual functionality.

---

I can certainly cook up some files to see if the machine actually cuts and maybe narrow down as to where it cuts. And then it could narrow that down nicer.

---

It is true that I don't do 0x80 0x01 x x y y 0x80 0x02 if the amount we are moving to small. This might be in error. It might be the case that this is a jump and should be treated as a jump but, I don't know and see no clear indication which way it should go.

I'll see about cooking up some files that will settle the unknown elements.

[tatarize]

cutcheck.zip

These cut check files have different distances of 0x80 0x01 xx yy 0x80 0x02 sequences and should be able to tell if there is a distance on the machine that will end up auto cutting. It goes up to 47.5mm.

        for x in range(0, 500, 25):
            file1 = "cutcheck_" + str(x) + ".vp3"
            pattern = EmbPattern()
            pattern += (0, 0)
            pattern.stitch(-30, -30)
            pattern.stitch(-30, 30)
            pattern.stitch(30, 30)
            pattern.stitch(30, -30)
            pattern.add_stitch_absolute(STITCH | ALTERNATIVE, x, 0)
            pattern.stitch(30, 30)
            pattern.stitch(30, -30)
            pattern.stitch(-30, -30)
            pattern.stitch(-30, 30)
            write_vp3(pattern, file1)

This uses the latest version that I put up earlier today. That is flagged to force ALTERNATIVE to make a longform stitch. Which I needed to force the generation of these odd elements.

[tatarize]

command2.zip

This archive only has one file. The file draws the little diamond things, but then jumps over by 50 and does the 80 02 command outside of any context, then jumps over another 50 and does a diamond on the other side. The idea being if 80 02 does something it should be possible to see what that thing might be.

[tatarize]

cut-no-2.zip

Similar to cut check it does the jumps with 80 01 but then does not end with 80 02. In theory if it does something it might be a command of exclusion. Where what it does is reset to normal. Omitting it here would permit checking.

[MatsIBengtsson]

What you call "fix" is typically called a tie-on. Sometimes when it's done prior to a cut it's called a tie-off. Generally the effect is the same. It keeps the thread where you put it. Pyembroidery has tie-ons built in. They aren't usually used since Inkstitch had their own and used that. I made it an option so more types of them could be used. Where it's reasonable to use different forms since those exist. I haven't had enough demand to implement more than three small lines going back over the last stitch, but there's others like small triangle and several stitches in the same place.

I see no difference in your description between "cut" and TRIM. Or any distinction being made here.

Ok, good, thx. So cut and trim is same thing, and has nothing to do with jump or tie-on/tie-off. Then, in the correct language, My interest is to preserve tie-off and tie-on. I suspect 0x01-0x02 does a tie-on. So I am worried when that information disappears on purpose from the file.

Inkstitch previously had no Trim. If it tried to add one it would merely skip and add nothing. This is pretty standard for formats that cannot interpret a given command. 0x02 is a command that appears after 0x01 command and the 2 16 bit values. I am still unsure of it's actual functionality.

So am I, but it does not cut, at least not after shorter distances (many centimeters).

I can certainly cook up some files to see if the machine actually cuts and maybe narrow down as to where it cuts. And then it could narrow that down nicer.

Good, I will test and report back.

It is true that I don't do 0x80 0x01 x x y y 0x80 0x02 if the amount we are moving to small. This might be in error. It might be the case that this is a jump and should be treated as a jump but, I don't know and see no clear indication which way it should go.

Same here, but I see Wilcom always adding it, Premier sometimes adding it, and you always removing it. That makes me worried.

I'll see about cooking up some files that will settle the unknown elements.

[MatsIBengtsson]

cutcheck.zip

These cut check files have different distances of 0x80 0x01 xx yy 0x80 0x02 sequences and should be able to tell if there is a distance on the machine that will end up auto cutting. It goes up to 47.5mm.

        for x in range(0, 500, 25):
            file1 = "cutcheck_" + str(x) + ".vp3"
            pattern = EmbPattern()
            pattern += (0, 0)
            pattern.stitch(-30, -30)
            pattern.stitch(-30, 30)
            pattern.stitch(30, 30)
            pattern.stitch(30, -30)
            pattern.add_stitch_absolute(STITCH | ALTERNATIVE, x, 0)
            pattern.stitch(30, 30)
            pattern.stitch(30, -30)
            pattern.stitch(-30, -30)
            pattern.stitch(-30, 30)
            write_vp3(pattern, file1)

This uses the latest version that I put up earlier today. That is flagged to force ALTERNATIVE to make a longform stitch. Which I needed to force the generation of these odd elements.

I took the 475 file and used. A diamond, a long thread, another diamond, and going back with "thread in needle" but still cut. No cut except when going back at end.

[MatsIBengtsson]

command2.zip

This archive only has one file. The file draws the little diamond things, but then jumps over by 50 and does the 80 02 command outside of any context, then jumps over another 50 and does a diamond on the other side. The idea being if 80 02 does something it should be possible to see what that thing might be.

Did not fully see or hear anything. It did do a diamond, moved a small distance, did another diamond, tied-off and cut. The start had likely no tie-on, first part was lose. This is common in InkStitch files. You see that Wilcom says there is a starting thread which InkStitch does not mention. It is, but it is not tied-on, so it disappears.

[MatsIBengtsson]

cut-no-2.zip

Similar to cut check it does the jumps with 80 01 but then does not end with 80 02. In theory if it does something it might be a command of exclusion. Where what it does is reset to normal. Omitting it here would permit checking.

Could you do these more like your diamond, a cut and a jump with and without 0x02? then I could see if tie-on tie-off differs.

[tatarize]

I took the 475 file and used. A diamond, a long thread, another diamond, and going back with "thread in needle" but still cut. No cut except when going back at end.

So no cut. Well, that actually means 0x80 0x01 literally just does a stitch. It's just a method for a very long stitch. Basically anything would have cut after moving 4.75 cm. That means the command I have is actually wrong in that it ever provides a cut. Wilcom E4 is right. Just drag the thread at the end.

It didn't cut when it rehomed at the end? I specifically removed the 0x80 0x03 TRIM command being added when END was called. It is technically correct. But, if it's dragging the uncut thread at the end, I see why it always tended to add that. Which is why I thought of it like an end, though the file doesn't actually have an END.

Did not fully see or hear anything. It did do a diamond, moved a small distance, did another diamond, tied-off and cut. The start had likely no tie-on, first part was lose. This is common in InkStitch files. You see that Wilcom says there is a starting thread which InkStitch does not mention. It is, but it is not tied-on, so it disappears.

Was there a stitch half way between the diamonds? The code for that file specifically says diamond, move 5mm, apply command 0x80 0x02 move 5mm more then sew another diamond. If it didn't apply the stitch at the center that's actually significant. Move to location, but do not stitch, is a JUMP command.

Could you do these more like your diamond, a cut and a jump with and without 0x02? then I could see if tie-on tie-off differs.

Not too hard to code up. I'll start on some of the next wave of checks. I'll code up them with the trim and then long_form stitch (80 01) with and without the terminal (80 01) command.

This is 80 03 80 01 xx xx 00 00 80 02 - So trim, long_form_stitch, (80 02) command.

trim01xy.zip

This is 80 03 80 01 xx xx 00 00 - So trim, long_form_stitch, no ending 80 02 command. To see if it has some meaning in a trimmed context.

trim01xy_no_ending_02.zip

[tatarize]

diamond02.zip

This one will do a diamond. Then move 10mm with an 80 02 then draw an entire 5mm diamond all with 80 02s and then go back to the middle point, make another 10mm move and sew a normal diamond on the other side. If 80 02 suppressed the stitching between those two diamonds in the previous test file I sent you, it should in theory suppress the entire center diamond. It might move in the shape, but never actually stitch anything. Or it might stitch that stuff since I don't really know.

---

Thus far the info I'm getting is 80 02 is long form stitch and cannot create an implicit trim. The code that suggests a long distance there trims, is in error. And I should restore the TRIM for the END command since it only otherwise trims between color blocks and that doesn't apply to the final color block and needs the explicit trim there.