DST Tajima Butterfly JX550L-W inkstitch/inkstitch#1296

[tatarize]

@Jsulung @kaalleen @lexelby @datchou

Can one of the users of the Butterfly embroidery machine try: recent-pyembroidery.zip

There have been a couple bug fixes with regard to the DST headers since the split with inkstitch.

LA:Untitled        
ST:   1469
CO:  0
+X: 1371
-X: 1371
+Y: 1428
-Y: 1428
AX:+    0
AY:+    0
MX:+    0
AY:+    0
PD:******
 

Is given in the really old version but this should correctly be:

LA:Untitled        
ST:   1469
CO:  0
+X:  137
-X:  137
+Y:  143
-Y:  143
AX:-   31
AY:+  139
MX:+    0
MY:+    0
PD:******


If it's actually using that header information it might be declaring a corruption based on that and refusing the file. The header does have a couple errors that some parsings might object to.

---

The other main difference is the switch of the terminal being F3 1A rather than merely F3.

Here's a copy of the file with the F3 1A termination:

[recent-pyembroider1ay.zip](https://github.com/EmbroidePy/pyembroidery/files/7189274/recent-pyembroider1

Here's a copy of the main stitches done in inkstitch with the header done in hatch. If this fails then the header isn't the problem but something with the body, if it doesn't fail then it's the faulty header and might be some issues in the older version of pyembroidery that inkstitch uses. hatchheader-inkstitchbody.zip ay.zip)

Those set of tests should narrow down the problem to faulty old header in inkstitch/pyembroidery or F3 1A termination or figuring out if the problem is in the header or body of the file.

[kaalleen]

An Ink/Stitch user tested the files on a tajima embroidery machine. This is his result:

I did download both those files and on both of them the embroidery machine gave an error

[tatarize]

@kaalleen The ButterFly JX550 and TEJT-C1501 are different machines, so this could be an entirely separate set of problems.

In this case (TEJT-C1501) the pedesign loaded dst and the original rope design2 differ in a couple ways. The stitch count (pe-designed added some), the AX, AY values in the header (these denote the position of the last stitch). The PE design added some divisions of longer stitches. It starts out with 3 jump stitches to 0,0 at the start, and jumps to the max values hence the different AX and AY values at the end (frame eject). The inkstitch version has about 30 stitches that go 0,0 which are effectively double stitches. This could cause a panic in some firmware perhaps.

It's effectively 20 questions at that point. The files aren't standardizes so the firmware is likely panicking at a fairly routine feature or event whereas the vast majority of other embroidery machines will process that data fine.

1. It could be that it expects the extension to be DST rather than dst.
2. I would try removing small stitches supposing that the 0,0 stitches could be responsible.
3. Then I might suspect the initial position jumps to start that actually travel. I don't know why this would confuse a machine, but it would be reasonable check.
4. Then I would try adding in the frame-eject at the end (the reason to jump to corner at the end of execution is to allow people to remove the hoop and get the head out of the way. It probably shouldn't result in firmware panic.)

I would try the doing numbers 1 and 2. For the other ones it might be more involved and might require a bit more direct interaction, and a lot less telephone spanning over 6 month, to get around my permaban (#1).

Discord (link to offtopic on my laser control software) would probably work, if somebody with the hardware shows up and can pass fail things in fairly fast order, I could probably check a bunch of stuff. https://discord.gg/RWQqk7YQVv