- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Оптимальный контроллер с Modbus TCP
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Доброе времени суток!
Проекты приходят), реализуются...появляются новые... пусть так и будет!
Вопрос к АСУТП инженерам - по поводу выбора оптимального контроллера с MODBUS (TCP желательное). Конечно...блин их много) зачем здесь такое спрашивать?, если сам не один раз уже настраивал в автомат режиме... НО
...уже 2020 год....а уже поднадоело, если честно, настраивать DB блоки отдельно для хранения, отдельно для параметризации протокола....отдельно FC встроенные драйверы...либо мудрить с %IW ...%QW...и т.д. и т.п.
Намного проще все хочется видеть....есть регистры (40001,40002...n)...есть коды функций(03/04....)....есть адреса (1..247)....
а есть контроллер?, где именно всё это можно..(.внимание самое главное слово!) ПРОСТО настроить и использовать (не мудрить с адресацией лишний раз). Как вариант - создать "таблицу" (карту модбас) и настройки...все!
Для примера имеется 30 TCP slave устройств, (карта MODBUS идентичная), нужно считать регистры на каждом устройстве. Но регистры считывать все нет необходимости, скажем нужные данные в 2044..2402..далее несколько бит в диапазоне 3012..3140...другие данные в 7540..7620..и таких очень много.....всего регистров считывать придется с 30 узлов около 9 000! На Семёнах 1200/1500 это труба делать( Modicon M251 какая-то кривость (проверял не моих рук ), Кодесис 3.5 кривость с другой стороны ( ).
Прошу не ругать...но к сожалению это правда! хотя кодить удовольствие с ними .
Если имеется контроллер с вариантом удобного обращения к регистрам Slave дайте пожалуйста знать!
С/у уважением Ваш коллега!
Проекты приходят), реализуются...появляются новые... пусть так и будет!
Вопрос к АСУТП инженерам - по поводу выбора оптимального контроллера с MODBUS (TCP желательное). Конечно...блин их много) зачем здесь такое спрашивать?, если сам не один раз уже настраивал в автомат режиме... НО
...уже 2020 год....а уже поднадоело, если честно, настраивать DB блоки отдельно для хранения, отдельно для параметризации протокола....отдельно FC встроенные драйверы...либо мудрить с %IW ...%QW...и т.д. и т.п.
Намного проще все хочется видеть....есть регистры (40001,40002...n)...есть коды функций(03/04....)....есть адреса (1..247)....
а есть контроллер?, где именно всё это можно..(.внимание самое главное слово!) ПРОСТО настроить и использовать (не мудрить с адресацией лишний раз). Как вариант - создать "таблицу" (карту модбас) и настройки...все!
Для примера имеется 30 TCP slave устройств, (карта MODBUS идентичная), нужно считать регистры на каждом устройстве. Но регистры считывать все нет необходимости, скажем нужные данные в 2044..2402..далее несколько бит в диапазоне 3012..3140...другие данные в 7540..7620..и таких очень много.....всего регистров считывать придется с 30 узлов около 9 000! На Семёнах 1200/1500 это труба делать( Modicon M251 какая-то кривость (проверял не моих рук ), Кодесис 3.5 кривость с другой стороны ( ).
Прошу не ругать...но к сожалению это правда! хотя кодить удовольствие с ними .
Если имеется контроллер с вариантом удобного обращения к регистрам Slave дайте пожалуйста знать!
С/у уважением Ваш коллега!
-
- эксперт
- Сообщения: 1025
- Зарегистрирован: 25 июл 2008, 10:06
- Имя: Леонид
- Страна: РФ
- Благодарил (а): 28 раз
- Поблагодарили: 104 раза
Оптимальный контроллер с Modbus TCP
DELTA V несколько выбивается из остального списка
Хард - это то, что можно швырнуть об стенку, а софт - это то, что можно лишь обматерить.
-
- эксперт
- Сообщения: 1602
- Зарегистрирован: 06 янв 2016, 19:45
- Имя: Петров В.Л.
- Страна: Россия
- город/регион: Красноярск
- Благодарил (а): 69 раз
- Поблагодарили: 185 раз
Оптимальный контроллер с Modbus TCP
Мне сильно ipc das в этом плане понравился. который с 3-м isagraf, просто заводишь в словаре переменных выходную или входную переменную, прописываешь в ней адрес modbus и в общем то все - читаешь или пишешь, Т.е. работаешь как с обычной переменной. Хотя это фишка не контроллера, а среды isagraf. Скажем у Gridex MST такая же схема работы.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Модульные системы Торнадо в продаже Gridex II имеется. Это просто мини промышленный ПК. А что имеется под MST ? поясните пожалуйста
-
- освоился
- Сообщения: 286
- Зарегистрирован: 15 сен 2016, 18:47
- Имя: Андрей
- Страна: Россия
- город/регион: Вологда
- Благодарил (а): 18 раз
- Поблагодарили: 73 раза
Оптимальный контроллер с Modbus TCP
У меня есть modicon premium, вполне неплохо modbus tcp работает. И настраивается просто.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
-
- эксперт
- Сообщения: 1602
- Зарегистрирован: 06 янв 2016, 19:45
- Имя: Петров В.Л.
- Страна: Россия
- город/регион: Красноярск
- Благодарил (а): 69 раз
- Поблагодарили: 185 раз
Оптимальный контроллер с Modbus TCP
MST это лейбла торнадовская. А gridex становится промышленным контроллером, когда в него заливают исполнительную систему Isagraf.
технология MST предполагает подключение модулей в/в по 2 каналам modbus TCP. Т.е. такое понятие как корзина или интерфейсная шина отсутствуют. Раньше они пользовались аналогичными адвантековскими контроллерами. Их на самом деле таких контроллеров много, называют PC based, даже у Сименса есть.
технология MST предполагает подключение модулей в/в по 2 каналам modbus TCP. Т.е. такое понятие как корзина или интерфейсная шина отсутствуют. Раньше они пользовались аналогичными адвантековскими контроллерами. Их на самом деле таких контроллеров много, называют PC based, даже у Сименса есть.
-
- эксперт
- Сообщения: 1025
- Зарегистрирован: 25 июл 2008, 10:06
- Имя: Леонид
- Страна: РФ
- Благодарил (а): 28 раз
- Поблагодарили: 104 раза
Оптимальный контроллер с Modbus TCP
Это можно сказать о любом контроллере Шнайдер Электрик.
PS. Premium снят с производства
Хард - это то, что можно швырнуть об стенку, а софт - это то, что можно лишь обматерить.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Исследуя просторы интернета в поисках необходимого нового решения для себя приметил несколько вариантов:
1 решение от компании Beckhoff промышленные компьютеры (CX9020-0115) с программным ПЛК TwinCAT 3 и ОС Windows Embeddent Compact 7.
https://www.download.beckhoff.com/downl ... CX9020.pdf
2 решение от гиганта автоматизации Advantech AMAX-5580
https://www.advdownload.advantech.com/p ... 191525.pdf
Второй вариант, по средней цене чуть выше 2 000 уе. , но включает в себе очень много коммуникационных возможностей (надо просто изучать ). Скорей всего на новый проект будем закладывать его (для Модбас TCP используем OPC ИНСАТ MODBUS UNIVERSAL MASTEROPC SERVER 60K). Кол-во тегов проекта возросло до 25 000 ! Проект должен быть предельно интересным! Что из этого получится покажет время
По PLC коммуникациям Модбас TCP вопрос остается также открытым для меня! Буду искать дальше идеальное решение для АСУТП!
1 решение от компании Beckhoff промышленные компьютеры (CX9020-0115) с программным ПЛК TwinCAT 3 и ОС Windows Embeddent Compact 7.
https://www.download.beckhoff.com/downl ... CX9020.pdf
2 решение от гиганта автоматизации Advantech AMAX-5580
https://www.advdownload.advantech.com/p ... 191525.pdf
Второй вариант, по средней цене чуть выше 2 000 уе. , но включает в себе очень много коммуникационных возможностей (надо просто изучать ). Скорей всего на новый проект будем закладывать его (для Модбас TCP используем OPC ИНСАТ MODBUS UNIVERSAL MASTEROPC SERVER 60K). Кол-во тегов проекта возросло до 25 000 ! Проект должен быть предельно интересным! Что из этого получится покажет время
По PLC коммуникациям Модбас TCP вопрос остается также открытым для меня! Буду искать дальше идеальное решение для АСУТП!
-
- освоился
- Сообщения: 286
- Зарегистрирован: 15 сен 2016, 18:47
- Имя: Андрей
- Страна: Россия
- город/регион: Вологда
- Благодарил (а): 18 раз
- Поблагодарили: 73 раза
Оптимальный контроллер с Modbus TCP
Возможно. Но я говорю о том, что потрогал руками :) У меня констроллер на unity, их ещё в somachine программируют, возможно там не все так удобно. Unity мне больше понравилась, чем tia portal и step7.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
пробовал! не очень понравилась реализация
очень часто приходится с Семеном работать. модбас хоть и функционально настраиваемый но не удобно все это.
На Unity Pro какими контроллерами с Modbus работали? Потянет 40 TCP соединений.... около 25000+-1000 регистров? интересует тайминг опроса? Сам на Unity Pro не приходилось работать, если скриншот по модбасу реализации сделаете и поделитесь опытом комментариями подробнее буду очень признателен !
-
- освоился
- Сообщения: 286
- Зарегистрирован: 15 сен 2016, 18:47
- Имя: Андрей
- Страна: Россия
- город/регион: Вологда
- Благодарил (а): 18 раз
- Поблагодарили: 73 раза
Оптимальный контроллер с Modbus TCP
У меня Unity Pro L 6, это довольно старая версия, контроллер modicon premium. С другими не работал. На LD и ST довольно удобно программировать. В 6 версии нет compare. У меня подключены 46 шт ПЧ и 35 шт удаленной периферии. Скриншот настройки см. выше, устройство добавляется одной строчкой. Все опрашивает без проблем.
Мне кажется, что в TwinCAT/CodeSys все намного сложнее, может, конечно, это мое предвзятое отношение к CodeSys.
ЗЫ У шнайдера неплохая техподдержка.
Мне кажется, что в TwinCAT/CodeSys все намного сложнее, может, конечно, это мое предвзятое отношение к CodeSys.
ЗЫ У шнайдера неплохая техподдержка.
-
- почётный участник форума
- Сообщения: 3559
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 253 раза
Оптимальный контроллер с Modbus TCP
Надо правильно это делать. Во-первых, перейти на оптимизированные (=современные) датаблоки. Используйте User data types (UDT), массивы (array[] of), если у вас повторяющиеся устройства. Я не очень понял, в чем заключается "труба".
В конце-концов всегда можно выполнить сериализацию-десериализацию, если приспичило.
Sergei_22, сформулируйте свою задачу, а не свое отношение к контроллерам.
Подсказка: начните с этого: "у меня n одинаковых slave-устройств, я хочу..."
-
- администратор
- Сообщения: 17476
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 749 раз
- Поблагодарили: 1278 раз
Оптимальный контроллер с Modbus TCP
Всё от рук и головы программиста зависит. ИМХО.
Сам вопрос бестолковый. Кто к чему привык, что попробовал - для того то и хорошее.
У всего на свете есть свои плюсы и минусы. А идеальных решений не бывает - бывают наиболее подходящие.
По вопросам работы Форума можно обратиться по этим контактам.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Ну кому как!
Бестолковый вопрос??? ))) Ха ...ну вы уважаемый на ОВне 10 000 тегов опросите)) а потом такие "бестолковые" ответы давайте! Если нечего предложить, то можно и не отвечать! Лучше предложите на каком контроллере Вам удобнее всего с модбасом было работать?!
Такой вопрос возникает не у меня одного, а у многих системных интеграторов при реализации распределенных систем. Если дело в опросе 10 RTU (100 - 2000 тегов) можно конечно
.Всё от рук и головы программиста зависит. ИМХО.
В моем конкретно случае - 500 Modbus RTU концентрируется в 30 Modbus TCP, а далее либо OPC либо контроллер. Если с OPC понятно все! то с контроллером - пока в поиске оптимального решения.
Оценил работу коммуникации DELTA V системы! подход простой и интересный! ценник правда системы впечатляет, но предложу заказчику! пока изучаю ограничения системы.
Отправлено спустя 21 минуту 15 секунд:
На сименсах давно работаю! вариант реализации Modbus их изучен вдоль и поперек! вопрос не в том, что это невозможно сделать на 1200 / 1500, а в том что это уже неудобно, трудозатратно. Неужели Вам это самому нравится...?...вариант где нужно собирать пакет, разбирать ответ..заменять адресацию...
Вопрос темы больше в выборе контроллера с ПО, более оптимизированного для коммуникации Modbus.
Ну если Вам так удобнее...)))
500 Modbus RTU заведены на концентраторы с Modbus TCP (таких 30 шт). Необходимо считать данные с 30 Modbus TCP c минимальной задержкой по времени. (В каждом слейве Modbus TCP данные лежат не последовательно в регистрах, например
Всего тегов (22 000 - 25 000). большая распределенная система. Через время будем модернизация и нужно будет еще такое кол-во добавить (но будет установлено доп контроллерное оборудование). Поэтому имеет смысл заложить удобный оптимизированный вариант сейчас, чтобы как у Семы 1200 не страдать. Сейчас выделил варианты: DELTA V, Modicon 251, AMAX 5580 с OPC Инсат.
Если у вас есть опыт опроса 20 000 тегов сименсом 1200 / 1500 по Modbus TCP, то прошу поделиться либо в личку или в этом вопросе!
Какова задержка полного опроса? Сколько времени примерно потребовалось на реализацию? Как система себя ведет при сбоях связи некоторых с некоторыми слейвами? Часто ли приходится перезагружать контроллер, если подвисает (к сожалению сталкивался на некоторых объектах (но может быть там так реализовали просто) )?
-
- администратор
- Сообщения: 4711
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 192 раза
- Поблагодарили: 336 раз
Оптимальный контроллер с Modbus TCP
Сергей, а удобство работы с модбасом - единственное требование к аппаратному/программному обеспечению? И вот так сразу DeltaV? Или что-то ещё важно?Sergei_22 писал(а): ↑20 июл 2020, 09:05 На сименсах давно работаю! вариант реализации Modbus их изучен вдоль и поперек! вопрос не в том, что это невозможно сделать на 1200 / 1500, а в том что это уже неудобно, трудозатратно. Неужели Вам это самому нравится...?...вариант где нужно собирать пакет, разбирать ответ..заменять адресацию...
После таких претензий к удобству работы - OPC Инсат??? Странно как-то.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Ну в этом суть вопроса и заключается! ну не менее важное требование это конечно время опроса!
Ну пока Delta V по крайней мере позволяет указывать прямой регистр и можно
работать по топологии (отзвонил технических специалистов где DELTA V - реально реализовано и работает. Прислали скриншоты опрос 12 000 регистров с 45 удаленных блоков (опрос 2,5 - 4 сек) на Газо-химическом комплексе без возможности управления (только отдельной медью)).звездой
Modicon 251 ранее был опыт с ним несколько раз (2000 - 2500 регистров). Надо конечно привыкать к их вариации. Но тоже все работает (опрос высокий 3 сек ). Конечно не совсем удобный вариант (мое мнение). У коллеги знакомого тоже опрос выше, нежели простым OPC опрашивать!
Codesys - ??? тут нужно быть его сторонником и только на нем работать с Modbus)) ....чтобы благодарить за удобство! про функционал это не относится
TwinCat 3 пока не изучал, но в планах есть в ближайшие дни поработать с их поддержкой, покодить в ПО.
Вроде претензий никаких не было))) Пытаюсь узнать новые решения и варианты работы с Modbus...как у других коллег реализовано, я не первый кто сталкивается с таким вопросом.
OPC Инсат пока реально работает на многих объектах и тянет без нареканий (7 000 регистров 12 слейвов) 0.6 -1,5 сек время задержки (только вчера подключался удаленно и смотрел). Есть другие объекты, но поменьше тегов - ни разу ни у кого не вылетело ПО и нет зависаний (плюс гибкие возможности и скрипт внутри).
вариант Kepserverex дороже в ценнике, работал с ним.
ЧТо можете Вы сказать по эксплуатации OPC Инсат или более успешный аналог OPC (в чем видите отличие).
-
- администратор
- Сообщения: 4711
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 192 раза
- Поблагодарили: 336 раз
Оптимальный контроллер с Modbus TCP
Тогда ложка дёгтя. Или две:
1. Предположим, вам надо на ходу что-то изменить в конфигурации OPC сервера. Тег ещё один добавить, например. Или ошибку найденную исправить. Последовательность действий:
- останавливаем сервис (тут обмен прекращается)
- разрегистрируем ПО, как сервис
- регистрируем, как приложение
- запускаем и работаем с конфигурацией. Если получится, потому что если использовали DCOM и какой-то клиент за это время обратился за данными, то сервер снова запустился. В общем, это некий эксперимент на скорость владения мышкой - быстро снять задачу и запустить другую :). Ну и пока работаем с конфигурацией - обмена данных нет.
- снова разрегистрируем приложение, регистрируем сервис, запускаем. Тут всё ппросто.
Это удобно?
Для сравнения в Kepserver: заходите в конфигуратор, вносите изменения, сохраняете. Всё.
2. Маленький, но важный нюанс: на случай выхода из строя оборудования нужна резервная копия конфигурации. Штатного способа копирования я не нашёл. Выискивание рабочего каталога и его копирование я не считаю штатным способом.
Хм... а ценник DeltaV не смущает?
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Есть такое!
Но этот нюанс важен когда необходим непрерывный процесс работы без возможности остановить тех процесс. На практике использую резервированные сервера с этими OPC: пока один работает, налаживаю резервный. По окончании ПНР итоговая копия на оба сервера + полный пакет документации заказчику, генподрядчику и себе в облако. Пока никто не обращался за моей версией с облака. Т.е. это в основном важно только на стадии ПНР.
Если использовать основной резервный серверы, и на каждом OPC Инсат, то опрос идет только на основном.
)) здесь удобно настроить опрос модбас регистров, устройств, переадресовать данные из одного протокола прямиком в другой, обработать скриптом математику данных регистра, опрос и запись; удобно провести диагностику по каждому узлу (определить кто самый медленный/быстрый и др.), удобно - один раз все по модбас карте настроить и больше не терять на это время! а если потом нет опроса, то проблема сети или железа.
KepServerEx хорош, и ценник его известен, использую если Заказчик готов за него платить! Но альтернативный OPC Инсат прекрасно себя зарекомендовал, а KepServerEx понятный, рабочий но подороже .
презентую разные рабочие варианты заказчику - пусть выбирают! я как всегда должен быть уверен, что мои решения будут 110% рабочими, безопасными, удобными и понятными. Не факт что они остановятся на Emerson. Поэтому в дальнейших поисках решения в этом вопросе ( месяц еще есть) потом проект рисовать и т.д.
-
- администратор
- Сообщения: 17476
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 749 раз
- Поблагодарили: 1278 раз
Оптимальный контроллер с Modbus TCP
я этим занимался когда Овна ещё в природе не существовало. Уважаемый. Так что тон претензий снижаем.
Я просил конкретных цифр, кол-ва тэгов, требований по времени, структура сети и т.п., потому что понятия "быстро" и "удобно" - это ни о чём и говорить не о чем без этого. Вы это сообщили частично и Александр ответил по делу, мне добавить к его ответам нечего.
По вопросам работы Форума можно обратиться по этим контактам.
-
- эксперт
- Сообщения: 1602
- Зарегистрирован: 06 янв 2016, 19:45
- Имя: Петров В.Л.
- Страна: Россия
- город/регион: Красноярск
- Благодарил (а): 69 раз
- Поблагодарили: 185 раз
Оптимальный контроллер с Modbus TCP
Действительно. Вы хотя бы предполагаемый цикл PLC озвучите. Одно дело цикл 10 мск и совершенно другое дело 2 секунды. Это как говорят в Одессе 2 большие разницы, которые кардинальным образом определяют спектр применяемых технологий.
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Без разницы как говорят в Одессе(
Коллеги прошу ЧИТАЙТЕ ВНИМАТЕЛЬНО ВОПРОС!
-
- знаток Eplan
- Сообщения: 260
- Зарегистрирован: 12 июн 2014, 06:17
- Имя: Мишкин Иван
- Страна: Россия
- город/регион: Самара
- Благодарил (а): 15 раз
- Поблагодарили: 70 раз
Оптимальный контроллер с Modbus TCP
Коллега, если Вы пришли сюда за ответами, прошу внимательно к ним относиться, как и к уточняющим вопросам собеседников.
Однако, если действительно требуется минимизировать время опроса и оптимизировать реакцию системы на ошибки, стоит работать на более низком уровне. Например, использовать библиотечную функцию обмена по Modbus (RTU - в первую очередь, обмен по TCP менее критичен в этом плане).
Попробуйте:
1. Спроектировать временнУю диаграмму обмена с учетом скорости обмена по шине RS485, объема передаваемых данных, необходимого количества запросов на каждое устройство, количества устройств в каждой линии RS485/Modbus RTU.
2. Спроектировать реакцию программы опроса на отсутствие ответа одного из устройств на линии и рассчитать возникающие из этого задержки.
3. Исходя из минимально необходимых для функций управления задержек получения тегов, сконфигурировать структуру сети и сформулировать требования на скорость обмена и максимальную задержку для концентраторов Modbus TCP и Modbus RTU.
4. Довести эти данные до сообщества и, возможно,
5. Получить толковый ответ в обмен на толковый вопрос.
500 контроллеров и 25000 тегов - это не очень большая система, по моим понятиям. Если программировать опрос параметрически (например привязкой блоков в Сименсе), то работа кропотливая и чреватая ошибками, да и только.
Однако, если действительно требуется минимизировать время опроса и оптимизировать реакцию системы на ошибки, стоит работать на более низком уровне. Например, использовать библиотечную функцию обмена по Modbus (RTU - в первую очередь, обмен по TCP менее критичен в этом плане).
Попробуйте:
1. Спроектировать временнУю диаграмму обмена с учетом скорости обмена по шине RS485, объема передаваемых данных, необходимого количества запросов на каждое устройство, количества устройств в каждой линии RS485/Modbus RTU.
2. Спроектировать реакцию программы опроса на отсутствие ответа одного из устройств на линии и рассчитать возникающие из этого задержки.
3. Исходя из минимально необходимых для функций управления задержек получения тегов, сконфигурировать структуру сети и сформулировать требования на скорость обмена и максимальную задержку для концентраторов Modbus TCP и Modbus RTU.
4. Довести эти данные до сообщества и, возможно,
5. Получить толковый ответ в обмен на толковый вопрос.
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Оптимальный контроллер с Modbus TCP
Не думали протокол поменять, например с Модбас-тср на МЭК-104? Концентаторы Модбас на шлюзы телемеханики Модбас/МЭК?
-
- здесь недавно
- Сообщения: 13
- Зарегистрирован: 20 окт 2019, 16:55
- Имя: Сергей
- Страна: Россия
- город/регион: Новосибирск
- Благодарил (а): 5 раз
Оптимальный контроллер с Modbus TCP
Что это может поменять?
1. Скорость обработки. Опрос будет быстрее?
2. Удобство при реализации?
3. Какой уровень принимать пакеты 104го - контроллер или OPC 104-client?
Подход интересный, но сразу порождает новые вопросы...
-
- не первый раз у нас
- Сообщения: 318
- Зарегистрирован: 31 окт 2017, 16:45
- Имя: Дмитрий
- Страна: Россия
- город/регион: Калининград
- Благодарил (а): 9 раз
- Поблагодарили: 82 раза
Оптимальный контроллер с Modbus TCP
1. МЭК-104 спорадический, при началной установке связи с шлюзами верхний уровень устанавливает время и делает общий опрос, а дальше данные от шлюзов передаются наверх только по изменению с меткой времени. Как такого опроса не существует, нет трафика по сети. Будет ли быстрее контроллер верхнего уровня обрабатывать только пришедшие изменения (если они вообще будут) в единицу времени или всю базу тэгов в случае с модбас?
2. Шлюзы предназначены для сбора данных с устройств с различным протоколом и создания базы без не нужных вам данных. Делая несколько модбас(или другого протокола) запросов устройств, выбрасывает из полученных ответов ненужное, складирует в базу нужное. ПО шлюзов обычно очень простое и гибкое, не нужно быть программистом АСУ.
3. Вы ведь выбрали контроллер верхнего уровня, например AMAX, + ОРС Сервер, меняете ОРС сервер модбас на МЭК.
Отправлено спустя 49 минут 52 секунды:
мэк-104 может вам не подойти, если используете управление аналоговыми выходами и управляете сразу несколькими дискретными выходами одновременно, все-таки телемеханический протокол
2. Шлюзы предназначены для сбора данных с устройств с различным протоколом и создания базы без не нужных вам данных. Делая несколько модбас(или другого протокола) запросов устройств, выбрасывает из полученных ответов ненужное, складирует в базу нужное. ПО шлюзов обычно очень простое и гибкое, не нужно быть программистом АСУ.
3. Вы ведь выбрали контроллер верхнего уровня, например AMAX, + ОРС Сервер, меняете ОРС сервер модбас на МЭК.
Отправлено спустя 49 минут 52 секунды:
мэк-104 может вам не подойти, если используете управление аналоговыми выходами и управляете сразу несколькими дискретными выходами одновременно, все-таки телемеханический протокол