Управление большим количеством преобразователей частоты Опции

[RoninX]

Добрый день, коллеги!
Кто нибудь сталкивался с управлением большого количества преобразователей частоты (ПЧ)?
Недавно был проект где требовалось реализовать управление 20 ПЧ Danfoss. Контроллер Siemens 1200. Реализовали последовательный опрос/управление ПЧ по Модбас RTU ибо управлять по 4-20 мА 20 ПЧ показалось не очень логичным решением. Опытным путем определили, что для надежного опроса (чтение слова состояния, запись командного слова, запись частоты) необходимо опрашивать с частотой 5Гц, т.е. по 200 мс на опрос каждого ПЧ. Итого: для полного опроса 20 ПЧ потребовалось 4с, что было приемлемо в рамках того проекта. Но как быть если нужно будет реализовать управление со 100 ПЧ? Для опроса всех частотников потребуется 20с, что может быть неприемлемо в рамках решаемой задачи. Кто сталкивался с такой задачей просьба поделиться опытом!
Спасибо!

Сообщение отредактировал RoninX - 28.2.2018, 19:03

[RoninX]

Добрый день, коллеги!
Кто нибудь сталкивался с управлением большого количества преобразователей частоты (ПЧ)?
Недавно был проект где требовалось реализовать управление 20 ПЧ Danfoss. Контроллер Siemens 1200. Реализовали последовательный опрос/управление ПЧ по Модбас RTU ибо управлять по 4-20 мА 20 ПЧ показалось не очень логичным решением. Опытным путем определили, что для надежного опроса (чтение слова состояния, запись командного слова, запись частоты) необходимо опрашивать с частотой 5Гц, т.е. по 200 мс на опрос каждого ПЧ. Итого: для полного опроса 20 ПЧ потребовалось 4с, что было приемлемо в рамках того проекта. Но как быть если нужно будет реализовать управление со 100 ПЧ? Для опроса всех частотников потребуется 20с, что может быть неприемлемо в рамках решаемой задачи. Кто сталкивался с такой задачей просьба поделиться опытом!
Спасибо!

Сообщение отредактировал RoninX - 28.2.2018, 19:03

[Se_Sib]

Добрый день, коллеги!
Кто нибудь сталкивался с управлением большого количества преобразователей частоты (ПЧ)?
Недавно был проект где требовалось реализовать управление 20 ПЧ Danfoss. Контроллер Siemens 1200. Реализовали последовательный опрос/управление ПЧ по Модбас RTU ибо управлять по 4-20 мА 20 ПЧ показалось не очень логичным решением. Опытным путем определили, что для надежного опроса (чтение слова состояния, запись командного слова, запись частоты) необходимо опрашивать с частотой 5Гц, т.е. по 200 мс на опрос каждого ПЧ. Итого: для полного опроса 20 ПЧ потребовалось 4с, что было приемлемо в рамках того проекта. Но как быть если нужно будет реализовать управление со 100 ПЧ? Для опроса всех частотников потребуется 20с, что может быть неприемлемо в рамках решаемой задачи. Кто сталкивался с такой задачей просьба поделиться опытом!
Спасибо!

Это же от ситуации зависит. Какие-то модели могут и быстрей данные отдать/принять, чем за 200мс, какие-то нет, опять же скорость от протяженности сети Rs485 зависит. Для быстродействия лучше переходить на Ethernet, модели ПЧ с Ethernet или карты коммуникационные с Ethernet(если они существуют для нужной модели).

[Chabol]

В случае, когда быстродействие опроса критично, а доступны только интерфейсы RS485, то можно разбить весь пул слейвов (частотников) на несколько сетей, а мастер должен иметь необходимое кол-во портов RS485, либо каждая сеть должна иметь преобразователь RS485 в Ehternet и мастер уже будет вести опрос по Ehternet.
Тогда скорость опроса всей сети увеличится примерно в то кол-во раз, на сколько сетей разбит весь пул (при равномерной разбивке) при прочих равных условиях.

Как вариант, это введение нескольких мастеров в Ваше решение, когда скорость опроса мастерами своих слейвов Вас устроит. А между мастерами, при необходимости, образовать обмен данными, либо с верхним уровнем.

