Propose SMM encoder and motor parameters from the drive #62

User story

As an engineer configuring the safety module of a SOMANET drive,
I want Motion Master to propose the SMM's encoder and motor parameters from the drive's own configuration,
so that the safe side matches the drive without me copying resolutions, gear ratios and motor data by hand.

Context

The SMM monitors the motor with its own copy of the encoder and motor data. That data already exists in the drive's configuration, the "unsafe side". OBLAC Drives has two buttons that copy it into the SMM parameters before a transmit, and shows the proposed values in a dialog for the user to confirm.

Copy encoder data (oblac-drives/src/app/devices/smm/smm-encoder/smm-encoder.component.ts:92-195):

1. The SMM encoder source type 0x2630:01 names an encoder interface. A fixed table turns it into a drive encoder port: 1 to 4 are port 1, 5 to 8 port 2, 9 port 3, and 0 and 10 no port (src/app/store/smm-parameter.model.ts:224-236).
2. The drive's encoder configuration on that port, from 0x2110 or 0x2112, gives the primary encoder. The other configured encoder is the verification encoder.
3. 0x2630:02 resolution, 0x2630:03 multiturn bits and 0x2630:05 timeout take the primary encoder's values. 0x2630:04 clock frequency is an option list on the SMM, so it takes the option closest to the primary encoder's clock frequency.
4. 0x2631:02 resolution and 0x2631:03 multiturn bits take the verification encoder's values, or the primary encoder's resolution when there is no verification encoder.
5. With a verification source type set and a Hall primary encoder, 0x2631:02 becomes the primary resolution × 6 / 4096 and 0x2631:03 becomes 0.
6. The verification scaling 0x2635:08 and 0x2635:09 is the gear ratio from 0x6091. When the primary encoder is the torque encoder, it is motor shaft revolutions over driving shaft revolutions, and otherwise the inverse. The numerator is negated when the two encoders have different polarities.
7. From SMM firmware 0x0203, 0x2635:11 takes the drive's system polarity 0x200D.

Copy motor data (src/app/devices/smm/smm-motor/smm-motor.component.ts:32-63), second layout only: 0x26B1:01 takes the torque constant 0x2003:02, 0x26B1:03 the pole pairs 0x2003:01, and 0x26B1:04 the commutation angle offset 0x2001, negated when the motor phases are inverted, 0x2003:05 not 0.

These are rules of the drive's configuration, so they belong on the server. The Console shows the result and the user confirms it, as now.

Acceptance criteria

• GET /api/devices/{slavePosition}/smm/proposed-values?from=encoder returns the proposed values of the encoder rules above, each with its index, subindex, current SMM value, proposed value, and the rule that produced it.
• GET /api/devices/{slavePosition}/smm/proposed-values?from=motor returns the proposed values of the motor rule, and 409 on the first layout, which has no motor group.
• A rule that has no source, such as a source type with no port or a port with no encoder configuration, is reported with the reason, and proposes nothing for that rule's parameters.
• A proposed value outside the SMM parameter's minimum and maximum is returned with a warning, not clamped.
• The routes never write anything. The proposed values reach the SMM only when a configuration of SMM configuration: transmit, verify and validate #61 transmits them.
• smm-configure of SMM configuration: transmit, verify and validate #61 takes proposeFrom: ["encoder", "motor"], which applies the proposed values before the transmit and lists them in the step list.
• The rules are pure functions in libs/node with unit tests: each source type, a missing verification encoder, the Hall rule, both gear ratio directions, different polarities, and the firmware 0x0203 gate.
• Every object read is checked against the drive's live object dictionary or the ESI before it is used, not assumed from OBLAC's code.
• The Configure wizard of SMM configuration: transmit, verify and validate #61 has Copy encoder data and Copy motor data buttons, which show the proposed values with their rules and apply them on confirm.
• apps/motion_master/swagger.yml documents the route, and the generated client is regenerated.

Out of scope

• Configuring the drive's own encoders. iC-MU encoder configuration #23 covers the iC-MU encoders.
• Proposing values for other SMM groups.

Notes

• This issue depends on SMM parameters and readouts #60 and SMM configuration: transmit, verify and validate #61.

References

• OBLAC Drives: src/app/devices/smm/smm-encoder/smm-encoder.component.ts:92-195, src/app/devices/smm/smm-motor/smm-motor.component.ts:32-63, src/app/store/smm-parameter.model.ts:224-236, src/app/store/encoder-configuration.model.ts
• SMM parameters and readouts: SMM parameters and readouts #60
• SMM configuration: SMM configuration: transmit, verify and validate #61