EmbroidePy/pyembroidery

I have an little problem with the embroidery quality from InkStich ...

Closed this issue · 2 comments

Maybe I am really wrong here. But first I like your work you guys done. Sorry my English is not fine and a bit rusted.
I made 744 in Issues but one of the guys wrote me in a pm I should try here my asking ;-)
So to history of the file X3mmY0,2mm45Grad.svg.txt to see in Inkscape download and delete the .txt at the end of the file.
I made a line from X0 Y0 to X+3 than Y+0,2 than X-3 Y+0,2 [mm] and so on = a nice I for embroidery I made the sew up from hand. Do that in InkStitch and all looks fine when exporting JEF or other ... I like re-importing the files in other layer xD.

But than when I change the angel of the I to 45° it start again ... Stitch coordinates don't come at the right position. They are far away.

Same happened if I import any other JEF (or other Format) in InkStitch and save it in same or other sewing format - the points starts moving around ... don't think that is what someone will have. Think @kaalleen can explain my Problem much better.

X3mmY0,2mm45Grad

What you're seeing is snap-to-grid. It is a requirement due to the nature of embroidery files. All file formats for embroidery are ultimately in discrete integer units. In most file formats this relative coordinates in 0.1mm units. In pyembroidery these are set to the native resolution of most embroidery machines which have a 1/10th mm stepping distance. All positions it can possibly use are a integer number of 1/10th mm units. When you put these lines 0.2mm apart, the actual files themselves will write that as 2 units. This is good in the case of the straight line.

The instructions it will use will be:

  • Go here
  • move 2 units down (0.2 mm)
  • Move 30 units to the right. (3mm)
  • Move 2 units down. (0.2mm)
  • Move 30 units to the left. (3mm)
  • ...

That's is perfect. It is hitting an exact number of units from one point to the next.


However, if you rotate that by 45 degrees. We now need to move it, 2 units down and to the left. Which will be 1.414 down and 1.414 right. But, these are not discrete units. So pyembroidery will keep track of where it expects to be in fractional units. And where it actually is in discrete units. And put the needle penetration as close as possible to the desired location.

  • Go here.
  • Move 2 units at a 45 degree angle. 1.414 units left and 1.414 units down.
    • We cannot write 1.414 so we write that as 1 left, 1 down. With 0.414 left and 0.414 down remaining.
  • Move 30 units at a 45 degree angle. 21.213 units right and 21.213 units down.
    • We cannot write 21.213 so we add to our location. We want to go 21.213 units right but we have 0.414 units left left over from the last operation. So 21.214 goes to 20.8 which rounds to 21 giving us a 0.2 remainder to the left. And we want 21.213 units down and have 0.414 units down remaining from last time. So we end up going 21.627 which rounds to 22. With 0.373 units up remaining.

You can see that as an angle to get the best positions, we ended up going (+1, -1), (-20, -22), because it needs to snap to the position. This is the minimum possible error within the criteria.

@kaalleen This is unfixable.

Because of the nature of embroidery files pyembroidery's effective position can be off by up half of 0.1mm This usually does not matter. Thread is about 3mm wide for standard weight. Needles are about that wide as well. The embroidery machines themselves run on stepper motors which can step a very specific distance very quickly but these are locked to particular units and embroidery uses the 0.1mm stepper motors. You cannot step a partial amount of this distance. You very likely will not be able to see this sewn and there is no way to correct this for embroidery files because they must use discrete units.

I understand you guys and must cry a bit xD - 2D Positioning control system versus Computerized Numerical Control system.

My world is still modern three - five or more axis CNC ... and not that ugly limited to a grid jumping system ... tested it on the MC500E moved the nice jef in an 45° angel and got the same result you write above.

I am not happy about that limitation but I can follow your nice explain - so thanks for helping me.

That Issues can be marked as closed but ... maybe time help me ;-)