Сообщение отредактировал Chabol - 28.2.2018, 21:58

[Andrew_2610]

Modbus rtu - тупик. Надо использовать Modbus TcP. У Шнайдера, например, atv600/900 в базе уже имеют modbus tcp.
Ну и про всякий удаленный доступ не забывайте.

В случае, когда быстродействие опроса критично, а доступны только интерфейсы RS485, то можно разбить весь пул слейвов (частотников) на несколько сетей, а мастер должен иметь необходимое кол-во портов RS485, либо каждая сеть должна иметь преобразователь RS485 в Ehternet и мастер уже будет вести опрос по Ehternet.
Тогда скорость опроса всей сети увеличится примерно в то кол-во раз, на сколько сетей разбит весь пул (при равномерной разбивке) при прочих равных условиях.

Как вариант, это введение нескольких мастеров в Ваше решение, когда скорость опроса мастерами своих слейвов Вас устроит. А между мастерами, при необходимости, образовать обмен данными, либо с верхним уровнем.

Вы меня извините - буду прямолинеен. Это хрень чистой воды. Не обижайтесь. Тут ведь не работа, где надо авторитет блюсти.

[Гость_wild_*]

Вы реализовали проект в надежде что никогда в сети Modbus не появится сбоев? Но как показывает практика иногда они случаются. Какой таймаут у вас при опросе ЧРП контроллером в случае отсутствия ответа?
Я бы порекомендовал использовать контроллеры B&R серии System X20 и их же частотники AcoposInverter P74 связав их штатной сетью Powerlink (Ethernet реального времени).

[Andrew_2610]

Что за power link такой? Реального времени? Прям из рекламы.

[Se_Sib]

Стало интересно, измерил время опроса ПЧ Altivar 630 контроллером Modicon M251 по Modbus RTU(RS485) и Modbus TCP(Ethernet). Использовал 23 функцию запись/чтение одним запросом, 10 регистров на чтение и столько же на запись. По Modbus RTU обмен проходит за 40мс при скорости 38 400 и за 55 мс при скорости 19 200. По Modbus TCP за 15-20мс. На контроллере доступно 16 TCP сокетов, 8 для Modbus server и 8 для Modbus client. Если взять с запасом, допустим 40мс на опрос устройства по Modbus TCP, то 100 ПЧ контроллер опросить за 100/8*40=500мс.

Сообщение отредактировал Se_Sib - 1.3.2018, 10:31

[Andrew_2610]

тут речь о детерминизме идет. Пакеты по езернету не доставляются в гарантированное время. Таймаут это несколько из другой оперы.
Но средства для гарантированной доставки есть. И необязательно покупать дорогие би энд эр.

[RoninX]

Modbus rtu - тупик. Надо использовать Modbus TcP. У Шнайдера, например, atv600/900 в базе уже имеют modbus tcp.
Ну и про всякий удаленный доступ не забывайте.

Посмотрел ценник на ATV, дороговато. А Вы не в курсе есть ли у Овен или Danfoss ПЧ с поддержкой Modbus TCP?

Вы реализовали проект в надежде что никогда в сети Modbus не появится сбоев? Но как показывает практика иногда они случаются. Какой таймаут у вас при опросе ЧРП контроллером в случае отсутствия ответа?
Я бы порекомендовал использовать контроллеры B&R серии System X20 и их же частотники AcoposInverter P74 связав их штатной сетью Powerlink (Ethernet реального времени).

Таймоут 350 мс. Если в течение 350 мс не будет подтверждения об успешном опросе, то осуществляется переход на следующий ПЧ, т.е. две попытки и потом уже перейдет на следующий.

Стало интересно, измерил время опроса ПЧ Altivar 630 контроллером Modicon M251 по Modbus RTU(RS485) и Modbus TCP(Ethernet). Использовал 23 функцию запись/чтение одним запросом, 10 регистров на чтение и столько же на запись. По Modbus RTU обмен проходит за 40мс при скорости 38 400 и за 55 мс при скорости 19 200. По Modbus TCP за 15-20мс. На контроллере доступно 16 TCP сокетов, 8 для Modbus server и 8 для Modbus client. Если взять с запасом, допустим 40мс на опрос устройства по Modbus TCP, то 100 ПЧ контроллер опросить за 100/8*40=500мс.

