Extra needles selected on a long piece if you don’t cross the turn marks

[Adrienne200]

First reported as #161 in the desktop ayab-software section of Github, moving it here to the firmware where it belongs. I split off the additional information about the lace carriage to its own issue #40, as it might be a different issue.

The original description and files from #161, slightly edited:
Mispatterning happens when knitting a long narrow single-bed piece for some time without ever crossing the turn marks.

seen on both AYAB and EMSL hardware:
    Preassembled shield bought from Tinkersoup in January 2015. (also later hardware)
    Early production EMSL board
Brother 910
0.8 firmware on Mac, also 0.75 and 0.8 Windows. (Still reproducible in 0.95)
the attached Guild Banner 2.png file. 66 pixels wide and 711 long.
single bed 2-color, center. (doesn’t happen using double-bed, because you pass the turn mark often)
66 needles in work. L33-R33.

You can use actual yarn, or just “air-knit”. If you are air-knitting, it is useful to mark the bed with the two places where most needle-selection happens in this design; L4-R16 (the lettering) and L18-L24 (the needle design). Apart from one obvious area of the design around lines 308-329, there should never be anything selected outside of L4-R16 and L18-L24.

Start knitting as usual at the beginning of the design, note that there are some white-only lines first.
IMPORTANT: to see these bugs do not let the magnet go outside the turn marks, this is a narrow design and there is plenty of space to wait for the beep and turn around without crossing the turn marks on either end.

See it fail: (pictures attached) After some time of knitting without ever passing the turn marks, (somewhere between 100 and 200 rows) it will suddenly start selecting extra needles, usually during the right->left rows only. I’ve included two sets of photos/screenshots for 2 of the 4 or 5 times it happened in this run-through. First batch was at row 158 and for a few rows after that, until I reset it by crossing a turn mark. Row 158 is in the letter “i” of Knitters, so it should be 2-black, one white, 17 black. The green lines in photo IMG_7987_row_158 are correct, the reds should be back at B position.

This will happen again on the next right-left row, and the next. It sometimes stops again on its own, but I found that the most reliable way to cure it is to pass the left turn mark. That zeroes everything out and it restarts its positioning calculations from the beginning. Then it’ll happen again in a while if you don’t cross a turn mark sometimes.

It happened again this run at rows 264, 258, 271 and 488. The second set of sample data is from row 488, in the letter “a” of San Francisco. What usually happens is that it selects an extra copy of the real design, shifted 16 needles to the left. In IMG_8009_row488.JPG, my finger is pointing at the incorrect selection, the other two selected groups are correct.
(end of original description)

Further description. It's doing what I call "shadowing" of the pattern, extra copies of the black squares, the needles that go to D position. We’re only ever getting spurious D needles, never B’s, it's always extra selections not deselections. Or put another way, it never loses pattern that should be there, only gets extra D-positions. It is remembering what it did 16 needles ago, isn't that the previous use of the same byte in the buffer? It should have forgotten that bit and be populated with the current new data.
But note that I never got it to fail simply by knitting fast, I don't think it's a speed issue; maybe something subtle about the timing, but not the actual speed of moving the carriage.
AYAB mispatterning.zip

[Adrienne200]

Adding another example, showing the "shadowing" of the D needles. It's happening on alternate rows, notice the repeating of the reindeer's legs in the area between the motifs that's supposed to be empty. The front of the reindeer is probably being repeated too, we just can't see it because the next motif is solid white. Count the stitches, they're all repeated 16 stitches to the left as seen on the knit side, or to the right as you knit.
From one cycle through the 16 solenoids to the next, it was supposed to engage the solenoid to make to do a B (blue) needle, but instead it left it disengaged from the previous cycle, resulting in a spurious D (white)

[jpcornil-git]

Your issue my be related to #48 (carriage position potentially drifting to the right depending of the encoder patterns after a Right->Left turnaround) => you may want to try the fix proposed within #50 to check if it solves this issue as well.

[Adrienne200]

Is there a build somewhere that I can try? I've never actually checked out the code and built the project myself; maybe now is the time to figure out how to do that.
I'm skeptical that these are related, because this issue's symptom is different, (D-needle selections repeated 16 needles later) and it has been here since the beginning. Whereas I've never seen the one-needle drift described in #50 in earlier releases, nor has anyone else reported it, so I think it must have been introduced since the stable 0.95 release. But I hope I'm wrong, it would be great if this long-standing issue is resolved.

[t0mpr1c3]

Adrienne, am I right in thinking you use a Mac?

…

On Tue, Feb 14, 2023 at 12:39 PM Adrienne200 ***@***.***> wrote: Is there a build somewhere that I can try? I've never actually checked out the code and built the project myself; maybe now is the time to learn how to do that. I'm skeptical that these are related, because this issue's symptom is different, (D-needle selections repeated 16 needles later) and it has been here since the beginning. Whereas I've never seen the one-needle drift described in #50 <#50> in earlier releases, nor has anyone else reported it, so I think it must have been introduced since the stable 0.95 release. But I hope I'm wrong, it would be great if this long-standing issue is resolved. — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM63QUSOG2XJYEV5HVBDKTWXO7NDANCNFSM4W4IRIMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Adrienne200]

Yes, Mac is preferable, but I do have a Windows machine too.

[jpcornil-git]

Note that one single solenoid drive all needles with an offset of 16, e.g. when needle # 50 is addressed, needles at position [18, 34, 50, 66, 82, ...] are affected as well/get the same value.

When everything is fine the 16 active needles under the carriage are aligned wirh the pattern and manipulated by the code but when there is a shift between the effective carriage position and what the code thinks it is, there is an issue, e.g. moving to the right/code one needle ahead, the code will set the tail needle (n) but the carriage is not yet at that position (1 behind) and therefore the needle n-16 will be handled by the carriage as that one is the one under the carriage.

Knitting fast or slow may change the probability to encounter a wrongly handled Right->Left turnaround and passing a turn mark cures the issue as code position is realigned with the carriage position.

Let's see if the patch solves your issue as well :-)

[jpcornil-git]

FWIW, master branch now includes the fix for #48

[Adrienne200]

I can no longer reproduce this issue in build test230626. It was never 100% reproducible, but I have tested it quite thoroughly and no sightings yet. AFAIK nobody ever directly reproduced this issue and fixed it, but it seems likely that #48 and #50 did fix it. So I'm crossing my fingers and closing this long-standing issue.