#161 closed баг (сделано)
Проблема с таймаутом MODBUS для ЧРП Delta.
Сообщил: | andrei | Владелец: | Art_M |
---|---|---|---|
Приоритет: | Срочно | Этап разработки: | 1-я очередь |
Ключевые слова: | Delta, modbus, timeout | Копия: | alx, san, andrei |
Описание (последним изменил )
В ЧРП Дельта передаются настройки 09-02 (таймаут модбаса) и 09-03 (действие по тймауту). После этого, если не передавать командное слово, ЧРП останавливает мотор и выдает ошибку на свою панель, требующую вмешательства оператора или сброса ошибки. Такая ситуация, например, может происходить во время включения питания, когда ЧРП уже включился и ждет командное слово, а УГП-ЧР еще загружается.
На самом деле ситуация критичная, т.к. любое отключение питания на скважине приведет к останову нашей станции до приезда персонала. Проблему надо решить до отгрузки ЧРП в Нижневартовск.
Артем, напиши пожалуйста какая ещё есть информация. Что говорил контроллер? Может быть лог есть? Точно ЧРП перестает слушать модбас?
Может быть будет достаточно начать записывать командное слово или дернуть аппаратный сброс при включении УГП?
История изменений (21)
следующий: 4 comment:3 by , 6 лет ago
Краткое описание: | Проблема с таймаутом MODBAS для ЧРП Delta. → Проблема с таймаутом MODBUS для ЧРП Delta. |
---|
Replying to Art_M:
я думаю Андрей и Александр помнят, как в течение хода было слышно, как кратковременно прерывалось действие одной из НУ
Кратковременно - значит работа ЧРП возобновлялась автоматически без вмешательства оператора просто по факту очередной записи командного слова по MODBUS. Следовательно, информация о том, что при возникновении таймаута ЧРП перестает работать c MODBUS и останавливается, пока не вмешается оператор - ошибочна, и тикет можно закрыть как invalid.
comment:4 by , 6 лет ago
Кратковременно - значит работа ЧРП возобновлялась автоматически без вмешательства оператора просто по факту очередной записи командного слова по MODBUS. Следовательно, информация о том, что при возникновении таймаута ЧРП перестает работать c MODBUS и останавливается, пока не вмешается оператор - ошибочна, и тикет можно закрыть как invalid.
Прошу прощения, кратковременное отключение наблюдалось на Danfoss. Danfoss умеет при получении командного слова возобновлять работу. Но в настоящий момент, я предполагаю, при кратковременной потери связи Delta не восстановит работу, как это умеет делать Danfoss. Про возможности Delta действовать аналогично - я не знаю.
А лучше бы это уточнить у инженера в службе поддержки! Ребята свяжитесь со службой поддержки, уточните этот вопрос, служба поддержки обычно кучу попутных вопросов задает об программно-аппаратной реализации управления ЧРП, на которые я ответить затрудняюсь.
comment:5 by , 6 лет ago
Ок, тогда ждем когда нам отдадут Александра и он продолжит общаться с техподдержками ЧРП.
Думаю это не дольше чем через неделю.
comment:6 by , 6 лет ago
Предлагаю не возиться с этой проблемой в дельте, а просто не писать в неё настройку таймаута модбас. Вообще эта защитная мера была актуальна когда у нас не было дискретного управления, сейчас считаю что это не нужно.
Артём, Андрей, нужно решать сейчас, выскажите своё мнение на моё предложение.
comment:9 by , 5 лет ago
Вроде как Власов должен приехать и решить эту проблему.
Только надо нам определиться передавать ли действие по таймауту или же не трогать и пусть настраивают с панели оператора ЧРП.
Артем, какое решение? Делаем чтобы Дельта работала или пока ждем и не трогаем?
comment:10 by , 5 лет ago
Ну тогда ждём эксперимента Артёма/Алексея, если они ничего не добьются от техподдержки - уберём запись настройки.
следующий: 13 comment:12 by , 5 лет ago
Если я правильно все понял, то УГП-ЧР знает про аварию таймаута командного слова.
Сейчас нужно договориться когда ее сбрасывать.
Саша, "дискретный" сброс аварий в дельте сбрасывает все существующие на данный момент в ЧРП аварии?
Если в ЧРП одна авария - CE10 (Modbus transmission time-Out), то сбрасываем ее.
А вот если есть еще аварии, то пусть Артем скажет как с ними быть.
comment:13 by , 5 лет ago
Replying to andrei:
Если я правильно все понял, то УГП-ЧР знает про аварию таймаута командного слова.
Как она может знать об аварии, если с ПЧ нет связи?
следующий: 15 comment:14 by , 5 лет ago
Мы же ждали решение от Власова/Макарова, а то что ты предлагаешь это такой костыль с нашей стороны.
Как она может знать об аварии, если с ПЧ нет связи?
Алексей, тут подразумевается такая ситуация:
- НУ движется
- Пропала связь по 485 - ЧРП остановился по аварии "таймаут"
- Связь возобновилась - ЧРП стоит
- Мы считываем аварию и делаем "сброс аварий" - ЧРП сбрасывает аварию и продолжает работу.
Андрей, при управлении дискретными сигналами авария таймаут только предотвратит запуск ЧРП на неправильной частоте (при разрыве 485 ЧРП будет запущен на последней записанной частоте), вместо этого установка встанет. А надо ли это Артёму? Что лучше: ездить на произвольной частоте или вовсе остановиться? Насколько я помню, Артём всё-время хотел чтобы привод хоть как-то двигался...
следующий: 16 comment:15 by , 5 лет ago
Replying to san:
Алексей, тут подразумевается такая ситуация:
- НУ движется
- Пропала связь по 485 - ЧРП остановился по аварии "таймаут"
- Связь возобновилась - ЧРП стоит
Эта ситуация нереальная, так как, как известно из описания тикета и было подтверждено устно, при возникновении данной аварии ЧРП перестает отвечать на запросы контроллера по modbus. Следовательно, в реальности связь не восстановится.
comment:16 by , 5 лет ago
Эта ситуация нереальная, так как, как известно из описания тикета и было подтверждено устно, при возникновении данной аварии ЧРП перестает отвечать на запросы контроллера по modbus. Следовательно, в реальности связь не восстановится.
При проведении дополнительных экспериментов выяснилось что информация об "полном" отключении модбас была ошибочная. ЧРП очень даже общается, только двигаться не желает.
comment:17 by , 5 лет ago
Описание: | изменено (отличие) |
---|---|
Приоритет: | Полный атас → Срочно |
comment:18 by , 5 лет ago
При дискретном управлении "Функция таймаута командного слова" = 0 (игнорировать? ничего не предпринимать?).
При управлении по модбас:
- "Функция таймаута командного слова" = 2 (Останов).
- Время таймаута командного слова = 0,7с.
- При появлении аварии таймаута сбрасывать аварии ЧРП.
comment:19 by , 5 лет ago
Андрей ты ошибся тикетом, тебе в #188
А сейчас, предлагаю для устранения проблемы не писать в Дельту регистры настройки таймаута и и его функции. Вношу это в ТЗ ?
comment:21 by , 5 лет ago
Решение: | → сделано |
---|---|
Состояние: | new → closed |
В качестве временного решения убрали из ТЗ запись настроек таймаута в Дельту, дальнейшее обсуждение темы в #188
=>В ЧРП Дельта передаются настройки 09-02 (таймаут модбаса) и 09-03 (действие по тймауту). После этого, если не передавать командное слово, ЧРП останавливает мотор и выдает ошибку на свою панель, требующую вмешательства оператора и перестает реагировать на команды в модбас. Такая ситуация, например, может происходить во время включения питания, когда ЧРП уже включился и ждет командное слово, а УГП-ЧР еще загружается.
Ошибка CE10 у меня возникала именно при выключении питания станции, когда контроллер уже обесточен, а ЧРП еще держится на конденсаторах, и при включении, когда ЧРП уже включился, а контроллер еще только загружается.
=> Может быть будет достаточно начать записывать командное слово или дернуть аппаратный сброс при включении УГП?
Я полагаю, что мы смотрим в нужную сторону, думаю скорее всего с этого и надо начинать. Однако, не уверен, будет ли этого достаточно. Здесь следует учесть, что при малом значении уставки таймаута мы наблюдали потери связи прямо в течении хода (я думаю Андрей и Александр помнят, как в течение хода было слышно, как кратковременно прерывалось действие одной из НУ), которые могут возникать по различным причинам. Соответственно, контроллеру следует пересылать командное слово и дергать аппаратный сброс не только при включении УГП. Скорее всего контроллеру следует научиться детектировать случай, когда у Delta будет ошибка CE10 без других критических (что бы случайно не сбрасывать все в подряд), и применять такие действия каждый раз в таком случае.