У нас был 1 регистр на чтение и два регистра на запись. Номера регистров не последовательные. Пришлось опрашивать последовательно по три раза каждый частотник поэтому и получилось примерно 150 мс на опрос одного частотника. У Шнайдера поддержка Modbus RTU реализована намного лучше, чем у Сименса.

Сообщение отредактировал RoninX - 1.3.2018, 13:47

[Andrew_2610]

А овно думаете дешевле? Это ведь данфос с лейблой Овна.

[Se_Sib]

Посмотрел ценник на ATV, дороговато. А Вы не в курсе есть ли у Овен или Danfoss ПЧ с поддержкой Modbus TCP?

У нас был 1 регистр на чтение и два регистра на запись. Номера регистров не последовательные. Пришлось опрашивать последовательно по три раза каждый частотник поэтому и получилось примерно 150 мс на опрос одного частотника. У Шнайдера поддержка Modbus RTU реализована намного лучше, чем у Сименса.

До 15кВт, есть серия ATV320, с картой Modbus TCP немного дешевле будет чем ATV630. У этих ПЧ по умолчанию CANopen интерфейс на борту, можно его использовать.
При том, что CANopen это шина, действительно реального времени, но тогда нужен ПЛК с CANopen и архитектура сети как у RS485, последовательная. Шнайдоровские ПЛК до 63 устройств на шине CANopen поддерживают.
 CANopen.jpg ( 62,63 килобайт ) Кол-во скачиваний: 17


По адресам Modbus у Алтиваров удобно, что все основные рядом лежат. C 8501 слово управления, задание частоты... С 3201 состояние, выходная частота, ток, напряжение, мощность, крутящий момент..... И у всех серий(кроме ATV212) ПЧ карта адресов общих параметров, та же самая.
А для версий с Ethernet и карт Ethernet, есть альтернативный Modbus Server, доступный по другому Id адресу, с своей таблицей адресов к которым можете привязывать желаемые параметры.
 ATV_IOprofile.jpg ( 370,96 килобайт ) Кол-во скачиваний: 31

[Chabol]

Modbus rtu - тупик. Надо использовать Modbus TcP. У Шнайдера, например, atv600/900 в базе уже имеют modbus tcp.
Ну и про всякий удаленный доступ не забывайте.



Вы меня извините - буду прямолинеен. Это хрень чистой воды. Не обижайтесь. Тут ведь не работа, где надо авторитет блюсти.

Искренне не понял про "хрень" и "авторитет". С чисто технической стороны такой подход мной использовался не единожды и показывал себя с позитивной стороны.
Прошу более детально дать разъяснения.

[Гость_wild_*]

Что за power link такой? Реального времени? Прям из рекламы.

Идея Powerlink это использование Ethernet c дополнительным функционалом квантования времени. Передача осуществляется циклически при этом вначале передаются критически важные данные (изохронная фаза), а некритичные данные передаются в асинхронной фазе. Время цикла около 200 мкс, девиация менее 1 мкс.
 2018_03_02_21_43_15.jpg ( 71,02 килобайт ) Кол-во скачиваний: 16


В качестве демонстрации управление приводами от B&R
робот CableEndy

[serge197a]

у меня есть опыт работы на 2-х полностью роботизированных немецких заводах в должности инженера электроника.
для управления ПЧ (более 200 на каждом заводе) использовались сетевое и смешанные системы.
при сетевом- использовался профибас к каждому ПЧ сименс. Кстати ПЧ сименс сейчас примерно в цену данфос можно найти.
при смешанном, с базовых станций на ET200(коммуникационный модуль, тк сети предприятия очень большие) подавалось задание, которое переводилось через модули вывода в дискретно аналоговый сигнал (пуск-стоп дискретный, частота 4-20ма)
В вашем случае я бы поставил модули ввода-вывода изернет, если быстродействие критично.
По маске можно одним словом(или DW) передавать команду в модуль вывода для всех ПЧ, аналогично и с частотой.
Лично я при проектировании небольших систем обычно передаю частоту на ПЧ по RS485 из порта ПЛК на прямую, а пуск-стоп, через DI контроллера или модуля ввода-вывода.
Запись команд сделайте по изменению. В этом случае Вам потребуется меньше времени, не нужно ждать 200мс.

