knitout miss instruction not working as expected

[walpoletim-bjss]

It looks like the miss instruction is not working as expected - it looks like a tuck is being added, but with no needles selected, so the transfer which follows it as no yarn to transfer

Knitout Section

Kniterate Section

Knitout File
ShapingNew1-kniterate1.k.txt

Kniterate File
ShapingNew1-kniterate1.kc.txt

[ixchow]

I believe the "Tu-Tu" pass (kniterate line 1250) is taking carrier 6 out, as per out 6 (knitout line 3290)

The portion of the code in the screenshots appears to be implementing the knitout as written and as visualized:

out 6 ; move carrier 6 back to parking position (kniterate line 1250)
miss + f1 3 ;move carrier 3 to the right of needle f1 (kniterate line 1260)
xfer f1 b1 ;move loop(s) on f1 to b1 (kniterate line 1270)
rack -1
xfer b1 f0 ;move loop(s) on b1 to f0 (kniterate line 1280)

Note, also, that miss + f1 3 actually means "treat carrier 3 as if it had just knit needle f1 to the right" so pass 1260 was only generated because xfer f1 b1 needed to move carrier 3 out of the way. (I believe the backend only performs kickbacks as needed, not eagerly).

With the out 6 behavior clarified, is this working as you had intended or is something still not quite right?

[walpoletim-bjss]

Hi - Ahh - missed that - that makes sense

Let me try and work out what's going on as something is definitely not knitting correctly as needles empty when transfer stitches are happening

Leave it with me and will get back to you

[walpoletim-bjss]

Looks like things are working as expected however on a kniterate machine, the following transfer stitch fails - Not sure why yet - I need to remove the brushes to find out why this transfer is always failing.

Any thoughts on how to resolve wold be great as this stitch type is used lots for increases so would be great to get working (Line 3470)

knitout line that is failing to transfer on a kniterate machine

code line that is failing to transfer

I have re-attached the latest kcode and knitout for this with the relevant lines annotated with the line number from the knitout

ShapeTest1-kniterate.k.txt

ShapeTest1-kniterate.kc.txt

[gabrielle-ohlson]

Hi! @walpoletim-bjss as a fellow kniterate owner and member of the textiles lab who tested the knitout-kniterate backend on my machine, I wanted to provide some input:

the xfer (transfer) operation in the line of code you highlight seems perfectly fine to me. From what I can tell, it isn’t an issue with the knitout operations (i.e. there being something wrong with the code:

xfer f1 b1
rack -1
xfer b1 f0
rack 0

)
but more likely, this is an issue with the values used for the extensions (stitch number, roller advance, speed number). The stitch size of 8 seems pretty large for an xfer—what size yarn are you using? From my experience, it works well to xfer with ~ 1/2 the stitch size that you use and have found works well for knit with your particular yarn.
For reference—I typically use yarn that is either 8/2 ne with x-stitch-number 6 for knit and x-stitch-number 3 for xfer, or yarn that is 16/2 ne with x-stitch number 4 for knit and x-stitch-number 2 for xfer.

Oddly enough, something I and some others have come across is that xfers seem to actually be working more reliably with a somewhat faster speed—x-speed-number 300 has been great (though we still do 100 for split).

Experiment with x-roller-advance too! Getting shaping to work on the kniterate is definitely a bit of a process and involves adjusting these parameters until it starts working consistently on your machine with your yarn.

Lastly, some kniterate-friends and I uncovered some info from their correspondences with the kniterate team—which was the suggestion to only xfer from the front to back bed in the positive direction and from the back to front bed in the negative direction.
In k-code that means only:

>>> Tr-Rr

and

<<< Rl-Tr 

I have tried this out and… I definitely think it is helping (?) I have way less dropped xfers than before but that could also be heavily due to other adjustments. Either way, it’s definitely not hurting so I’ve been enforcing this rule in my fork of the backend. The only downside is that it adds some unnecessary kickbacks/carriage moves for longer distances than necessary (so, a little less efficient) since it’s more of a quick fix than an ironed-out solution. (@ixchow — should we discuss integrating these changes into the main backend?)

I could be wrong, but I’m guessing that you’re seeing the machine xfer from empty needles because it has dropped some loops previously in failed xfer operations. Don’t forget to check for malfunctioning machine parts too, like stuck needles, gunky transfer cams, broken transfer springs, faulty latch hooks, etc!