Pixel→Moxa_NPort_5150→ПЧ_ABB_ACS_310 по Modbus (решено)

[Aiven]

Задача: Необходимо управлять Преобразователем частоты ABB ACS 310 с контроллера Pixel 2511 по протоколу Modbus.

1. Предприняты попытки подружить эти девайсы по протоколу Modbus-RTU. Соединялись девайсы непосредственно друг к другу. Работать корректно данная схема отказалась. На Преобразователе частоты постоянно выпадает ошибка связи A5001. (вернее работает какое-то время, от нескольких минут до 5-15 минут, потом выпадает ошибка).
Обращался в техподдержку АВВ. Проблем не нашли. Брал другой такой же ПЧ, симптоматика та же.

2. Подключил вместо контроллера Pixel устройство Moxa NPort 5150, на ПК запустил опрос с сервера MasterOps. Ошибки связи на ПЧ не появляются. Схема работоспособна.
Вывод: Что то не так с интерфейсом 485 на Pixel.

3. Пытаюсь собрать схему:
1. Pixel→Moxa_NPort_5150 (здесь обмен по Modbus-TCP)
2. Moxa_NPort_5150→ПЧ_ABB_ACS_310 (здесь обмен по Modbus-RTU)
Связь между Moxa_NPort_5150 и ПЧ_ABB_ACS_310 настроена.
Связь между Pixel и Moxa_NPort_5150 настроить не получается.
Прошу помощи.

PS: Конечно приоритетней чтобы контроллер мог напрямую управлять ПЧ без промежуточных звеньев, если есть решение, прошу поделиться.
На данный момент:

• форум листал,
• с терминаторами играл,
• линию связи экранированным кабелем с заземлением экранов собрал,
• скорость перебирал,
• осциллограммы сигналов А и В смотрел,
• задержки в проекте Лоджика менял. При уменьшении времени задержки до 100 мС (было и 1000 мС и 3000 мС) стало лучше, но не идеально, ошибка появляется.

Тестовый проект и настройки конвертера прилагаю:
test_2511_5150_310.psl


Проект в котором устанавливалась связь напрямую Pixel→ПЧ ACS310 ПЧ_Pixel.psl

[Arsie]

Цитата

Сообщение от Aiven

Задача: Необходимо управлять Преобразователем частоты ABB ACS 310 с контроллера Pixel 2511 по протоколу Modbus.

1. Предприняты попытки подружить эти девайсы по протоколу Modbus-RTU. Соединялись девайсы непосредственно друг к другу. Работать корректно данная схема отказалась. На Преобразователе частоты постоянно выпадает ошибка связи A5001. (вернее работает какое-то время, от нескольких минут до 5-15 минут, потом выпадает ошибка).
Обращался в техподдержку АВВ. Проблем не нашли. Брал другой такой же ПЧ, симптоматика та же.

Что такое "ошибка связи A5001"? Что означает этот код?

[ATS]

Цитата

Сообщение от Aiven

Пытаюсь собрать схему:
1. Pixel→Moxa_NPort_5150 (здесь обмен по Modbus-TCP)
2. Moxa_NPort_5150→ПЧ_ABB_ACS_310 (здесь обмен по Modbus-RTU)
Связь между Moxa_NPort_5150 и ПЧ_ABB_ACS_310 настроена.
Связь между Pixel и Moxa_NPort_5150 настроить не получается.

Moxa_NPort_5150 вообще не знает что такое Modbus-TCP, умеет только Modbus-RTU Over TCP.
Так что такой вариант связи стоит похоронить.

[Aiven]

Цитата:

Сообщение от Arsie

Что такое "ошибка связи A5001"? Что означает этот код?

Копия из мануала: 5001 Привод не отвечает. Проверьте подключение панели управления.

Панель управления никак не влияет на появление ошибки. Пробовал и с панелью и без панели. Фокус в том, что если управление происходит не по шине FiledBus (протокол Modbus-RTU, интерфейс RS-485), а например через аналоговый вход 0-10 В. Ошибка не появляется.

Сервис ABB сказали что данная ошибка может генериться и при возникновении неисправностей при работе по Modbus-RTU.

Настораживает то что с конвертером Moxa ошибки нет.

Если нужен, мануал на ПЧ вышлю, к форуму не прикручивается, тяжёлый 5,6 М.

[Arsie]

Цитата

Сообщение от Aiven

Копия из мануала: 5001 Привод не отвечает. Проверьте подключение панели управления.

Т.е. на экране панельки возникает сообщение, что эта панелька потеряла частотник?

Цитата

