Я думаю, справедливым будет заключение, что qt может быть и красивым, и некрасивым, а степень красивости зависит от разработчика… ну, и если есть такая возможность, то от кастомизации на уровне юзера.
Как видим, дефолтный интерфейс WinCC OA весьма архаичен. Насколько его можно допилить теми или иными способами — я не знаю.
Нажал.
Удивился.
Вспомнил, что меня еще в прошлом году в ВК поправили именно по этому вопросу.
Но, разумеется, тогда я ничего не поправил, а сейчас тупо скопипастил, что, несомненно, четко характеризует мои умственные способности.
Коллега, благодарю за помощь.
Есть такое, Qt-шный интерфейс по современным меркам не радует взгляд. Зато и не грузит систему лишними рюшечками. Под Debian WinCC OA вообще летает.
К слову, архаичность внешнего вида среды разработки и базовых элементов (а я пишу только про них — какая красота может быть в синем прямоугольнике?) совершенно не мешает профессиональным разработчикам делать весьма качественный, красивый и современный операторский визуал.
Коллега, Вы обратили внимание, что эта заметка называется «Часть 1»?
Вопросов, тем не менее, задали уже на 15 частей вперед. Материал переносится сюда не сразу, постепенно ответы будут.
Если не терпится, то vk.com/@akcount, там гораздо больше.
В меру своих убогих знаний постараюсь сформулировать отличия кратко. Под «обычной WinCC» буду предполагать классическую версию 7.
Общая идеалогия. 7 — монолитная, ОА — модульная, основанная на менеджерах, общающихся на TCP. В ОА рассматривается и лицензируется система, а не набор хостов. Ничто не помешает даже однопользовательскую систему разнести на три физических хоста (1 — EV и драйверы, 2 — ui, 3 — архивы), при этом набор купленных компонент не меняется. На практике так, вряд ли, кто-то будет делать, но, тем не менее.
Можно написать абсолютно любой менеджер или драйвер и интегрировать в свою систему.
Кроссплатформенность. ОА, кроме винды, крутится еще на трех дистрах пингвина, причем, в рамках системы хосты могут быть на разных ОС.
Наличие «катастрофоустойчивого» резервирования. Применяется на пара резервных серверов, а две таких пары, то есть 2х2
Возможность построение распределенных систем. В самом простом случае пара строчек в конфиге, и две никак не связанные до этого системы, теперь имеют единую базу точек данных. Причем, как я понял, обмен между dist-менеджерами построен на принципах телемеханических протоколов и весьма похож на IEC104.
Система фактически написана сама на себе. Это если грубо. Тот же модуль para является панелью «системного» (что-то вроде include) проекта, и его можно спокойно изменить/модифицировать.
Возможность менять систему на лету и не только «ручными средствами» конфигурирования. Скриптами можно и добавлять точки данных, и изменять конфигурацию на лету, и создавать/добавлять панели.
Область применения? А исходя из здравого смысла и дальнейших планов на развитие. Если в АСУ ТП находится пара-тройка S7-1511, и она всю жизнь будет в stand alone режиме, то тут в WinCC Professional может оказать много, можно и Advanced обойтись.
А если речь идет про управление магистральных нефтепроводов или любую другую распределенную системы в пару миллионов внешних сигналов, то это совсем другое дело.
Да, коллега, все верно. Я счел необходимым немного расширить охват своих заметок. Кроме того, хабр удобнее с точки зрения демонстрации программного кода прямо в тексте, а не скриншотами.
Я не разделяю Ваших опасений относительно «набегут и накритикуют». Если почитать комментации к предлагаемой статье, то там не видно восторгов, зато есть замечания разной степени ехидности касательно применения «настоящих» скада-систем.
Есть общепризнанный инструментарий для создания операторских систем в промышленности, это факт. Однако, ни законом, ни обществом не запрещено и не порицается брать любую среду разработки (особо сильные могут обойтись средствами vi и make) и «писать свою скаду».
Про подход согласен — натягивание совы на глобус, даже у таймера имя соответствующее задано. Про REAL тоже согласен.
Постановка задачи. Кратко и на пальцах. Выделяем некоторые сущности, например — DI, DO, агрегат. Каждая сущность — это массив элементов, у каждого элемента, соотвественно, есть свой индекс, т.е. уникальный номер. Обработка всех сущностей выполняется в циклах.
Для каждой сущности задается конфигурацию в реманентной памяти.
Для DI
-сигнал не в работе, подавать замещающее значение
-замещающее значение
-сигнал инвертирован
-время фильтрации дребезга контактов
Для DO
-сигнал не в работе, подавать замещающее значение
-замещающее значение
-сигнал инвертирован
-длительность управляющего импульса
Для агрегата
-индексы сигналов состояния
-индексы сигналов управления
-куча другого
У S7-300, особенно у тех, которые были поколение-два назад, все не очень хорошо с рабочей (оперативной) памятью, ее очень мало. По этой причине и заворачивали обработку в циклы. Память экономится значительно, но читаемость такого кода очень низкая.
В «тысячной» серии с рабочей памятью стало гораздо лучше, поэтому описанный в заметке пример носит больше демонстрационный и ностальгический параметр.
В циклическом OB (OB35, например) ты просто будешь знать время приращения аккумулятора времени, как константу. Но в целом задача сводится к предыдущей.
И за свой счёт такую собирать будет только ОЧЕНЬ состоятельный человек )
Я не понял Вас. WinCC OA, с Вашей точки зрения — проприетарное или «свободное» решение?
Я думаю, справедливым будет заключение, что qt может быть и красивым, и некрасивым, а степень красивости зависит от разработчика… ну, и если есть такая возможность, то от кастомизации на уровне юзера.
Как видим, дефолтный интерфейс WinCC OA весьма архаичен. Насколько его можно допилить теми или иными способами — я не знаю.
Удивился.
Вспомнил, что меня еще в прошлом году в ВК поправили именно по этому вопросу.
Но, разумеется, тогда я ничего не поправил, а сейчас тупо скопипастил, что, несомненно, четко характеризует мои умственные способности.
Коллега, благодарю за помощь.
images.app.goo.gl/2hSamW8gbVtpVktXA
К слову, архаичность внешнего вида среды разработки и базовых элементов (а я пишу только про них — какая красота может быть в синем прямоугольнике?) совершенно не мешает профессиональным разработчикам делать весьма качественный, красивый и современный операторский визуал.
Вопросов, тем не менее, задали уже на 15 частей вперед. Материал переносится сюда не сразу, постепенно ответы будут.
Если не терпится, то vk.com/@akcount, там гораздо больше.
Общая идеалогия. 7 — монолитная, ОА — модульная, основанная на менеджерах, общающихся на TCP. В ОА рассматривается и лицензируется система, а не набор хостов. Ничто не помешает даже однопользовательскую систему разнести на три физических хоста (1 — EV и драйверы, 2 — ui, 3 — архивы), при этом набор купленных компонент не меняется. На практике так, вряд ли, кто-то будет делать, но, тем не менее.
Можно написать абсолютно любой менеджер или драйвер и интегрировать в свою систему.
Кроссплатформенность. ОА, кроме винды, крутится еще на трех дистрах пингвина, причем, в рамках системы хосты могут быть на разных ОС.
Наличие «катастрофоустойчивого» резервирования. Применяется на пара резервных серверов, а две таких пары, то есть 2х2
Возможность построение распределенных систем. В самом простом случае пара строчек в конфиге, и две никак не связанные до этого системы, теперь имеют единую базу точек данных. Причем, как я понял, обмен между dist-менеджерами построен на принципах телемеханических протоколов и весьма похож на IEC104.
Система фактически написана сама на себе. Это если грубо. Тот же модуль para является панелью «системного» (что-то вроде include) проекта, и его можно спокойно изменить/модифицировать.
Возможность менять систему на лету и не только «ручными средствами» конфигурирования. Скриптами можно и добавлять точки данных, и изменять конфигурацию на лету, и создавать/добавлять панели.
Область применения? А исходя из здравого смысла и дальнейших планов на развитие. Если в АСУ ТП находится пара-тройка S7-1511, и она всю жизнь будет в stand alone режиме, то тут в WinCC Professional может оказать много, можно и Advanced обойтись.
А если речь идет про управление магистральных нефтепроводов или любую другую распределенную системы в пару миллионов внешних сигналов, то это совсем другое дело.
Я не разделяю Ваших опасений относительно «набегут и накритикуют». Если почитать комментации к предлагаемой статье, то там не видно восторгов, зато есть замечания разной степени ехидности касательно применения «настоящих» скада-систем.
Есть общепризнанный инструментарий для создания операторских систем в промышленности, это факт. Однако, ни законом, ни обществом не запрещено и не порицается брать любую среду разработки (особо сильные могут обойтись средствами vi и make) и «писать свою скаду».
Кстати, из структуры можно, скорее всего, безболезненно, убрать Q и ET, сэкономим немного памяти.
Постановка задачи. Кратко и на пальцах. Выделяем некоторые сущности, например — DI, DO, агрегат. Каждая сущность — это массив элементов, у каждого элемента, соотвественно, есть свой индекс, т.е. уникальный номер. Обработка всех сущностей выполняется в циклах.
Для каждой сущности задается конфигурацию в реманентной памяти.
Для DI
-сигнал не в работе, подавать замещающее значение
-замещающее значение
-сигнал инвертирован
-время фильтрации дребезга контактов
Для DO
-сигнал не в работе, подавать замещающее значение
-замещающее значение
-сигнал инвертирован
-длительность управляющего импульса
Для агрегата
-индексы сигналов состояния
-индексы сигналов управления
-куча другого
У S7-300, особенно у тех, которые были поколение-два назад, все не очень хорошо с рабочей (оперативной) памятью, ее очень мало. По этой причине и заворачивали обработку в циклы. Память экономится значительно, но читаемость такого кода очень низкая.
В «тысячной» серии с рабочей памятью стало гораздо лучше, поэтому описанный в заметке пример носит больше демонстрационный и ностальгический параметр.