KH930: pattern displaced using the K-carriage starting from the right

[Adrienne200]

Right-left is displaced 16 places to the left. Left-right is displaced 40 stitches to the left.

AYAB software version: 0.99 rc1 Aug 6 2023
Computer/OS: Windows 7
Knitting machine: KH930
AYAB hardware: Interface

Steps:
Open the uC3 image from the samples,
Set all UI settings to defaults
Set the carriage to KC2 and start from the right.
Set needles L40 - R 40 in work.

Select L15-R15 in the software which is all it should need, but actually have L40-R40 in work, so you can see the displacements.
Expected: starting from the right should select the exact same needles as if you’d started from the left. So the first two needles for the tail of the mu character should be at Green/R14 and 15. (This works perfectly when starting from the left.)

Actual, starting from the right:
If you only put needles L15 - R15 in work, it appears that nothing is happening at all when going Left-Right. And Right-Left shows part of the pattern but displaced.

To see a bit more of what’s happening:
Cross the right turn mark and wait for the mutiple-beep as usual.
Right-left passes: it’s selecting the pattern, but displaced 16 places to the left. In the very first row, the two needles are at L2 and L3, whereas they should be at R14 and 15, ie they are displaced 16 needles to the left.
Left-right passes, row 2, the two needles are way out at L25 and 26, ie 40 stitches to the left. (An odd multiple of 8 this time, usually these errors are multiples of 16)
Row3, same as row 1

In short: right-left passes are displaced 16 needles to the left, and left-right passes are displaced 40 needles to the left.

[Adrienne200]

However, when the pattern is a full 200 stitches wide, the KH930 K carriage starting from the right is almost all correct, except for the first about 32 stitches at the right on the first row. (And yes, I am stopping to wait for the beep at the first available opportunity, the magnet is about an inch past the hall sensor.)

[clholgat]

Only happens on the 930, can't repro on my 910

[jonathanperret]

Looking at the code, I think what happens on the 930 is that when the K carriage passes the right magnet and the voltage rises on the analog input, this is considered enough to "initialize" the machine (Knitter waits only for m_hallActive to be different from None):

ayab-firmware/src/ayab/encoders.cpp

Lines 258 to 261 in 85d0842

	hallValueSmall = (hallValue < FILTER_R_MIN[static_cast<uint8_t>(m_machineType)]);
	if (hallValueSmall || hallValue > FILTER_R_MAX[static_cast<uint8_t>(m_machineType)]) {
	m_hallActive = Direction_t::Right;

But if you look below in Encoders::encA_falling you can see that the carriage is not detected as a K carriage — the test looks for a low voltage to declare a K carriage is present:

ayab-firmware/src/ayab/encoders.cpp

Lines 280 to 282 in 85d0842

	if (hallValueSmall) {
	m_carriage = Carriage_t::Knit;
	}

This makes sense on the 910 where the signal that is connected to the shield is actually a digital signal that goes low when a K magnet is present — but on the 930 and machines like it, we get an actual analog signal just like on the right, so we need to look for a high signal for a K carriage.

The result on the 930 is that the machine is initialized and knitting starts, but the carriage type remains unknown until the left sensor is passed (which happens naturally when the pattern is 200 needles wide). It's no surprise it makes a mess of any rows before that.

[jonathanperret]

I tentatively added this to the 1.0.0 milestone. I think I can write a relatively simple fix for the issue (on machines other than the 910, we just need to apply the same logic on the right sensor as we already do on the left sensor).

On the other hand, we don't absolutely have to advertise starting from the right as a 1.0 feature (I didn't mention it in the release notes so far), we can keep it for 1.1 that can follow closely…

[dl1com]

As a result of recent discussions, we should also add this as a known issue to the manual and describe the cases/hardware constellations where this can occur.

We should also at least try to get a hardware fix in shield and interface before official release of 1.0.0.
More details in a separate issue to coordinate the required measures.