Обратите внимание на качество линии RS485.
Используйте только специальный кабель, а не простую витую пару.
Обязательно ставьте терминальные резисторы в первом и последнем устройстве.
Только последовательное включение. Ни каких "звездой".

Сообщение отредактировал serge197a - 3.3.2018, 10:14

[mr_Frodo64]

Какие роботы?!? Какие специальные кабели? Чел на коленке систему запускает исходя из того, что есть, а вы ему про красивое будущее, где космические корабли бороздят просторы вселенной.
И думается, что управление по дискретно-аналоговому интерфейсу вы зря откинули. В Вашем случае - это самое оно! И понятно и быстро. По цене - спорно.

[WRybkin]

Таймоут 350 мс. Если в течение 350 мс не будет подтверждения об успешном опросе, то осуществляется переход на следующий ПЧ, т.е. две попытки и потом уже перейдет на следующий.

По стандарту на Modbus RTU таймаут на скоростях 19200 и более около 3,5 мсек. Любопытно, кто из производителей умудряется ухудшить стандартное требование в 100 раз и называть свой протокол Modbusом?

[Se_Sib]

И думается, что управление по дискретно-аналоговому интерфейсу вы зря откинули. В Вашем случае - это самое оно! И понятно и быстро. По цене - спорно.

100 кабелей по 4-5 жил каждый от ПЛК до ПЧ и 100 аналоговых сигналов в конфигурации ПЛК, ещё расстояние может быть более 200-300 метров....
У того же S7-1200, что использовал RoninX, модуля расширения AO максимум 4 канала, около 330 евро за 1 модуль и в конфигурации столько вряд ли потянет.
Тогда уж лучше вариант от Chabol, на S7-1200 можно до 4 каналов RS-485, где-то по 110 евро за модуль, по 25 устройств в сети будет.

[Гость_wild_*]

По стандарту на Modbus RTU таймаут на скоростях 19200 и более около 3,5 мсек. Любопытно, кто из производителей умудряется ухудшить стандартное требование в 100 раз и называть свой протокол Modbusом?

Вы что-то путаете, это не таймаут.
 Modbus.jpg ( 136,55 килобайт ) Кол-во скачиваний: 32


Вероятно Вы слышали про минимальную паузу между запросом Master и ответом Slave которая должна быть не короче 3,5 символов. Больше можно, меньше нельзя.

Сообщение отредактировал wild - 4.3.2018, 12:22

[По самые по...]

Вы что-то путаете, это не таймаут.
 Modbus.jpg ( 136,55 килобайт ) Кол-во скачиваний: 32


Вероятно Вы слышали про минимальную паузу между запросом Master и ответом Slave которая должна быть не короче 3,5 символов. Больше можно, меньше нельзя.

Всё правильно! Вот см. стр.12

[serge197a]

Какие роботы?!? Какие специальные кабели? Чел на коленке систему запускает исходя из того, что есть, а вы ему про красивое будущее, где космические корабли бороздят просторы вселенной...

У данфоса максимальное время задержки ответа 25мс(см. ИЭ).
из-за не правильной организации связи автор и получает свои 200мс.
т.е. идут повторные команды и ответы.
минимальное-10мс.
т.е. при грамотном подходе можно сделать в 20 раз быстрее.
(практически тоже)

Сообщение отредактировал serge197a - 4.3.2018, 14:10

[Se_Sib]

У данфоса максимальное время задержки ответа 25мс(см. ИЭ).
из-за не правильной организации связи автор и получает свои 200мс.
т.е. идут повторные команды и ответы.
минимальное-10мс.
т.е. при грамотном подходе можно сделать в 20 раз быстрее.
(практически тоже)

