Удаленное изменение настроек ЧРП

[san]

Ещё одно предложение от Art_M:

Рассмотреть возможность удаленного "считывания" и изменения любых уставок ЧРП, пусть даже если это будет происходить в каком-нибудь, упрощенном текстовом режиме.

[Art_M]

Если не затруднит, давайте скорректируем, путем добавления слова "считывания"
Рассмотреть возможность удаленного "считывания" и изменения любых уставок ЧРП, пусть даже если это будет происходить в каком-нибудь, упрощенном текстовом режиме.

[andrei]

"Любые уставки" подразумевает - все уставки?

[andrei]

Артем, если этот тикет повторяет ТЗ " Приложение 2. Настройки для записи в ЧРП.", то может закроем его? Зачем в двух местах одно и тоже?
В приложении нужно еще добавить уставки ЧРП, которые нужно читать.
Куда только мы столько информации денем?

[san]

Этот тикет не повторяет то что в тз.
Здесь Артём предлагает дать возможность пользователю считать/записать любую настройку(регистр) ЧРП, а по ТЗ мы читаем/пишем только малую часть настроек.

[andrei]

Мне кажется странным что Артем в двух местах предлагает различные решения))))

[san]

Это не различные решения одной задачи, это разные задачи.

1. В ТЗ указано какие значения в какие регистры ЧРП должен записать контроллер
2. А здесь Артём предлагает инструмент позволяющий пользователю, подключенному удаленно к контроллеру, считывать и записывать любые значения в любые регистры ЧРП.

[andrei]

Задача понятна.
Как вариант: Отдельная вкладка в веб-интерфейсе с парой полей для ввода и кнопки считать, записать.
Пока это не самая интересная проблема.

[san]

На мой взгляд нет необходимости выносить этот функционал в веб-интерфейс.

в каком-нибудь, упрощенном текстовом режиме

Думаю что, для решения задач Артёма, достаточно будет команд работы с модбас через консоль.

[andrei]

Если это требуется только для Артема, то да. И приоритет тогда не средний, а низкий.

[alx]

Replying to san:

Думаю что, для решения задач Артёма, достаточно будет команд работы с модбас через консоль.

При работающем процессе smarthdcd посторонним процессам лезть в шину modbus нельзя. На шине может быть только один мастер. Так как smarthdcd постоянно ведет обмен сообщениями по шине modbus (то есть сообщение отправлено и ожидается ответ на него), отправка в это же время "постороннего" сообщения нарушит логику работы шины.

Работоспособный вариант - это если внешняя команда будет передавать запрос не прямо в шину, а процессу smarthdcd через какой-то специальный интерфейс, а smarthdcd, в свою очередь, поставит этот запрос в общую очередь. Но если все равно делать дополнительный интерфейс, то почему это не должен быть web-интерфейс?

[san]

все равно делать дополнительный интерфейс

В таком случае согласен, пусть будет в веб-интерфейсе.

[andrei]

Тогда предварительное решение:
Отдельная вкладка в веб-интерфейсе. Два поля для ввода значений: адрес регистра и содержимое. Кнопки ОТПРАВИТЬ и СЧИТАТЬ.
ОТПРАВИТЬ отправляет содержимое в регистр. СЧИТАТЬ считывает содержимое указанного регистра.

Возражения?

[san]

У меня нет возражений, но я бы ещё добавил какой-то индикатор успешности/неуспешности записи или чтения.

[andrei]

С индикатором согласен.
Передаю тикет Алексею.

[alx]

С учетом того, что предложено читиать/писать "сырые" данные (то есть фактически реализовать две функции Modbus), мне показалось, что реализовать это будет очень просто. Но потом я столкнулся с неожидинной проблемой.

Cейчас HTTP-сервер реализован так, что предполагает немедленное выполнение любой принятой команды API и отправку ответа. В данном же случае после получения команды API генерируется запрос Modbus, который ставится в очередь на отправку в шину, после чего соответствующий HTTP-поток должен заснуть, так как ответа на запрос еще нет. И только после получения ответа от ЧРП (или таймаута) дложен быть сгенерирован ответ, и поток HTTP разбужен для отправки ответа.

