Увы, но ничего приводного под рукой нет, проверить не на чем. С учетом того, что Starter - это классическая, а не портальная софтина, в проект портала она не интегрируется, и в статье указано, как склеить эти две среды.
Однако, тема S7 routed connection раскрыта не полностью. Почему-то при рассмотрении таких соединений приводят в пример соединения ПЛК - ПЛК, ПЛК - HMI. А как насчёт соединений ПЛК - ПЧ (например, G120)?
Вопрос интересный, но я не припоминаю, чтобы наши частотники общались по S7. Профинет, профибус, даже модбус RTU для V20 - запросто. А вот S7, хоть убей, не помню. Поинтересуюсь у коллег для повышения уровня самообразованности.
Коллеги подскажите, может кто знает, в серии S7-1200 функция роутинга вообще есть? В принципе? Искал на сайте Сименса но так и не нашёл определённого ответа. Или может в 1200 серии есть какая-то особенность при настройки связи с приводами?
Можно. Через внутренний тег панели, который в свою очередь привязывать в анимации. Не обязательно именно "возвращать значение" скриптом, просто в его теле писать значение в переменную.
Невидимый на фейсплейте (и его производных) iofield с event'ом на process value change?
Эм, как бы, TIA Portal WinCC Basic/Comfort/Advanced давно позволяет легко копировать проекты между HMI-панелью и АРМ в обе стороны
И где в этом перечне взрослые скады? Первое и второе - это строго панели, третье - одиночная станция с функционалом панели comfort. Копи-паст из проектов WinCC Pro в панельные крайне ограничен. Копи-паст из классической WinCC в панели - а он есть вообще?
Главное отличие Unified в использовании движка HTML5 и SVG для визуализации (как у InTouch) ради потенциальной кроссплатформенности, однако функционал разработчика они стремятся унифицировать поэтапно с Comfort/Advanced функционалом.
С кроссплатформенностью согласен. Унификация визуализации между панелькой и скадой - это очень хорошо и этого очень не хватало. Учитывая, что панели Comfort Unified являются, ЕМНИП, IPC227 под управлением Simatic Industrial OS (Debian с RT нахлобучкой), то Unified для PC тоже можно сделать кроссплатформенным и запускать, хотя бы, под тем же SIOS. Что, в принципе, сейчас уже есть в WinCC OA. Надеюсь, товарищи немцы зарелизят Unified PC с под SIOS... но не уверен, что это будет пользоваться большим спросом. )
Относительно унификации с Advanced? А что Вы под этим подразумеваете? Если речь идет про работу в TIA, то она и так полностью интегрируется в портал. Относительно строго инженерной унификации с advanced - ну, я даже не знаю. По ящзыка скриптов у нас в юнифаед - жабаскрипт, в адванседе - бейсик. Как это унифицировать? И надо ли унифицировать? Сама юнифаед уже является мощным шагом в сторогу унификации, стоит ли "тянуть" за ним наследие ProTool?
Возможно для Unified это добавили именно с 17 версии. К сожалению у меня не установлен Unified для проверки
В V16 для флэшинга приходится изгаляться, как описано выше. Во-первых, я сам пришел к этому выводу, когда Unified только вышла, а, во-вторых, я интересовался этим вопросом у немца на трехдневных курсах по Unified.
А вот в версии 17 помигать уже стало можно через динамический диалог. Значит, замыкаем на классический подход, когда статус девайса приходит с ПЛК еще и в виде целочисленного. Возможно ли организовать то же самое скриптом, разбирая только статусное слово? Увы, так и не понял. Возвращаемое значение скрипта - только цвет.
предполагаю что они идут путём максимальной унификации функционала между Comfort/Basic и Unified
Это вряд ли. Прелесть Unified - в унификации ЧМИ на панелях и АРМах. В кой то веки одну и ту же работу нет необходимости делать полностью дважды. Хотя, доработки, все равно, потребуются в виду различных разрешений экрана.
Вообще, в целом, отвлекшись от конкретной задачи, я бы предложил ознакомиться с концепцией High Performance HMI/SCADA, потому что изобилие "красивых" SVG элементов сильно засоряет визуально мнемосхему и усложняет считывание информации оператором
Как правило, на мнемосхемах применяю графические примитивы, но в этом туториале захотелось красивую картинку, потому что, зараза, красивое )
чтобы организовать modbus/tcp, нужно точно иметь TCP. Как его не "приплетать" :)?
Вы говорили про работу через сокеты. То есть, непосредственный обмен через TCP или UDP порт? И для этого непосредственного обмена со стороны целевой системы (ПЛК или смарт-реле) недостаточно просто иметь поддержу протокола TCP/IP на уровне операционной системы, необходимы функции или функциональные блок соединия, чтения, записи и т.д.
Чтобы организовать modbus/tcp - нужно этот modbus с обеих сторон поддержать.
Конечно. Так и строится нормальная система АСУ ТП, на согласованности протоколов.
Была задача брать данные из ёкагавы и отправлять в TSDB Osi/PI SDK. Для простоты выбрал python.
Самописный опрос промышленного девайса с компа - это частный, очень частный случай.
По какому протоколу работала йокка? Вы сами описывали протокол или брали готовую библиотеку?
Я бы приаттачил сюда сейчас картинку с престарелым мастером кунг-фу с поднятым вверх указательным пальцем, но мне, откровенно, лениво. Ведь надо вначале разобраться, что ты делаешь, потом понять, что ты делаешь не так, а лишь потом делать далеко идущие выводы.
Ладно, ворчать закончил )
Все верно, Вы копали не в ту сторону. Если я переведу свое реле FS4 в ведомый режим, то он из реле превратиться в безмозглый, как ловко подметили мои коллеги из саппорта, интерфейсный модуль для ведущего реле, а его (ведомого) программа не будет выполняться.
Превращаю в ведомогоПрограмма арбайтен нихт
Но стоит лишь вернуть его в режим мастера, как работа возобновляется.
И совершенно неважно, какой тип проекта Вы применяете, отдельные диаграммы или сетевой проект. И там, и там необходимо лишь сконфигурировать соответствующее соединение. Сетевой проект в этом отношении даже более нагляден.
С учетом того, что Вы юзали панель, Вам надо было сконфигурировать логу! в качестве сервера Modbus или S7... в зависимости от того, какой протокол понимает сама панель.
В моем примере Logo работает сервером (слейвом) модбаса, и ППО при этом функционирует. Возможно, у Вас совпали изменения в ППО и добавление функционала Modbus TCP Server, но гадать я не буду.
Про реманентность данных в логах, увы, не подскажу.
Модбас не нужен, есть сокеты. Но модбас работает через сокеты. А в частотниках ПЛК встраивают для этого.
Вспомните модель ISO OSI. Да, многие ее не любят, но в качестве наглядного пособия - подойдет. Modbus TCP - это прикладной уровень модели. То есть, четко оговоренный формат передачи пакетов. Вы зачем-то приплетаете уровень TCP, то есть - транспортный. Можно ли организовать обмен между ПЛК на транспортном уровне? В ряде случаев можно. А для некоторых целевых систем, т.н. ПЛК или смарт-реле, такой функционал недоступен. Зато есть стандартизированный и общепринятый протокол. В данном случае - Modbus TCP.
Главное тут - общепринятость и стандартзированность.
Протокол Modbus TCP подразумевает наличие поля Slave ID в заголовке пакета.
Никаких проблем быть не должно.
Преобразователь TCP - RTU со своей северной стороны нам, все одно, предоставляет именно Modbus TCP.
При всем уважении, коллега, это больше похоже на одноплатник а-ля "малинка".
Для затравки, два вопроса:
В какой среде и на каких языках IEC61131-3 ведётся разработка ППО?
Каким образом обеспечивается реальное время? Это жесткое или мягкое реальное время?
Сколько, сколько экземпляров функционального блока "модбус" (и коннекшенов) Вы зададите.
Отличный ответ, куда лучше моего!
Мое предположение про "сделать Сименс доверенным" (очевидно, вручную и на каждой машине) - соответствует истине или фантазии?
Ругается, ибо сертификат самоподписанный.
Либо смириться, либо внести "сименс" в доверенные на всех компах, откуда будете подключаться, либо платить за воздух и купить сертификат.
Добрый день!
Прошу простить, что так долго затянул с ответом, на выходных я предавался безделию и даже не смотрел емейл с уведомлениями.
К лого! можно подключать устройства протокола Modbus TCP, у Вас же железка на RS-485, а это Modbus RTU, так что, увы, нельзя.
Благодарю, буду знать.
Увы, но ничего приводного под рукой нет, проверить не на чем. С учетом того, что Starter - это классическая, а не портальная софтина, в проект портала она не интегрируется, и в статье указано, как склеить эти две среды.
Вопрос интересный, но я не припоминаю, чтобы наши частотники общались по S7. Профинет, профибус, даже модбус RTU для V20 - запросто. А вот S7, хоть убей, не помню. Поинтересуюсь у коллег для повышения уровня самообразованности.
Тут посмотрите:
https://support.industry.siemens.com/cs/document/584459/which-modules-support-the-s7-routing-function-in-s7-subnets-?dti=0&lc=en-SI
Невидимый на фейсплейте (и его производных) iofield с event'ом на process value change?
И где в этом перечне взрослые скады? Первое и второе - это строго панели, третье - одиночная станция с функционалом панели comfort. Копи-паст из проектов WinCC Pro в панельные крайне ограничен. Копи-паст из классической WinCC в панели - а он есть вообще?
С кроссплатформенностью согласен. Унификация визуализации между панелькой и скадой - это очень хорошо и этого очень не хватало. Учитывая, что панели Comfort Unified являются, ЕМНИП, IPC227 под управлением Simatic Industrial OS (Debian с RT нахлобучкой), то Unified для PC тоже можно сделать кроссплатформенным и запускать, хотя бы, под тем же SIOS. Что, в принципе, сейчас уже есть в WinCC OA. Надеюсь, товарищи немцы зарелизят Unified PC с под SIOS... но не уверен, что это будет пользоваться большим спросом. )
Относительно унификации с Advanced? А что Вы под этим подразумеваете? Если речь идет про работу в TIA, то она и так полностью интегрируется в портал. Относительно строго инженерной унификации с advanced - ну, я даже не знаю. По ящзыка скриптов у нас в юнифаед - жабаскрипт, в адванседе - бейсик. Как это унифицировать? И надо ли унифицировать? Сама юнифаед уже является мощным шагом в сторогу унификации, стоит ли "тянуть" за ним наследие ProTool?
В V16 для флэшинга приходится изгаляться, как описано выше. Во-первых, я сам пришел к этому выводу, когда Unified только вышла, а, во-вторых, я интересовался этим вопросом у немца на трехдневных курсах по Unified.
А вот в версии 17 помигать уже стало можно через динамический диалог. Значит, замыкаем на классический подход, когда статус девайса приходит с ПЛК еще и в виде целочисленного. Возможно ли организовать то же самое скриптом, разбирая только статусное слово? Увы, так и не понял. Возвращаемое значение скрипта - только цвет.
Это вряд ли. Прелесть Unified - в унификации ЧМИ на панелях и АРМах. В кой то веки одну и ту же работу нет необходимости делать полностью дважды. Хотя, доработки, все равно, потребуются в виду различных разрешений экрана.
Как правило, на мнемосхемах применяю графические примитивы, но в этом туториале захотелось красивую картинку, потому что, зараза, красивое )
Одним скриптом, который в шедуллере?
Признаю, получилась халтура.
В 16ой версии flashing был именно такой, как описано выше.
В 17ой версии функционал был расширен, но я это бездарно проморгал.
Вы говорили про работу через сокеты. То есть, непосредственный обмен через TCP или UDP порт? И для этого непосредственного обмена со стороны целевой системы (ПЛК или смарт-реле) недостаточно просто иметь поддержу протокола TCP/IP на уровне операционной системы, необходимы функции или функциональные блок соединия, чтения, записи и т.д.
Конечно. Так и строится нормальная система АСУ ТП, на согласованности протоколов.
Самописный опрос промышленного девайса с компа - это частный, очень частный случай.
По какому протоколу работала йокка? Вы сами описывали протокол или брали готовую библиотеку?
Я бы приаттачил сюда сейчас картинку с престарелым мастером кунг-фу с поднятым вверх указательным пальцем, но мне, откровенно, лениво. Ведь надо вначале разобраться, что ты делаешь, потом понять, что ты делаешь не так, а лишь потом делать далеко идущие выводы.
Ладно, ворчать закончил )
Все верно, Вы копали не в ту сторону. Если я переведу свое реле FS4 в ведомый режим, то он из реле превратиться в безмозглый, как ловко подметили мои коллеги из саппорта, интерфейсный модуль для ведущего реле, а его (ведомого) программа не будет выполняться.
Но стоит лишь вернуть его в режим мастера, как работа возобновляется.
И совершенно неважно, какой тип проекта Вы применяете, отдельные диаграммы или сетевой проект. И там, и там необходимо лишь сконфигурировать соответствующее соединение. Сетевой проект в этом отношении даже более нагляден.
С учетом того, что Вы юзали панель, Вам надо было сконфигурировать логу! в качестве сервера Modbus или S7... в зависимости от того, какой протокол понимает сама панель.
В моем примере Logo работает сервером (слейвом) модбаса, и ППО при этом функционирует. Возможно, у Вас совпали изменения в ППО и добавление функционала Modbus TCP Server, но гадать я не буду.
Про реманентность данных в логах, увы, не подскажу.
Что-то Вы все в кучу смешали.
Модбас не нужен, есть сокеты. Но модбас работает через сокеты. А в частотниках ПЛК встраивают для этого.
Вспомните модель ISO OSI. Да, многие ее не любят, но в качестве наглядного пособия - подойдет. Modbus TCP - это прикладной уровень модели. То есть, четко оговоренный формат передачи пакетов. Вы зачем-то приплетаете уровень TCP, то есть - транспортный. Можно ли организовать обмен между ПЛК на транспортном уровне? В ряде случаев можно. А для некоторых целевых систем, т.н. ПЛК или смарт-реле, такой функционал недоступен. Зато есть стандартизированный и общепринятый протокол. В данном случае - Modbus TCP.
Главное тут - общепринятость и стандартзированность.
С частотниками Вы тоже предлагаете через сокеты общаться? )
А Вы на цену Logo! посмотрите, причем, не "листовую", а у дистров.
Про Modbus TCP для трехсотой серии я в течении ближайших 2-4 недель планирую написать заметку в моем любимои стиле "автоматизация для бедных" )