Closed nikita-p closed 3 weeks ago
На самом деле GetParams уже возвращает "человеческий" номер --- поле layer. https://github.com/caenHV/caen_tools/blob/8347601d5576ab55f499defb03ba685445a5a1f9/caen_tools/DeviceBackend/apifactory.py#L85C13-L85C59 Вот тут нужно брать keydict["layer"], если я не ошибаюсь.
там вроде проблема, что в один layer по определению мы можем добавлять несколько разных каналов
TL;DR: я не знаю, как решить данный issue, если не использовать имплицитное условие однозначности связи канал-слой.
Тогда встаёт вопрос --- что такое "человеческий" номер? В парадигме Попова это и есть layer. В его схеме одному слою сопоставляется один канал. У нас подход шире. Сужать, его не стоит, конечно.
Сейчас монитор уже использует продположение однозначности связи канал-слой, которое справедливо для нынешней ситуации (первод номера канала из служебной записи в человеческую). То есть если каналов станет больше чем слоёв, нам придётся переписывать монитор, чтобы всё было тип-топ.
Возможное решение: Можем уже сейчас ввести нашу "человеческую" нумерацию --- {layer}_{channel} и что-нибудь менее глупое. Но такая нумерация будет отличаться от Поповской.
Другими словами, я не знаю, как решить данный issue.
По сути уже сейчас вся информация лежит в test_config.json и ещё один файл избыточный, однако использовать test_config.json Monitor не может (поскольку это увеличивало бы его связность с DeviceBackend). Я бы рассмотрел изменение API DeviceBackend (именно
/get_params
) так, чтобы он выдавал "человеческий" номер канала, а не служебный (составленный изboardaddress_conet_link
) и который бы монитор просто использовал (безо всяких преобразований на своей стороне), но в таком варианте также должен быть изменён ответ тикета GetParams в репозитории Setuphttps://github.com/caenHV/caen_tools/blob/323d258edb3c9cd696cad158ae175a044fb2b9f9/caen_tools/MonitorService/monitor.py#L118