Пока для быстрого теста функция реализована частично: при получении запроса на запись соответствующий запрос ставится в очередь - и все, никакого ожидания ответа от ЧРП нет (см. r711).

---

Далее (это я пишу скорее сам для себя) необходимо доработать внутренний интерфейс между сервером и командами API:

• добавить обработчику возвращаемое значение, по которому определять, была ли команда выполнена полностью или требуется "усыпить" HTTP-поток;
• кроме запроса/ответа обработчику команды передавать еще и идентификатор HTTP-потока;
• сделать функцию пробуждения HTTP-потока по его идентификатору, когда будет готов ответ.

Должно получиться как-то так:

[san]

Небольшое замечание по внешнему виду
Для пользователя удобней было бы задавать не адреса регистров а номера параметров, предлагаю добавить поле "Номер параметра" в интерфейс. Например, если пользователь хочет записать чтото в параметр 05-01, он введёт в это поле 501, и дальше в зависимости от типа чрп значение будет записано в нужный регистр. Если же поле "Номер параметра" не заполнено, то запись/чтение производить по адресу регистра из поля "Адрес".

[alx]

Replying to san:

Для пользователя удобней было бы задавать не адреса регистров а номера параметров...
предлагаю добавить поле "Номер параметра" в интерфейс.

А еще им было бы удобнее, например, задавать ток в Амперах (120.5 А), а не "сырое" значение в сантиамперах или еще непонятно в каких единицах. :) И мы возвращается к вопросу, который мы уже недавно обсудили устно - на каком уровне должна работать эта функция - на низком (уровень функций шины Modbus) или высоком (уровень настроек ЧРП)...

[san]

Да, всё правильно функция должна работать на низком уровне.
Но суть предложения в том что незначительное усложнение функции даст пользователю значительное увеличение удобства использования.

[andrei]

По крайней мере Амперы в сантиАмперы я могу в уме перевести, а для перевода из HEX в DEC еще и не каждый калькулятор подойдет)))
Но для быстроты можно и оставить, я приспособился.

[andrei]

Можно ограничиться добавлением в таблице ТЗ с параметрами десятичного адреса.
А тикет закрыть, т.к. задача выполнена.

[san]

Replying to andrei:

добавлением в таблице ТЗ

Руки прочь от ТЗ :)

[andrei]

Replying to san:

Replying to andrei:

добавлением в таблице ТЗ

Руки прочь от ТЗ :)

Зря ты так, там потом удобно смотреть адрес и переводить не надо будет, все в одном месте.

[andrei]

Артем просит: кроме просмотра и записи уставок ЧРП через веб-интерфейс нужно иметь возможность сбросить ошибку. Например если в случае ввода вне диапазона получили СЕ4

[san]

Артем просит: кроме просмотра и записи уставок ЧРП через веб-интерфейс нужно иметь возможность сбросить ошибку.

Это не имеет отношения к данному тикету

Руки прочь от ТЗ :)

Зря ты так

Ну добавь, мне не жалко, только эта информация к тз не относится

[andrei]

Ну добавь, мне не жалко, только эта информация к тз не относится

Хоть где-то останется информация доступная и легко находимая.

Для этого тикета осталось научиться считывать регистры из ЧРП.

[Art_M]

Опыт показал - проблема у нас есть - не умеем записывать уставку номинального тока мотора 1-24 в чрп данфосс.

[Art_M]

Так же опыт показал, а ответ поддержки удостоверил, что введенные уставки Danfoss хранятся только в оперативной памяти. Необходимые действия для записи в энергонезависимую память Danfoss направил на почту Саше.

[san]

По последнему комментарию - см. #212

[san]

Replying to alx:

С учетом того, что предложено читиать/писать "сырые" данные (то есть фактически реализовать две функции Modbus), мне показалось, что реализовать это будет очень просто. Но потом я столкнулся с неожидинной проблемой.

Алексей, директор просил задать тебе вопрос. Выполняю его просьбу.
Каковы примерные сроки реализации этого тикета в Алексее-часах?

[alx]

Replying to san:

Каковы примерные сроки реализации этого тикета в Алексее-часах?

Могу оценить это в 25-40 Алексея-часов.