И какое время цикла(от запроса до получения данных) обмена на практике с ПЧ Данфос(какая модель?), на какой длине сети, с какой скоростью и с каким ПЛК?
На примере S7-1200, правда я давно не работал с Siemens, но помню, что раньше в Tia Portal время цикла программы S7-1200 по умолчанию было установлено 100мс, а для работы с протоколом Modbus использовались специальные ФБ, т.е. инициализация опроса из цикла программы и на сколько можно уменьшить время цикла зависит от нагрузки на цп. Обязательная задержка между фреймами(о чем спорят коллеги выше) + время на передачу данных+задержка ПЧ на ответ+время обратной передачи данных от ПЧ и по новой для следующего устройства.

[serge197a]

считайте:
20ПЧ - 20 таймаутов, пусть по мax 25мс= 0.5с
реально от 10мс.
19200/16/2=600слов за 0.5сек
1 пакет округлим до 20 байт (запрос-ответ) с запасом,
получаем 30, т.е. остается время на простой. реально на скорости 19200 раз в секунду всеми ПЧ управлять.
Нужно ли всеми сразу? - скорее всего нет,т.к. целесообразнее записывать данные по изменению.

время цикла s1200 для коммуникационного контроллера
Количество активированных
ведомых устройств + 1) х 154 мкс
т.е. менее 0.4 мс на 20ПЧ.
Само время цикла программы обычно до 10-15мс максимум,
в очень больших программах с несколькими ПИД и пр. вычислениями.
но коммуникации работают вне цикла программы.
так, что тут проблема только в правильности организации сети.

Сообщение отредактировал serge197a - 4.3.2018, 16:54

[WRybkin]

Вы что-то путаете, это не таймаут.
 Modbus.jpg ( 136,55 килобайт ) Кол-во скачиваний: 32


Вероятно Вы слышали про минимальную паузу между запросом Master и ответом Slave которая должна быть не короче 3,5 символов. Больше можно, меньше нельзя.

Лет 15 назад работал программистом 8-битных микроконтроллеров AVR и в том числе писал подпрограмму для modbus slave. Невнимательно прочитал описание протокола и сделал таймауты между запросом и ответом по 100 мкс. С тех пор всегда удивляюсь мастерству программистов, которым не хватает рекомендованных в указанном Вами документе на странице 1,75 мсек. Ещё удивляюсь, когда при длинах кабелей менее 200 метров используют скорости ниже 57600бод. На этих скоростях пересылка запроса и ответа обычно укладывается в 1-2мсек.

Сообщение отредактировал WRybkin - 4.3.2018, 18:57

Прикрепленные файлы

 Time.png ( 29,59 килобайт ) Кол-во скачиваний: 13

 

[manjey73]

ставим каждому ПЧ бескорпусной Ethernet-RS485 и не делаем мозг. То есть экономим на ПЧ и прочем без всяких ограничений.
Но получаем вполне рабочую сеть по скорости. И нафик никакие B&R не нужны.

По цене такие преобразователи стоят смешных денег даже если взять Moxa

[WRybkin]

По цене такие преобразователи стоят смешных денег даже если взять Moxa

Интересно, какие деньги люди считают смешными? Лично я, в зависимости от обстоятельств, от 5 до 500 рублей. Хотя, если деньги не мои, готов довести сумму до 3-5 тысяч.

[mr_Frodo64]

Ну результат получается иногда вот такой, какой получился... Где-то было что-то упущено на каком-то этапе. Скорее всего заказчик критически зажал бюджет ))) и выбор пал на не совсем опытного в плане построения сетей реализатора. Отсюда и был мной упомянут архаичный, но понятный вариант аналогового управления. Хотя и в нём можно накосячить... (и разговор шел не о 100, а 20 аппаратах) 100 это непонятная перспектива...

Сообщение отредактировал mr_Frodo64 - 4.3.2018, 21:51

[Se_Sib]

считайте:
20ПЧ - 20 таймаутов, пусть по мax 25мс= 0.5с
реально от 10мс.
19200/16/2=600слов за 0.5сек
1 пакет округлим до 20 байт (запрос-ответ) с запасом,
получаем 30, т.е. остается время на простой. реально на скорости 19200 раз в секунду всеми ПЧ управлять.
Нужно ли всеми сразу? - скорее всего нет,т.к. целесообразнее записывать данные по изменению.

