Jef trim on machines.

[tatarize]

Inkstitch/Inkstitch#374 suggests there is a failure to trim for some Jef outputs. The comparison chart for the 400E and 500E says there are "Programmable Jump Thread Trimming". ( http://www.sewvacdirect.com/content/Comparison%20Chart%20400E%20vs%20500E.pdf )

Auto says anything longer than 3mm is trimmed. But, manual, suggests there is a read trim points from the program is an option.

12. Cutting Command. When this option is turned on, the machine trim the threads at the trim code if the imported stitch data file contains a trim command (cutting command).

If these points exist, pyembroidery does not acknowledge them. It assumes all the jumps are going to be cutting for reading, and treats them as such. Has 0x80 0x02 as move/jump and 0x80 0x01 as color change. In effect it treats all jef commands in the Easy method. Cutting after all color changes.

The embroideryware EW3lines.jef. Tries to do 0x80 0x02 (0,0) 0x80 0x02 (x,y) at the start then between the different stitch block does. 0x80 0x01 (0,0) 0x80 0x02 (0,0) 0x80 0x02 (x,y). This formatting is not seen in Janome's software which does these elements as `0x80 0x01 0x80 0x02 (x y).

If that is an example of a trim command. Then a trim command is equal to a jump command of zero distance.

@jameskolme could you test this theory? Or have any way to produce a file with trims and another without from the same hopefully Janome source.

The relevant file is 3chevptrims. 3chevptrims has 0x80 0x02 without any distance as trims. The other files are 3chevj which is a janome produced file, 3chevw which is wilcom produced, and 3chevp which is pyembroidery produced (without attempting any trim coding).

jef trims.zip

If it works, the changes needed to fix are quite minimal:

• Add an option to switch between these modes for reading and writing in jef.
• When manual mode: Write a zero distance move as a trim for saving.
• Read a zero distance move as a trim for loading.

Assuming my speculation there is correct, which would need to be proven.

[jameskolme]

Tested all files and no trimming at line ends happened. Machine is set to accept only programmed trims and auto generate program end trim, well that works, but it is not the issue here. 3chevptrims.jef machine says file is corrupted and should be removed.

I can make file without trims, maybe EW3lines.jef both versions.

[jameskolme]

I try later again, not possible to turn trim off for EW3lines.jef anymore. Basically trims are handled so poorly, trim is generated by swapping line types at certain point, no switch to turn trim on or off.

But something I did discover, EW3lines.jef might be really bad example. If I turn off automated trims at program end / color change, there are no trims at all. So program is coded with multiple program ends to fool machine to auto trim.

[jameskolme]

After reading this: https://edutechwiki.unige.ch/en/Embroidery_format_JEF

It should work as described:

Has 0x80 0x02 as move/jump and 0x80 0x01 as color change. In effect it treats all jef commands in the Easy method. Cutting after all color changes.

Are those commands separated by , (X,Y)? Every time trim is applied to program, machine states file is corrupt.

Unfortunately I can't export proper .jef files for comparison. Today EW wants to trim every line, but here goes next best thing that I managed to make. Couple files made using simple janome editor, machine performs as expected and trims are between shapes. janome editor trim.zip

[tatarize]

I wrote the technical documentation there (even updated because of this). The commands all validly use X Y for distances, the belief is that 80 02 with 00 00 might be a trim. And consequently might be safe to use. I'll still hold out some hope, because I messed up the file I made. I forgot jefs require an exact count and that I precalculated, but when I added TRIM I didn't add 2 to the count. That failure makes the file declared corrupt. This file should work.

3chv-trim.zip

The EW3lines is, in fact, working by color changing to the same color repeatedly (end usually means 0x80 0x10 which terminates the command sequence). It's using the color changes to trigger the trim. Given that I took my theory from that file. Zero distance jumps might not work as such, because it's using color changes and has no examples of a trim.

Using color changes might have some other side effects, but generally should work. Though that's already a valid way of making a file and would require no change to pyembroidery.

I checked the commands in the JEF+ files you attached, the commands seem pretty similar but nothing stands out. Though it's a bit of a different format.

[jameskolme]

Ok, excellent work.

Tested new file with color change / program end disabled and enabled, just to be sure and it works perfectly. Jumps get trimmed when program end trim is disabled, like it should.

[tatarize]

Hm. So even without the color change trims (the file had no color changes) it still invoked the trim. Did you have the jump trims off? Just making sure all the Ts are crossed and is dotted. So manual mode, only thing that should trim is a trim command and it still did some trimming?

If so, Fantastic!

That means my very educated guess that a trim is a jump to no distance was right. And a zero distance jump is so innocuous that it can just be added to the jef output and parsing of the inputs, without any harm. Which is part of the reason I guessed that that might be what it was doing, you should be able to slip a zero distance jump into most anything without ill effects and backwards and forwards compatible.

[jameskolme]

Yes, machine was manual mode, accepting only trim commands from program and both jumps worked. Program end trim worked only when program end trim was enabled, not sure is this programmed or is this automated, but it still did what was expected.

[tatarize]

Yeah, the code there only added a little trim command before the pretty tiny jump. So that's the command. Updating the code now. Updated the documentation. I'll test it a bit and then send it to pypi.

https://github.com/EmbroidePy/pyembroidery/commit/2d1eafa3a9f94e87494dc95ea2a8866b6d072880

That should be the extent of the needed changes.

You'll likely have to point Lex to that change to have him update the old version of pyembroidery he has to get that functionality. But, the files shouldn't conflict. It's simply adding the 0x80 0x02 0x00 0x00 for the trim and making sure to update the count so the machines don't reject the files as corrupt. And reading the trims in on the JefReader side. Pyembroidery has really good bones.

Sorry about the delay, I only semi-rarely check inkstitch for various format problems and fix them. Might be a bit easier if I weren't permabanned. And I've been mired in cracking the speedcodes for this K40 laser cutter, turns out they were linearly related to the period between the pulses sent to the stepper motor. But, glad I could help, and glader yet, that others will likely get nice access to jef trims. But, as for many of these fixes you'll likely just have to tell Lex it was solved and point him to it here.

[jameskolme]

Yes, I do that, thanks.