Increases always using miss increase

[walpoletim-bjss]

I have tried to change the increases to use kickback or split increase as miss increases are causing a kniterate machine to drop stitches when transferring the stitch for the increase.

Whatever I do, the knitout that is produces comes out the same, with a miss increase as below

Are split or kickback increases implemented yet, of not is this on the radar to implement

Thanks

[xionluhnis]

There are two settings for modulating the type of increase:

Those are the Increase and Direction settings in the image above. By default it is supposed to do a kickback increase.

Increases exactly on the side of a flat structure are a bit restricted because you cannot cast on the leftmost or rightmost needle and then knit on it directly (because the corresponding pick up stitch would undo itself when you try to knit it).

What to try:

• change the direction and/or increase settings
• make the increase happen inside of the structure, not the sides

Increases inside of the structure are typically safe, unless you stack them in which case you don't want to split an already splitted stitch because of tension issues. You can also not do gauge switching with splits (e.g. go from half-gauge to full-gauge using split). For such scenario, you need to use kickbacks (or miss).

[xionluhnis]

Attempted to do something matching you on a flat rectangle that I skewed the upper section so as to get increases. rect-increase.json.txt

If I put a seam annotation on the left side and increase the default seam weight (it's too low for this case by default), then I get all the increases on the left side.

By default, with kickback, I get mostly what you observed

By changing the direction, we get what you probably wanted:

By using split without changing the direction, it works directly:

By changing the direction with split, it also works (I used the semi-implicit racking visualization to check that the transfers don't hide that we're missing a stitch at the location we split from):

And if you don't use any seam, then by default with my rectangle, all seams happen in the center:

For which any increase will work directly:

Summary

The default "Outward" direction corresponds to doing the special action of an increase on the stitch that is "ahead" in the step. For flat structures that increase on the side, this unfortunately corresponds to doing the special action on the stitch that is the leftmost or rightmost, and this ends up being unsafe, so it gets replaced by a miss action.

Using the "Inward" direction corresponds to doing the special action on the stitch that happens first in the step. For side increases, this means that the leftmost or rightmost stitch gets transferred to the side to create space for the increase action, and we get what you probably expected.

I think it's possible that I made the split case automatically pick one out of the two (outward, inward) if one is clearly better. It's possible I did not do that for the kickback increase too. But at least this should clarify the problem.

Beware: if you try splits, make sure you try all the variants because, if I remember correctly, out of the four (split out, split in, rsplit out, rsplit in), one of them did not work in practice. I don't know if it's split out or split in that failed. I think the r-split (reverse direction split) worked for both directions. Though I've never tried splits on the border of a flat sheet of fabric.

[walpoletim-bjss]

Amazing

Thank you so much - Let me play with the settings and see if I can achieve increases in the middle of each section - for now I am trying to knit this small 'test' structure to see if I can shape jumpers correctly on a kniterate machine.

This is the file that is causing the increases on the left side as discussed running in inverse mode as previously discussed.

As you can see we end up doing increases on the left section and right section at the top (for the top of the jumper).

Here is the file in question sketch (39).json.txt

[walpoletim-bjss]

Hi - I have tried changing the increase setting for the file I attached , running it in inverse mode but still I can’t get anything other than miss increases at the edge

any thoughts?

Thanks

[walpoletim-bjss]

I have loaded a simple shape, as you had, and looked at your knitout visualiser,

This is what I get (which looks like the increase is happening in the middle)

However, when I view this in the knitout visualiser, you see that its working differently - there is an extra row being added at the left of the garment (with a knitout miss command) which, on a kniterate machine causes the stitch to drop.

Am I completely missing something here?

[xionluhnis]

I see.

There is is a visual interpretation difference. But for both images, I seem to see a proper split in the center. So your main issue is with what happens on the left.

[walpoletim-bjss]

Yes, we are finding that the, in the knitout below, 2074 works correctly, however 2076 always fails to transfer - the stitch is ALWAYS dropped when transferring from the back bed to the front..

Kniterate machines done have pressers (Maybe this is relevant).

The same happens every time this kind of transfer happens so where this is happening at the edges of the knit, we always have dropped stitches.

Any thoughts on this would be amazing. I need to take the brushes off, and try and see why the stitch is not being transferred..

e

[xionluhnis]

Does removing the miss change anything? Since the first transfer works, I guess that this is an issue of tension.

A few ideas:

• removing the miss
• reducing the use of rollers during that transfer
• splitting the transfers into two (one for every other needle)
• trying in half gauge

That later point is likely relevant. Most of the samples I've tested are in half gauge. They all rely on the CSE algorithm (collapse, shift, expand). If you're knitting in full gauge, i think the code switches to another algorithm (RS for rotate and shift) which enforces looser slack constraints. Though you're dealing with a single needle racking here so that shouldn't really matter...

The presser shouldn't be relevant in this case. The rollers might be since I don't use them but you likely do.

[walpoletim-bjss]

Some great points and I have not run on 1/2 gauge so let me try some testing over the weekend and get back to you

agreed it’s probably the tension. I have already removed the roll and increased stitch size

[walpoletim-bjss]

So over the weekend I have played around a lot, and knitted a lot, and have confirmed that central increases (using Split stitches) work perfectly.

I have also got to the bottom of the issue with the left side of this knit which is increasing in size.

On a kniterate machine, whatever the tension or rollers, or stitch size, if you are knitting on a single (front) bed, and try and transfer a stitch one left (as you do when increasing), then the transfer from front to back works (rack 0), however, when the transfer from back to front happens (rack -1) then, due to the position of the yarn in the rollers etc, the yarn never pushes back far enough over the transfer spring and so the transfer fails to completely correctly and the stitch is dropped.

To solve this, I have had to transfer the 2 left stitches to the rear (instead of just the 1 left stitch), and then complete the rest of the transfer as before. with the second stitch on the rear bed, the left stitch correctly transfers back to the front.

Any thoughts on this - Maybe it also fails on other machine, or is do you think this is kniterate specific?

With regards to adding this to the knitout - Is this worth having a fix for or will it cause issues on other machines?

Thanks

Tim

[xionluhnis]

This still seems like a tension issue that could potentially be fixed in different ways. Though moving both at the same time seems to help, I wonder why there is no specific issue with the additional left stitch you are moving now. It's likely due to the tension being different if you stretch inside of the fabric or at the end.

That being said, the CSE algorithm collapses all stitches to the other bed, so I would definitely try to knit in half-gauge with the CSE algorithm for transfers (by default). If half-gauge works thanks to CSE, then one simple option would be for me to let the CSE algorithm be used in full gauge (in some "expert mode", or accepting that this will fail with some machines).

Could you upload here both working and failing knitout files? If I have time, I will try to knit both on our machine this week. That would confirm whether this is a machine-specific problem, or a more general issue.

If it's a general problem, then it's a big nail that is critical to know about. If it ends up being machine specific, then it's still important to know, but it would be dealt at a different level of a full pipeline (and knowing that is important for devising that pipeline).

BTW, thanks for doing all those tests! I don't have access to a Kniterate machine (yet).

[walpoletim-bjss]

Hi

I will upload the files here later in a bit.

for reference the program setting for this knitout is already set for 1/2 gauge using CSE mode, split stitch inward Setting for increases.

When the split stitches are added in the middle of the knit, the stitches are collapsed onto the back bed and that all works perfectly

it’s just the left increase stitches that don’t work and dot seem to collapse like the central split stitches .

Is there potentially an issue with the increases that are happening at the left where it’s not using the cse mode?

more than happy to carry out test for you on our kniterate machine.

thanks for all your support and help on this - would be amazing to be get this fully working and knitting on a kniterate machine as I know this would interest lots of owners.

thanks once again

Tim

thanks for all your

[walpoletim-bjss]

Hi - Here is the knit sketching json file , and I have included the knitout output from the program running on CSE, 1/2 Guage, split stitches for increase (inward). This knitout file has the first 5 left side increases updated to work on a kniterate machine, and the rest not updated - I have commented in the knitout file the changes.

I released I had to do 2 things to resolve the issue for the increases on the left - The second d stitch on its own did not solve the dropped stitch issue.

1. move a second stitch to the rear on the left
2. do a knit on the left stitch before transferring it back to the front.

Without both 1 and 2, the stitch was dropped...

You should be able to run the knit on your machine and see what happens to the first 5 increases, and then the rest of the knit. for us, the first 5 would not drop, and then the remainder would drop..

Knitout file - first 4 increase rows updated for kniterate Knitout-First-5-Increases-Workng-Kniteratare.k.txt

knit sketching input file (json) KnitSketching.Increase.Inverse.json.txt

Commented Updates

[walpoletim-bjss]

Morning Morning

Any thoughts on the above so we can start doing further testing - Is it for instance a potential bug that the increaes on the left done run under use shaping with movement of all the stitches to the rear for shaping?

Thanks

Tim

[xionluhnis]

Unfortunately, I haven't had time to try this on our machine. But I checked the knitout code by compiling that with the software from Shima, and here are the current outcomes:

Your .k file

If I use your .k file, then I get a few warnings during compilation, although they wouldn't induce what you are seeing:

• three overlapped loop transfers (those are unfortunately cases that we're well aware happen from time to time, and we have no way to remove them because of the current transfer implementation with CSE)
• one split stitch that is unsafe

That .k file is for full gauge, not half-gauge, so I wonder if you tried the half gauge version too.

Your first action pass with continuous needles (don't check the cast-on, since that's done with an interlock pattern):

x-stitch-number 5 ;action
knit + f0 1
knit + f1 1
knit + f2 1
knit + f3 1
knit + f4 1
knit + f5 1
knit + f6 1
knit + f7 1
knit + f8 1
knit + f9 1
knit + f10 1
knit + f11 1

In half-gauge (the $meta=X comments are for linking to the stitch graph in the UI, but it's not actually used):

x-stitch-number 6 ;action
knit + f0 1 ;$meta=0
knit + f2 1 ;$meta=1
knit + f4 1 ;$meta=2
knit + f6 1 ;$meta=3
knit + f8 1 ;$meta=4
knit + f10 1 ;$meta=5
knit + f12 1 ;$meta=6
knit + f14 1 ;$meta=7
knit + f16 1 ;$meta=8
knit + f18 1 ;$meta=9
knit + f20 1 ;$meta=10
knit + f22 1 ;$meta=11

As for the sampling, what value did you use?

I tried to replicate your picture with sampling scale 1mm/1px, but I end up with twice as much data in the knitout file (although it looks very similar).

Here are the two versions I tried (both with 1mm/1px, split increase inward):

Full-gauge

Knitout-First-5-Increases-Workng-Kniteratare-self-fullgauge.k.txt

No error at all.

Half-gauge

Knitout-First-5-Increases-Workng-Kniteratare-self.k.txt

No error either.

Comments

Is it for instance a potential bug that the increaes on the left done run under use shaping with movement of all the stitches to the rear for shaping?

Different transfer algorithms work with different methods for moving stitches around. The one we use by default in half-gauge knitting is called Collapse-Shift-Expand and comes from this paper: https://la.disneyresearch.com/publication/machine-knitting-compiler/

It has a few issues for shaping:

• notably, it can merge stitches before having them reach their target needle, in which case we get overlapped loop transfers
• it only works for half-gauge knitting on the SWG091N2 from Shima, because slider transfers prevent any carrier movement, and all the carrier movements in that algorithm are assumed to be done implicitly (which does not prevent carrier movements while sliders are pending)

But it has a few advantages:

1. It can do complex rotations of a stitch cycle very efficiently
2. It enforces pretty strong slack constraints so the yarn is typically under good tension during the whole transfer procedure

The other algorithm we use implicitly for full-gauge knitting is an in-house version. That's why I wanted you to try to use half-gauge results, because then it goes back to the CSE algorithm which has been tested a lot more.

Now, to the real point: the transfers you see on the left are part of the shaping, but not the shaping itself. The local irregular structure is the stitch increase that happens with the split stitch. What you have on its left is just stitches moving around to create some space for the split stitch to have a location to put its secondary loop at.

At least on the Shima machine, we basically assume that you can move stitches around without too many constraints. The main constraint that we apply is a slack constraint that defines how far the connected stitches are on the bed (because they are in tension with the current stitch, so if you try to move one too far from the two others, you are going to either fail the transfer, or break the yarn eventually).

The moves we see in the example where it fails with your machine don't appear to have any slack violation. So I'm assuming that it is something related to the machine differences between Kniterate and Shima.

Question

I assume that you're adding some form of waste yarn below to run the code on your machine. Two questions there:

1. In terms of the failures in the increases, is it failing basically at the beginning but not later?
2. Have you tried increasing the amount of waste yarn and ensuring it is not too tightly connected to the active stitch course?
3. Have you tried knitting the piece but in the original orientation (using decreases instead of increases)?

I don't use rollers on our machine because the sinkers are sufficient. That means that the yarn is typically free falling without additional tension beside the sinkers preventing the stitches to move up. I wonder if the roller ends up creating too much tension during the transfers so that moving a single stitch on the side fails because the side is under a larger load somehow.

I assume this could especially happen if the starting fabric is narrow. Then as it gets wider, it becomes less and less important.

If this is the problem, then you may just not be able to knit narrow pieces with complex shaping unless you get perfect tensioning. My own experience is that knitting small structures that do shaping is hard, even on our machine. We have lots of issues doing wide increase shaping for the point of a sock, or similarly closing rounded fingers in a glove.

If the reality is that the tension is too hard to get right for these, then I assume that the solution is a different casting strategy. One option is to pre-cast on the needles so that you don't do increases, but just knit on the side while having already cast on previous stitches. this effectively creates a clean seam and makes shaping much simpler since you don't need any transfers. Here's an example for a sock:

Notice the pre-casting below the rounded shape. It's covering both sides of the needle bed before starting the sock itself. You could do the same for your triangle.

Unfortunately, the current system does NOT allow such type of scheduling. I hope to eventually get something like that, but that requires a different form or scheduling.

[walpoletim-bjss]

Hi

Thanks so much for the detailed response.

I have realised, that even though I thought I was knitting 1/2 gauge, I wasn't, so will do some trials this week on 1/2 knitting to force the CSE shaping.

We will also try and knit a larger size for a jumper as this will be more representative and cause less issues to the amount of shaping that has to occur.

We are very limited to how we can adjust the rollers on the kniterate - Currently the knitout -> kniterate software can change roller distances for either transfers or knitting, but I think we somehow will need to be able to change that elsewhere (as sometimes you have Manu transfer rows happening one after another and due to this end up with too much (or too little), but we can experiment with this later.

We have indeed added a full waste yarn section (about 100 rows) which ensures the knit is in the rollers before actually starting the real knit.

Let me play again with 1/2 Guage, and will let you know how we get on :):)

Thanks once again

Tim