Сообщение от Aiven

Настораживает то что с конвертером Moxa ошибки нет.

Ну это как отрезать себе ноги и радоваться тому, что теперь не пробежать перекрёсток на красный свет

Т.е. при использовании Моксы убирается причина проблемы. Например, мокса наверняка питается не от того же источника питания, что контроллер. К моксе наверняка подходит гораздо меньше проводов и так далее. В общем, нужно искать проблему, а для этого сначала нужно уровнять условия работы Пикселя и Моксы, т.е. откинуть от контроллера всё, кроме питания и RS485

[ATS]

Цитата

Сообщение от Aiven

Настораживает то что с конвертером Moxa ошибки нет.

Настройки 485-го на Моксе покажи. У немцев со стоп битами обычно строго.

[Aiven]

Цитата

Сообщение от ATS

Настройки 485-го на Моксе покажи. У немцев со стоп битами обычно строго.

[Aiven]

Цитата:

Сообщение от Arsie

Т.е. на экране панельки возникает сообщение, что эта панелька потеряла частотник?

Формально да. Или панелька частотник или частотник панельку. Пробовал 2 частотника и 2 панельки. Поведение идентично. Время появления ошибки всегда разное. Закономерность отследить не удалось.

Цитата:

Сообщение от Arsie

Например, мокса наверняка питается не от того же источника питания, что контроллер. К моксе наверняка подходит гораздо меньше проводов и так далее. В общем, нужно искать проблему, а для этого сначала нужно уровнять условия работы Пикселя и Моксы, т.е. откинуть от контроллера всё, кроме питания и RS485

Верно: питание моксы и контроллера от разных источников питания. У контроллера минимальное количество подключений, а именно:

• Питание.
• Связь по RS-485.
• Кнопка Dinput 0-INT. (длина проводников 8 см)

[ATS]

Что-то не сходится.
У Моксы 9600 8N1, а у Пикселя в проекте 19200 8N2

[Aiven]

Цитата

Сообщение от ATS

Что-то не сходится.
У Моксы 9600 8N1, а у Пикселя в проекте 19200 8N2

Я же писал выше что играл, перебирал все возможные варианты, какие остались последние, те и сохранились.
Если критично, попробую сейчас ещё раз, именно с теми же настройками что на моксе.

[Arsie]

Цитата

Сообщение от Aiven

Формально да. Или панелька частотник или частотник панельку. Пробовал 2 частотника и 2 панельки. Поведение идентично. Время появления ошибки всегда разное. Закономерность отследить не удалось.



Верно: питание моксы и контроллера от разных источников питания. У контроллера минимальное количество подключений, а именно:

• Питание.
• Связь по RS-485.
• Кнопка Dinput 0-INT. (длина проводников 8 см)

А скорость опроса одинаковая? Переменные одни и те же опрашиваются одними и теми же видами запросов?

Я почему уточняю, лет 12 назад столкнулся с не помню уже каким частотником, у которого банально перегревался проц из-за частого опроса по модбасу.

[ATS]

Цитата

Сообщение от Aiven

Я же писал выше что играл, перебирал все возможные варианты, какие остались последние, те и сохранились.
Если критично, попробую сейчас ещё раз, именно с теми же настройками что на моксе.

Главное чтобы на частотнике и Пикселе все было одинаково.

[Aiven]

Цитата:

Сообщение от Arsie

А скорость опроса одинаковая?

Скорость опроса всех переменных одинаковая (период опроса 100)

Цитата:

Сообщение от Arsie

Переменные одни и те же опрашиваются одними и теми же видами запросов?

Хм, здесь не совсем понял как это настраивается. В карте памяти?
Скрин карты памяти прилагаю:

[Arsie]

Цитата

Сообщение от Aiven

Скорость опроса всех переменных одинаковая (период опроса 100)



Хм, здесь не совсем понял как это настраивается. В карте памяти?
Скрин карты памяти прилагаю:
Вложение 3862

Для такой карты памяти и периода опроса 100 мсек контроллер буквально задалбывает частотника. Неужели у вас и в OPC те же 100 мсек стоят, а не 1000 мсек, которые по умолчанию?

У вас контроллер настроен на работу одиночными запросами, OPC серверу вы также запретили спрашивать по несколько переменных за один раз?

[Aiven]

Цитата:

Сообщение от Arsie

Для такой карты памяти и периода опроса 100 мсек контроллер буквально задалбывает частотника. Неужели у вас и в OPC те же 100 мсек стоят, а не 1000 мсек, которые по умолчанию?

