Start knitting on LHS or RHS

[t0mpr1c3]

Counterpart to AllYarnsAreBeautiful/ayab-firmware#31

Manual selection of the carriage needs a radio button on the desktop Preferences dialog, and a change to the API informing the device of the carriage selected in the reqInit (or reqStart?)message. The desktop needs to verify the carriage reported in IndState. The host also needs to inform the device (in the reqInit or reqStart message) whether it is starting on the LHS or RHS.

[jpcornil-git]

Why not handle this completely in the desktop SW ?

FW could indicate to SW via IndSate msg that the left/right hall sensor has been passed in the right/left direction respectively and transition from s_init to s_ready as of today and SW, as a function of preference settings, either accept/reject by triggering a s_operate/s_init transition ?

I believe FW/API should be made as dumb/generic as possible and focus as much as possible on HW/realtime aspects.

[t0mpr1c3]

I believe FW/API should be made as dumb/generic as possible and focus as much as possible on HW/realtime aspects.

Yes, I agree this is a good goal.

[t0mpr1c3]

Why not handle this completely in the desktop SW ?

FW could indicate to SW via IndSate msg that the left/right hall sensor has been passed in the right/left direction respectively and transition from s_init to s_ready as of today and SW, as a function of preference settings, either accept/reject by triggering a s_operate/s_init transition ?

I think this should be possible.

[dl1com]

@AllYarnsAreBeautiful/ayab-contributors do we want to solve this for 1.0?

[t0mpr1c3]

Yes, because the solution impacts the API, which we want to be stable for 1.0.

[t0mpr1c3]

So, is the plan still to have the user select the carriage and direction and have the desktop (host) tell the device (interface) what to expect?

I suggest that the host should tell the device this information in every line of data because of #607.

In terms of what we need to implement for the GUI, I suggest radio buttons to select Knit Carriage/Garter Carriage, start LHS/start RHS.

It's not immediately obvious to me how we should implement lace patterns in the GUI. Perhaps we can leave that until after v1.0 and just get the API in place for now.

[jpcornil-git]

If carriage detection implemented in FW is solid (detect carriage type in both directions and reset associated carriage parameters/carriage position dynamically) I don't see what issue it will solve. If you want to recover from a power down, you would have to recover carriage position as well (not trivial to guess, most effective is to pass one LHS/RHS sensor).

=> Why would you need to enforce carriage type/direction(/position) from the GUI ?

[t0mpr1c3]

If carriage detection implemented in FW is solid (detect carriage type in both directions and reset associated carriage parameters/carriage position dynamically)

Is it? My understanding was that this is/was not the case for 910.

[jpcornil-git]

Because of:

• the HW issue on KH910 with RHS hall sensor ?
  => It should work for K carriages (but not L nor G) [pullup should also be enabled for that pin cfr. G carriage auto detection ayab-firmware#51)
• not solid
  => It should be fixed then :-)

[t0mpr1c3]

Yes, it is my understanding that K carriage detection on both sides should be fixed in the new hardware.

What do you propose for right now?

[jpcornil-git]

K carriage can be made OK on existing HW (if there is a detection from RHS sensor on KH910 then you assume it is K [can't be L and can't distinguish from G because of the missing connection).
If you want to support G as well then SW has to tell FW 'ForceG', i.e. if you detect K (RHS) or G (LHS) it is G and you need a 'Force G' radio button to set that in the UI

[t0mpr1c3]

That is still setting the carriage in the desktop, really.

Either way we need to change the API.

But you are saying that we don't need to specify the direction, yes?

[jpcornil-git]

If you want to add support for G carriage start from RHS on KH910 on existing HW yes (only use case I believe)

[t0mpr1c3]

OK, I guess the question is whether we want to support that particular combination or not.

The question also arises of how we know which version of the hardware is in use because right now the desktop has no way of knowing.

[jpcornil-git]

Legacy HW could report HW_DEFAULT and new one HW_ESP32_V1 for ex.

Note that wrt API you may also want to add a message to report FW state to SW. Today SW/UI move back to configuration state as soon as the last line has been sent while FW has still to handle it, i.e. not really finished.

I saw that issue when I added a motor to a machine because last line was always missing.
On main, the issue is here (imageFinished should be set when FW transition to s_ready not when the last line has been sent)
https://github.com/AllYarnsAreBeautiful/ayab-desktop/blob/main/src/main/python/ayab/plugins/ayab_plugin/ayab_control.py#L806

[t0mpr1c3]

Yes, that's a separate issue.

[dl1com]

Just my two cent:
In case adding RHS is too much of a hassle with the current hardware and we don't get a lean solution for it, we should leave it out.

The question also arises of how we know which version of the hardware is in use because right now the desktop has no way of knowing.

That's an info which is good to have in any case. Therefore we created AllYarnsAreBeautiful/ayab-firmware#106 some time ago

[t0mpr1c3]

If we can implement what JPC is suggesting we might not need changes to the API after all, so this does not necessarily need doing for v1.0, we can do it as feature release v1.1 or something.

In which case the only change that is necessary for the desktop right now is to correct the knitting progress window which currently always assumes starting on the LHS. I think we just need to check the reported direction in the IndState message? (#626)

[X-sam]

Let's consider working with knit carriage sufficient for 1.0.0 and open additional tickets for additional functionality (and tag them next release).