Comments 36
Молодцы Siemens, могли бы конечно и раньше. Долго они добавляют протоколы, например Modbus TCP в контроллерах S-300 только отдельными платными билиотеками, совсем не дешевыми.
Сейчас мне больше B&R нравятся, функционал мощнее намного, протоколы Modbus TCP, OPC UA - по умолчанию. Можно залить в PLC математическую модель (SimIntech, Simulink, MapleSim или просто тандарта FMI).
Про Modbus TCP для трехсотой серии я в течении ближайших 2-4 недель планирую написать заметку в моем любимои стиле "автоматизация для бедных" )
В Российских компанияю любят экономить ))) "автоматизация для бедных" - это точно. Я работотал с DirectLogic, Rockwell - все на борту по умолчанию. Разный подход, американский и европейский.
Концепция уже и у S поменялась. Для современных 1200/1500 библиотеки и TCP, и RTU - бесплатные и встроенные.
В Роквелле убрали 485 порт и модбас "по умолчанию" вместе с ним
А Прософт-модули для модбаса там еще дороже, чем у Сименса
На мой взгляд, как раз американские компании самые жлобские. "Жлобее" Rockwell разве что только Emerson.
В плане документации и софта Siemens IADT самые лучшие. А вот поддержка HVAC продуктов хромает на обе ноги - всё закрыто, документацию зачастую так просто не найти.
Как то не вяжутся SIEMENS и автоматизация для бедных.
С частотниками Вы тоже предлагаете через сокеты общаться? )
Что-то Вы все в кучу смешали.
Модбас не нужен, есть сокеты. Но модбас работает через сокеты. А в частотниках ПЛК встраивают для этого.
Вспомните модель ISO OSI. Да, многие ее не любят, но в качестве наглядного пособия - подойдет. Modbus TCP - это прикладной уровень модели. То есть, четко оговоренный формат передачи пакетов. Вы зачем-то приплетаете уровень TCP, то есть - транспортный. Можно ли организовать обмен между ПЛК на транспортном уровне? В ряде случаев можно. А для некоторых целевых систем, т.н. ПЛК или смарт-реле, такой функционал недоступен. Зато есть стандартизированный и общепринятый протокол. В данном случае - Modbus TCP.
Главное тут - общепринятость и стандартзированность.
чтобы организовать modbus/tcp, нужно точно иметь TCP. Как его не "приплетать" :)?
Вы говорили про работу через сокеты. То есть, непосредственный обмен через TCP или UDP порт? И для этого непосредственного обмена со стороны целевой системы (ПЛК или смарт-реле) недостаточно просто иметь поддержу протокола TCP/IP на уровне операционной системы, необходимы функции или функциональные блок соединия, чтения, записи и т.д.
Чтобы организовать modbus/tcp - нужно этот modbus с обеих сторон поддержать.
Конечно. Так и строится нормальная система АСУ ТП, на согласованности протоколов.
Была задача брать данные из ёкагавы и отправлять в TSDB Osi/PI SDK. Для простоты выбрал python.
Самописный опрос промышленного девайса с компа - это частный, очень частный случай.
По какому протоколу работала йокка? Вы сами описывали протокол или брали готовую библиотеку?
Сокеты это же не протокол. Всё равно необходимо установить правила обмена информацией.
Драйвера, позволяющие получить объектную модель контроллера, такое есть. Называется OPC протокол. Современная спецификация OPC UA встраивается в контроллеры. Но ещё не все контрооллеры её поддерживают.
Ох напрограммировал я в свое время контроллеров Logo! Очень интересно было. Начиная автоматикой для гаража в коттедже и заканчивая компонентами городских подстанций! Однажды при помощи модуля и 2 дополнений написал программу управления пожарной сигнализцаии на 16 этажей! Получилось дешевле чем на релюшках, но не взяли в массовое производство из-за того, что сборщики взбунтовались, так как не было сложной обвязки и они получали в разы меньше на сборке данных шкафов )
Детально написаны изыскания автора на "тему" ) Мне был интересен сам факт появления ModbusTCP на LOGO, т.к. в некоторых задачах микроавтоматизации действительно этот девайс вне конкуренции по сочетанию бренд-качество-цена-функционал. Теперь еще и с модбасом. Спасибо!
У ОВЕН вышел ПР103 с поддержкой Modbus TCP, пример управления из нескольких мест, в том числе и с панели оператора недавно тестировал, все ОК:
Когда Овен дороже Сименса....
Сравнение не прямое, и Овен только зарелизился, но Лого и аналогам уже лет 15, баги отловили...Выбор так себе
А как Вы сравнивали какой вариант дороже?
Я из стать не очень понял тип реле лого, по скриншотам только косвенно увидел 4 дискретных входа и 4 дискретных выхода, полный набор периферии мне не известен у лого.
Рассмотренный выше экземпляр ОВЕН ПР103 имеет 16 дискретных входов, 8 универсальных аналоговых, которые так же могут быть дискретными, 16 выходов, порт RS485 встроенный и возможность установить ещё один RS485, и встроенный облачный сервис. Это если коротко. Теперь можно говорить о цене.
Недавно пришлось делать проект: logo8+Kinco по MB TCP. Откровенно говоря о лого сложилось такое себе впечатление. Софт тупой и глючный. Сам лого нормально работает только мастером. Если перевести в слэйв пользовательская программа, перестаёт выполняться. Вроде так и положено. Но если поупражняться в загрузкой проекта подольше можно добиться слэйв режима с работой программы. Техподдержка у Siemens по Logo тоже никакая. В общем тот же ПР200 и то интереснее.
Кстати, задачка знатокам. Как сохранить в энергонезависимой памяти Logo целочисленную переменную считанную с пвнели через MB ? Например мне необходимо было задавать с панели в реле значение максимальных и минимальных обротов. И хотелось, что бы эти данные хранились именно в лого, ибо так надёжнее. Увы. Разобраться не смог, техподдержка тоже не подсказала как быть. В итоге пришлось хранить параметры в панели управления. Может кто тут подскажет? )
В моем примере Logo работает сервером (слейвом) модбаса, и ППО при этом функционирует. Возможно, у Вас совпали изменения в ППО и добавление функционала Modbus TCP Server, но гадать я не буду.
Про реманентность данных в логах, увы, не подскажу.
Блин, а вот сейчас обидно было! ))
Прошу прощения, увидел вашу статью глубокой ночью и не особо вчитывался.
Кажется я копал не в ту сторону... я делал проект во вкладке NetworkProject и переключал лого в онлайн настройках в режим ведомого. На что он ругался и прикаждой загрузке прошивки просился обратно в режим мастера.
А нужно было копаться Diagram Mode. И делать всё по аналогии с вашим проектом.
Жаль теперь нет "железки" на руках.
Спасибо вам за вашу статью! Теперь мое мнение о Лого немного улучшилось.
В свое оправдание цитирую запрос в техподдержку и их ответ:
Есть возможность назначить в сети LOGO! как Slave? Нужна подчинённость операторской панели. Сейчас после загрузки программы система запрашивает переход в Master.
Режим ведущий-ведомый предполагает, что ведомое лого это просто безмозглый вход-выход присоединённый к ведущему лого. Собственной программы у такого прибора нет. Доступ только к I и Q областям. Протокол зашит в Лого и описан только применительно к связке LOGO-LOGO. Для панелей такой режим незадокументирован. Работа с операторской панелью это частный случай клиент-серверной связи через S7 функции. Для этого Лого должно иметь программу а это автоматически отсекает режим «ведомый».
Я бы приаттачил сюда сейчас картинку с престарелым мастером кунг-фу с поднятым вверх указательным пальцем, но мне, откровенно, лениво. Ведь надо вначале разобраться, что ты делаешь, потом понять, что ты делаешь не так, а лишь потом делать далеко идущие выводы.
Ладно, ворчать закончил )
Все верно, Вы копали не в ту сторону. Если я переведу свое реле FS4 в ведомый режим, то он из реле превратиться в безмозглый, как ловко подметили мои коллеги из саппорта, интерфейсный модуль для ведущего реле, а его (ведомого) программа не будет выполняться.
Но стоит лишь вернуть его в режим мастера, как работа возобновляется.
И совершенно неважно, какой тип проекта Вы применяете, отдельные диаграммы или сетевой проект. И там, и там необходимо лишь сконфигурировать соответствующее соединение. Сетевой проект в этом отношении даже более нагляден.
С учетом того, что Вы юзали панель, Вам надо было сконфигурировать логу! в качестве сервера Modbus или S7... в зависимости от того, какой протокол понимает сама панель.
Работает ли RTU over tcp, т.е. через конвертер?
Siemens Logo! и Modbus TCP