У вас контроллер настроен на работу одиночными запросами, OPC серверу вы также запретили спрашивать по несколько переменных за один раз?

Ответы на вопросы на скриншоте:
На OPC всего 3 переменных. Все переменные как в Лоджике не стал собирать для экономии времени.

[Arsie]

Цитата

Сообщение от Aiven

Ответы на вопросы на скриншоте:Вложение 3863
На OPC всего 3 переменных. Все переменные как в Лоджике не стал собирать для экономии времени.

Период опроса 500 мсек и прямой запрет работать с командами одиночной пересылки.

А в Пикселе наоборот - 100 мсек и прямой запрет группировать несколько переменных в одну посылку.

Что ж сказать, "практически равные" условия. Наверняка в Пикселе ещё и тайм-аут на отказ штатные 100 мсек, а не 1000, как в OPC.

[New]

Цитата:

Сообщение от Arsie

Что ж сказать, "практически равные" условия.

Плюс ещё и 3 попытки в ОРС

[Aiven]

Цитата:

Сообщение от Arsie

Период опроса 500 мсек и прямой запрет работать с командами одиночной пересылки.

А в Пикселе наоборот - 100 мсек и прямой запрет группировать несколько переменных в одну посылку.

Что ж сказать, "практически равные" условия. Наверняка в Пикселе ещё и тайм-аут на отказ штатные 100 мсек, а не 1000, как в OPC.

Посмотрел в ОРС время ответа слейва (ПЧ), составляет порядка 205-208 мС.
Соответственно в Pixel период опроса переменных изменил с 100 до 300 мС.
Время на отказ было и оставил 1000 мС.
Разрешил группировать запросы.
Скорость подключения на устройствах сейчас 9600 8N1.
Итого: Схема проработала порядка 3х часов. Затем выпала ошибка.

Изменил период опроса с 300 до 500 мС. Наблюдаю.

1. Как правильно подобрать время опроса переменных?
2. Как правильно подобрать время на отказ в Pixel?

[Arsie]

Цитата

Сообщение от Aiven

Посмотрел в ОРС время ответа слейва (ПЧ), составляет порядка 205-208 мС.
Соответственно в Pixel период опроса переменных изменил с 100 до 300 мС.
Время на отказ было и оставил 1000 мС.
Разрешил группировать запросы.
Скорость подключения на устройствах сейчас 9600 8N1.
Итого: Схема проработала порядка 3х часов. Затем выпала ошибка.

Вот вам и ответ, кто где накосячил. В частотнике какие-то проблемы. Может тоже что-то перегревается.

Цитата

Сообщение от Aiven

1. Как правильно подобрать время опроса переменных?
2. Как правильно подобрать время на отказ в Pixel?

Лучше задайте сами себе вопрос, зачем частотник опрашивать чаще, чем раз в секунду.

[Aiven]

Цитата:

Сообщение от Arsie

Вот вам и ответ, кто где накосячил. В частотнике какие-то проблемы. Может тоже что-то перегревается.

Лучше задайте сами себе вопрос, зачем частотник опрашивать чаще, чем раз в секунду.

Установил время опроса переменных 2000 мС.
Время на отказ 3000 мС.

Оставил схему на выходные.
В результате всё равно выпадает ошибка.

Как быть в данной ситуации? Опытным путём подбирать время опроса при котором не будет разрываться связь?

С преобразователями частоты других моделей, возможно других производителей, есть подобные проблемы? Поделитесь опытом, кто сталкивался. Какое время опроса переменных используется там (при каком общем количестве переменных).

[Arsie]

Цитата

Сообщение от Aiven

Установил время опроса переменных 2000 мС.
Время на отказ 3000 мС.

Оставил схему на выходные.
В результате всё равно выпадает ошибка.

Как быть в данной ситуации? Опытным путём подбирать время опроса при котором не будет разрываться связь?

С преобразователями частоты других моделей, возможно других производителей, есть подобные проблемы? Поделитесь опытом, кто сталкивался. Какое время опроса переменных используется там (при каком общем количестве переменных).

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

К сожалению, в упор не помню, что за частотник. Но может как раз ваша модель?

[tvf]

Цитата

Сообщение от Aiven

Как быть в данной ситуации?