Вот это реально, улучшение в 4 раза, но не в 20 раз от 200мс. Я удивился, что по 10 мс на устройство с учетом задержек между фреймами. Вот и спросил, на практике сколько получается.

У нас был 1 регистр на чтение и два регистра на запись. Номера регистров не последовательные. Пришлось опрашивать последовательно по три раза каждый частотник поэтому и получилось примерно 150 мс на опрос одного частотника. У Шнайдера поддержка Modbus RTU реализована намного лучше, чем у Сименса.

Т.е. если можно 1 запросом, он и без наших советов улучшит время в 3 раза.

Записывать данные по изменению - вы правы, а вот опрашивать состояние ПЧ, нужно всех, с какой-то периодичностью. И тут, либо вы используете 23 функцию и все же читаете/пишите периодами, либо вставляете функции записи в циклический процесс опроса, либо вставляете функции записи между циклами опроса.

Данные из документации и математика это хорошо, вот только на практике цифры редко совпадают, из-за технических особенностей устройств.
Выше я приводил цифры для связи ПЧ ATV630 и ПЛК M241, обмен по 23 функции, 10 регистров на запись и 10 на чтение за 55 мс при скорости 19 200... это при цикле ПЛК 5мс и времени задержки между фреймами 10мс.
Обмен использовал ациклический, т.е. инициализация обмена с помощью ФБ из программы, и в это время входит погрешность +1 цикл(5мс), а так же время обмена данными с коммуникационным ядром процессора на ПЛК +1..2мс, остальное время это трансфер на скорости 19 200 и время обработки запросов и отдачи данных самим ПЧ.
При времени цикла ПЛК 1 мс и задержки между фреймами 3мс(ниже, не дает установить конфигуратор ПО для скорости 19200) получаем время 43-53мс.
Если взять необходимый минимум в 3 регистра, чтение состояния ПЧ, запись команды управления и задание частоты, выходит 27-33мс.

[manjey73]

WRybkin цена Moxa смешная при разнице в цене ПЧ, ну а если нет таньге на Moxa есть USR китайские, работают аналогично а стоят меньше. Проблема только с покупкой может оказаться. И опять же, можно разбить на сектора а не на каждый ПЧ лепить.

[serge197a]

зачем в 1 устройство записывать 10 регистров 10 командами, можно использовать групповую запись.
для чего все время читать?
можно вывести аварию на DI контроллера. к примеру.
при чем тут цикл плк, альтивар и м241?
у сименса (да и не только, а почти у всех) коммуникации вынесены в сопроцессор,
а у него время я выше писал-микросекунды, можно не учитывать.

[Se_Sib]

зачем в 1 устройство записывать 10 регистров 10 командами, можно использовать групповую запись.
для чего все время читать?
можно вывести аварию на DI контроллера. к примеру.
при чем тут цикл плк, альтивар и м241?
у сименса (да и не только, а почти у всех) коммуникации вынесены в сопроцессор,
а у него время я выше писал-микросекунды, можно не учитывать.

Кому-то не зачем, а кому-то нужно по мимо задание частоты и управления, задавать разгон, торможение, задание ПИД, коэффициенты и другие параметры..... читать состояние ПЧ, код аварийных событий, ток, напряжение, выходную частоту.... да что угодно, что потребует заказчик и что требуется исходя из технологии.
23 функция это и есть групповая запись и запрос на чтение одной командой, а не 10 командами, это быстрей чем 3 функция + 16, вызванные последовательно.
Читать не все время, а с какой-то периодичностью, чтоб как минимум знать состояние ПЧ...стоп, работа, неисправность....
Алтивар и m241 абсолютно не причем, просто пример реальной оценки обмена с учетом нюансов устройств, а не данных из документации.
Конечно время коммуникационного сопроцессора не значительно, вот только есть ещё время обмена между этим сопроцессором и ЦП, оно тоже незначительно + другие нюансы железяк с обеих сторон, в сумме дают некую задержку.
Просто любопытство реальных цифр, никаких претензий.