Export PES has no trims.

[tatarize]

inkstitch/inkstitch#689

@ursus-kirk -- To the best of my knowledge there are no trims within the PES format.

        elif data == TRIM:
            continue

If you have an example of the format performing such an operation independent of a long jump, I would like to see such a file.

[ursus-kirk]

I have found that using the Attach Commands to Selected Objects > Stop (pausing machine) always first trims the thread. Which is what I wanted.

[tatarize]

The PES format doesn't technically even have a stop. It just does that with a color change to the same color it's already on. That could be expanded to mean trim, but I can't be sure all machines would take it to have that meaning.

Does your machine stop there when you add stops? Like does it stop and trim, and you hit the button and it moves on, or does just trim and keeps moving? And does it have a setting to interpret the file to mean that on the machine itself? I know a lot of them will interpret multiple jumps as a trim requirement and other things, is that set as a setting directly on your machine?

[ursus-kirk]

When I set a 'stop (pause machine) after this object' in inktstitch then Save as PES, transfer it to my machine. my machine stops, trims, lifts the foot and waits until next command (generally lower foot and start stitching again). No extra settings needed.

On Fri, May 29, 2020 at 1:39 AM tatarize notifications@github.com wrote:

The PES format doesn't technically even have a stop. It just does that with a color change to the same color it's already on. That could be expanded to mean trim, but I can't be sure all machines would take it to have that meaning.

Does your machine stop there when you add stops? Like does it stop and trim, and you hit the button and it moves on, or does just trim and keeps moving? And does it have a setting to interpret the file to mean that on the machine itself? I know a lot of them will interpret multiple jumps as a trim requirement and other things, is that set as a setting directly on your machine?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EmbroidePy/pyembroidery/issues/91#issuecomment-635673235, or unsubscribe https://github.com/notifications/unsubscribe-auth/APPZ3QJLCZOMYIV76SU6DGLRT3Y4DANCNFSM4NATNFGA .

[wwderw]

Is there also a color change involved after that stop after this object? I've never really known even Brother software to offer a true stop function in their consumer software. There is a pseudo stop function with regard to applique, but nothing for say if wanted to do puff or needed to do other changes that would need a stop (color matching upper/lower thread for instance, for freestanding work).

Now, at least with the PR machines, you could add in a "reserve stop", I would doubt that it would be for a single needle though as in order to use that function at the machine it would have to be at a color change and on single needles, a color change already indicates a "stop".

[tatarize]

The fake stop is merely a colorchange to the same color. The colors in any file with a pec block, (pec, pes, phb, phc) are listed and so if you switch from one color to the same color it counts as a stop in several programs. This apparently also triggers his trim functionality on the machine. Which would make sense as color change procedures. But, if there's not actually anything datawise in the file there's not really anything datawise to fix.

I guess I could interpolate a trims and stops as a pseudostop, and just make sure to avoid stringing multiple ones together. So if you say you wanted to trim here and the jump away, that'll get a pseudostop. But, if you want to stop here. That'll also get a pseudostop. Then if you wanted to trim, then stop, then jump away, I'd want to make sure that'd get 1 pseduostop rather than two.

Though a good amount of this seems kinda like it would require some pre-processor interpolation which does trickle up to the older version run in inkstitch but not as easily. There's still some pretty basic corrections that haven't made it in yet. But, I'll check if there's some easy way to do that. But, certainly at the low level of the writers since there's no trim command there's nothing that writes a trim command.

[ajquick]

I generate PES files with TRIM commands in Embird. These files are imported into the Python library without problems and the TRIM commands are recognized. When I export the same file from the Python library as a PES file, the TRIM commands are removed. If I export as a CSV, I see the TRIM commands are there.

Perhaps it is not conforming to any PES standard, but TRIM seems to be understood by, in the very least, some Brother embroidery machines. Embird seems to export as PES0090 in the header.

Here is an example file of two lines with a jump and trim in between.

Line.pes

[tatarize]

I'm pretty sure this is actually right. I'll do a binary analysis of the file but I do think it's flagging a trim there. There was a trim flag code but I don't think I ever saw it and thus assumed it was a rumor. The PES header doesn't matter much since it's in the stitches which is part of the PEC block. I'm pretty sure all the machines check if the first digits are PES and then lookup the jumpto code and jump to that in that file and read the PEC code never touching the pes block.

[yaxu]

Hi, I'm just wondering if there's any updates or tips on how to send trims to a Brother embroidery machine.

[tatarize]

The code here should actually encode a jump/trim each jump but the start jumps. In theory these are 0x20 encoded as a long form command.

def pec_encode(pattern, f):
    color_two = True
    jumping = True
    init = True
    stitches = pattern.stitches
    xx = 0
    yy = 0
    for stitch in stitches:
        x = stitch[0]
        y = stitch[1]
        data = stitch[2] & COMMAND_MASK
        dx = int(round(x - xx))
        dy = int(round(y - yy))
        xx += dx
        yy += dy
        if data == STITCH:
            if jumping:
                if dx != 0 and dy != 0:
                    write_stitch(f, 0, 0)
                jumping = False
            write_stitch(f, dx, dy)
        elif data == JUMP:
            jumping = True
            if init:
                write_jump(f, dx, dy)
            else:
                write_trimjump(f, dx, dy)
        elif data == COLOR_CHANGE:
            if jumping:
                write_stitch(f, 0, 0)
                jumping = False
            f.write(b"\xfe\xb0")
            if color_two:
                f.write(b"\x02")
            else:
                f.write(b"\x01")
            color_two = not color_two
        elif data == STOP:
            pass  # These will already be processed into duplicate colors.
        elif data == TRIM:
            pass
        elif data == END:
            f.write(b"\xff")
            break
        init = False

Line.pes does seem to include a trim-jump there. Though pyembroidery would also contain a trim-jump as well.

A0 F4 A0 4B is the code there.

172: Stitch 0 -12 173: Stitch 0 -12 174: Trim 244 75 175: Stitch 0 0 176: Stitch 0 0

In binary this is: 00 74 00 74 A0 F4 A0 4B 00 00 00 00

The high bit 0x80 and the jump bit 0x20 are combined to make 0xA0. Which is effectively saying. Do a jump/trim x=F4 and a jump/trim y=4B. But, codewise this isn't actually different than we'd tend to produce anyway.

I'm not entirely sure if this should be fully controllable. The commands are jump/trim rather than a standalone trim command. Though I guess a long-form trim that travels 0,0 would maybe work but it might need to be confirmed with hardware.