1. Попытайтесь уменьшить трафик при обмене с ПЧ. Судя по вашей карте памяти у вас на ПЧ уходит аж 73 запроса. Для оперативного управления ПЧ вполне достаточно 10-15 переменных. Остальные большей частью нужны для начальной конфигурации ПЧ. Это можно сделать и вручную. Если ломает, то тогда уж запись/чтение по условию (время опроса =0, а далее из справки к лоджику). Интенсивность обмена резко упадет. А если и операцию записи будете проводить только там где надо, то еще больше снизите трафик.
2. Где выпадает ошибка? В ПЧ или контроллере? От единичных ошибок ни кто не застрахован, они могут быть от причин ни коим образом не связанных ни с собственно ПЧ, ни с контроллером, ни с линией связи. Ошибка связи должна фиксироваться при наличии критического количества ошибок связи (10-15). Ну и возможно сбрасываться автоматически при возобновлении обмена.
3. ПЧ как правило определяет ошибку связи при отсутствии обмена с мастером. Увеличте тайм-аут на ПЧ до 5 с.
4. Если уж и произошла ошибка связи на ПЧ, то он встает колом, но обмен по шине не прерывает. Сбросьте ошибку связи или любую другую по шине и работайте дальше.
5. По логике вещей, весь опрос всех переменных должен быть меньше чем период опроса. Так что не худо бы посчитать, какое минимальное время опроса предполагает скорость обмена, количество переменных, количество запросов. Только считать надо включая служебные задержки, как регламентируемые протоколом, так и самим ПЧ.

[Aiven]

Цитата

Сообщение от tvf

1. Попытайтесь уменьшить трафик при обмене с ПЧ. Судя по вашей карте памяти у вас на ПЧ уходит аж 73 запроса. Для оперативного управления ПЧ вполне достаточно 10-15 переменных. Остальные большей частью нужны для начальной конфигурации ПЧ. Это можно сделать и вручную. Если ломает, то тогда уж запись/чтение по условию (время опроса =0, а далее из справки к лоджику). Интенсивность обмена резко упадет. А если и операцию записи будете проводить только там где надо, то еще больше снизите трафик.
2. Где выпадает ошибка? В ПЧ или контроллере? От единичных ошибок ни кто не застрахован, они могут быть от причин ни коим образом не связанных ни с собственно ПЧ, ни с контроллером, ни с линией связи. Ошибка связи должна фиксироваться при наличии критического количества ошибок связи (10-15). Ну и возможно сбрасываться автоматически при возобновлении обмена.
3. ПЧ как правило определяет ошибку связи при отсутствии обмена с мастером. Увеличте тайм-аут на ПЧ до 5 с.
4. Если уж и произошла ошибка связи на ПЧ, то он встает колом, но обмен по шине не прерывает. Сбросьте ошибку связи или любую другую по шине и работайте дальше.
5. По логике вещей, весь опрос всех переменных должен быть меньше чем период опроса. Так что не худо бы посчитать, какое минимальное время опроса предполагает скорость обмена, количество переменных, количество запросов. Только считать надо включая служебные задержки, как регламентируемые протоколом, так и самим ПЧ.

Проблема решена. 5 пункт расставил всё на свои места.
Вылечил следующим образом:

1. Оставил только необходимые для управления ПЧ переменные. Итого 11 шт. В запросах = 14. Групповых 8.
Рассчитал необходимое время для индивидуальных запросов: 14*210 мСек+2 Сек = 5 Сек.
Оставил схему на 3е суток. Ошибка не появляется.

2. Эксперимент с первоначальным набором переменных.
Здесь рассчитал время не для индивидуальных запросов, а для групповых (при том же времени 210 мСек), т.е: 43*210+2 = 11 Сек.
Оставил схему на 3е суток. Ошибка не появляется.

Итог: Нужно было установить правильный период опроса переменных.

(Ответ на оставшиеся вопросы выше: Ошибка выпадала на панели ПЧ. Сбросить её можно было только перезагрузкой по питанию всего ПЧ. На кнопки управления не реагирует при ошибке.)

Всем Спасибо за участие.

[tvf]

Цитата

Сообщение от Aiven

Ошибка выпадала на панели ПЧ. Сбросить её можно было только перезагрузкой по питанию всего ПЧ. На кнопки управления не реагирует при ошибке.

Видимо прав был Arsie

Цитата

Для такой карты памяти и периода опроса 100 мсек контроллер буквально задалбывает частотника

Похоже процессор ПЧ просто вешался от слишком частых запросов. В следующий раз видимо надо подбирать более подходящий тип ПЧ. Периодичность опроса 5 с не айс.

[TIVAN2]

Буквально вчера мучился с подобной проблемой, на другом частотнике. Оказалось были не включены резисторы по концам линии. В режиме стоп связь с ПЧ не падает в режиме работа через некоторое время ПЧ отваливается хотя другие устройства на данной линии работали стабильно.