Благодарю, буду знать.

Увы, но ничего приводного под рукой нет, проверить не на чем. С учетом того, что Starter - это классическая, а не портальная софтина, в проект портала она не интегрируется, и в статье указано, как склеить эти две среды.

Однако, тема S7 routed connection раскрыта не полностью. Почему-то при рассмотрении таких соединений приводят в пример соединения ПЛК - ПЛК, ПЛК - HMI. А как насчёт соединений ПЛК - ПЧ (например, G120)?

Вопрос интересный, но я не припоминаю, чтобы наши частотники общались по S7. Профинет, профибус, даже модбус RTU для V20 - запросто. А вот S7, хоть убей, не помню. Поинтересуюсь у коллег для повышения уровня самообразованности.

Коллеги подскажите, может кто знает, в серии S7-1200 функция роутинга вообще есть? В принципе? Искал на сайте Сименса но так и не нашёл определённого ответа. Или может в 1200 серии есть какая-то особенность при настройки связи с приводами?

Тут посмотрите:

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?

Эм, как бы, 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 элементов сильно засоряет визуально мнемосхему и усложняет считывание информации оператором

Как правило, на мнемосхемах применяю графические примитивы, но в этом туториале захотелось красивую картинку, потому что, зараза, красивое )

Одним скриптом, который в шедуллере?

Признаю, получилась халтура.

В 16ой версии flashing был именно такой, как описано выше.

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

чтобы организовать 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.

Главное тут - общепринятость и стандартзированность.

С частотниками Вы тоже предлагаете через сокеты общаться? )

А Вы на цену Logo! посмотрите, причем, не "листовую", а у дистров.

Про Modbus TCP для трехсотой серии я в течении ближайших 2-4 недель планирую написать заметку в моем любимои стиле "автоматизация для бедных" )

Для S7-1200 есть редакция Step 7 Basic

Basic. Но не Lite.

Все верно, коннекшены расходуются, и их в 1200ом - немного.