Hmi визуализация

[Малышев Олег]

С огромным интересом зачитываю данную дисскусию. В настоящий момент наблюдаю два подхода -
1) Западный
ПО платное и за лицензии надо платить. ПО производится промышленным методом ( по правильной методологии и проходит lifecycle ). Раздается не бесплатно, но цена ПО вполне обоснована с точки зрения коммерческого предприятия
2) Российский
ПО условно бесплатое - т.е. если есть возможность не платить - "пиратим" без зазрения совести. В случае отсутствия нужного ПО (или соотношение деньги для взлома/ (нужное кол-во лиц-ий * цену лицензии) >1 ) разрабатывается ПО "на коленке". При определенной достижении определенной сложности ПО ( ну скажем >10Кстрок) тестирование в "домашних" условиях без пром. подхода не дает результатов. И поэтому появляются ошибки. Если люди готовых за них платить - отлично. Для маленьких продуктов, которые заключаются в выведении пары графиков и 3-х кнопок.
Вот - например приколы которые случаются с наколенниками 1) Переход на зиму-лету
2) Конец памяти 3) Отображение на нестандартном шрифте dpi >125 4) Работа в "безопасном режиме" 5) Работа не под админом с жестко ограниченными правами когда на каждое открытие дескриптора нужно получить права 6) Работа от win95 до Vista 7) Контроль версий библиотек проставленных в системе.
Это то что я "навскидку сказал" подумав 10 секунд. Реально если программисты катают карандаш - это ерунда какая та. Так обычно не бывает

[Прохожий]

С огромным интересом зачитываю данную дисскусию. В настоящий момент наблюдаю два подхода -
1) Западный
ПО платное и за лицензии надо платить. ПО производится промышленным методом ( по правильной методологии и проходит lifecycle ). Раздается не бесплатно, но цена ПО вполне обоснована с точки зрения коммерческого предприятия

Мы живем далеко не на Западе, а скорее на Востоке, а он, как известно, дело тонкое...
А откуда Вы знаете, что мой (условно, поскольку я не один) софт не проходит lifecycle? Очень даже проходит и условия достаточно суровые.
Методологиия проста. По договору софт эксплуатируется определенное время без всякой оплаты со стороны заказчика. За это время утрясаются все неувязки и просчеты, продукт проверяется на соответствие ТЗ, учитываются текущие пожелания заказчика, воплощение которых не противоречит ТЗ. Лишь по истечении этого срока составляется акт приемки-сдачи и оплачивается труд разработчика.
Сия метода придумана, увы, не мной, а пришла с горячо любимого Вами Запада. Пример - MASA Group. ПЛК - SIEMENS, а визуализация - Delphi, причем в каждом конкретном случае своя. Прокладка - либо ProDave, либо S7API.

2) Российский
ПО условно бесплатое - т.е. если есть возможность не платить - "пиратим" без зазрения совести. В случае отсутствия нужного ПО (или соотношение деньги для взлома/ (нужное кол-во лиц-ий * цену лицензии) >1 ) разрабатывается ПО "на коленке".

Ну Вы прямо жуть какую-то нагнетаете. Сборище жутких хакеров, и безголовых индивидуумов. На самом деле все гораздо белее и пушистее.

При определенной достижении определенной сложности ПО ( ну скажем >10Кстрок) тестирование в "домашних" условиях без пром. подхода не дает результатов. И поэтому появляются ошибки. Если люди готовых за них платить - отлично. Для маленьких продуктов, которые заключаются в выведении пары графиков и 3-х кнопок.

Ну если кто-то умудряется наделать ошибок в маленькой программуле из пары графиков и 3-х кнопок, то бог ему судья. А вообще-то существует ряд методов, позволяющих разрабатывать софт с минимальным количеством ошибок вне зависимости от количества строк кода. И еще - краткость - сестра таланта. Тестирование в реальных условиях я уже осветил выше.

Вот - например приколы которые случаются с наколенниками 1) Переход на зиму-лету
2) Конец памяти 3) Отображение на нестандартном шрифте dpi >125 4) Работа в "безопасном режиме" 5) Работа не под админом с жестко ограниченными правами когда на каждое открытие дескриптора нужно получить права 6) Работа от win95 до Vista 7) Контроль версий библиотек проставленных в системе.
Это то что я "навскидку сказал" подумав 10 секунд.

Я могу сделать то же самое по отношению к профессиональным продуктам. Причем пунктов будет граздо больше. Может быть начнем с HMI?

Реально если программисты катают карандаш - это ерунда какая та. Так обычно не бывает

Ну да? А что в последнее время что-то изменилось и программисты стали с реальным производством сталкиваться - крутить гайки и таскать кабеля?
Проблема-то на самом деле в том, что неоправданно высокая цена на софт, к тому же далеко не всегда качественный, приводит к тому, что приходится заниматься несвойственным делом.

[Milchuk]

В отношении ошибок и всяческих ньюансов могу отметить следующее.
Попробовав написать проект для HMI я, к сожалению не встретил активной поддержки - пользователи, видимо, не слишком часто его используют, да и фирма 3S с ПРОЛОГом не очень-то активно отвечают на вопросы. Я уже не говорю о каких-либо исправлениях ПО, которые, очевидно, необходимы. И бог с ней, с ценой. Я просто оцениваю HMI как откровенно сырой продукт, (и дело с места не двигается) на котором я свой проект, сделать не могу. Соответственно остаётся SCADA. Как я понимаю, тут тоже выбор не велик., и деньги другие.
На мой взгляд, заманчивый вариант написать визуализацию самому. Я готов к ошибкам, по крайней мере, я могу их исправить. А в случае, когда ошибка обусловлена несовершенством HMI - что прикажете делать?
Тема про визуализацию актуальная. Наблюдая поколения технологического оборудования, нетрудно заметить увеличение диагонали экранов и навороченности панелей операторов плюс повсеместное внедрение диспетчерских пультов на РС. Цитируя Билла Г., "... пусть плохо работает, но выглядеть должно отлично...".
И почему вас удивляет 3D визуализация на несколько входов - выходов? Имея один датчик подсчёта продукции, клиент зачастую хочет видеть диаграммы и архивные данные по количеству этой продукции чуть ли не за любую минуту (есть прецеденты). Да ещё и печатать кучу разнообразных отчётов по этому архиву.

[Прохожий]

Дело не в платности/бесплатности, а в ресурсах процессора.

О каких ресурсах идет речь?
По моим данным PIC24 по производительности на тестах в целочисленной арифметике не уступает тому же ARMу. Я уже не говорю о dsPIC33F, с его дополнительным DSP ядром.
А AVR отнюдь не медленнее MSC51.

[Филоненко Владислав]

По ресурсам памяти. Ну невозможно на PIC-е эффективно работать с указателями. Код раздувается раз в 5! Не все определяется числом скоростных попугаев.

[Прохожий]

По ресурсам памяти. Ну невозможно на PIC-е эффективно работать с указателями. Код раздувается раз в 5! Не все определяется числом скоростных попугаев.

Извините, ради любопытства, а какой инструментарий Вы имеете в виду, когда говорите о неэффективной работе с указателями - MPLAB+C30 или что-то иное? И указателями на что (данные, функции, структуры)?

[Филоненко Владислав]

IAR - очень неэффективно, MPLAB чуть лучше, но все равно алгоритм с указателями получается сущ. больше аналог. с индексами, тогда как на др. архитектуре (к примеру ARM) все наоборот.
Массированное использование указателей - на PIC просто невозможно - не влезает, рост размера в 3-4 раза по сравнению а AVR!
+ у PIC-а очень мало памяти и она по идиотски разбита на маленькие банки. Даже у древнего 8051 архитектура памяти лучше, что и позволяет портировать на него CoDeSyS.

[Игорь Петров]

Никто не говорит про "раздавать даром". За софт фирме 3S платит производитель ПЛК...Именно к такой форме оплаты софта я и призываю. Здесь все просто и понятно.

Именно так и есть, причем никто не собирается это менять. Это касается всех базовых компонентов. Обратите внимание, что даже OPC и DDE серверы поставляются бесплатно!
Однако на практике порой возникают всякие дополнительные специальные потребности. Например, стыковка сети контроллеров с базами данных, ERP, библиотеки поддержки приборов некого изготовителя, инжиниринговые средства для многопользовательской работы и интеграции в проект разных файлов (например, электрических схем) и др. и пр. Никто в принципе не может запретить любой компании делать дополнительные компоненты на заказ или на продажу.
Если вдруг вы сделали некую удачную штуку для CoDeSys, которая может быть интересна не только одному заказчику, то ее вполне можно продавать. Никто не вправе это запретить.

Я всегда был против SCADA систем. В настоящее время достаточно большое количество фирм - производителей промышленного оборудования отказались от их применения. Заменой служит тот же продукт от Borland - Delphi. И в этом случае визуализация адаптируется под нужды клиента.

На мой взгляд, использование универсальных средств программирования гораздо более трудоемко. Практически все изготовители оборудования дают OPC сервера для стыковки с SCADA.

Имелись в виду ядра систем исполнения CoDeSys. Среди них: MSC8051H8 (CSP8), MC680x+0, TriCore, ARM(CSP32), C16x(CSP16).
Если внимательно присмотреться к этим платформам, то выяснится, что инструментальные средства к ним стоят достаточных денег.
В то же время, существует ряд не менее популярных платформ с бесплатными инструментальными средствами. Это микроконтроллеры PIC24, dsPIC30/33, AVR, MAXQ2000 и еще целый ряд других. Но на эти платформы CoDeSys не становится.
В связи с этим вопрос. Это политика 3S или простая случайность?

На поддержку вышеперечисленных семейств в CoDeSys просто нет реального спроса.
Требования пользователей к системе программирования и универсальным ПЛК постоянно растут. Все хотят иметь работу с файлами, сетями, быструю математику высокой точности и др. Грубо говоря, для хорошего универсального современного ПЛК процессорное ядро должно как минимум легко тянуть ОС Линукс или WinCE. Такой ПЛК проще в применении. Он с большим запасом обеспечивает быстродействие (можно особо не ломать голову над оптимизацией кода, можно программно делать все что надо, без спец. модулей). Сейчас есть 32 бит процессоры, которые стоят дешевле некоторых 8 бит (например ARM). Дык почему бы их не использовать?
Что касается средств разработки, то эти разовые затраты никого особо не напрягают. Это инструменты = средства производства, также как и станки и сборочные линии. В сравнении с затратами на строительство завода для производства ПЛК, инструментальные средства стоят копейки. Выводить CoDeSys на рынок кустарей-самодельшиков никто не собирается. Сейчас он применяется только в изделиях очень серьезных OEM компаний, способных делать передовые изделия соответствующего качества.

[Игорь Петров]

Попробовав написать проект для HMI я, к сожалению не встретил активной поддержки - пользователи, видимо, не слишком часто его используют, да и фирма 3S с ПРОЛОГом не очень-то активно отвечают на вопросы..

Только что вернулся из командировки с завода, где только на одной машине используется 40 ПЛК с визуализацией в CoDeSys. Таких машин много. К HMI у прикладных программистов замечаний нет вообще. Это квалифицированные люди, имеющие большой опыт работы. Возможно, они просто умеют правильно применять встроенную визуализацию? Практически HMI используется и достаточно широко, ежедневно и круглосуточно.

Неужели действительно было хотя бы одно письмо в адрес Пролог, на которое не пришел ответ? Точно письмо дошло до нас? Реально отвечаются абсолютно все вопросы, даже от тех, кто вообще ничего у нас не покупал. Есть проблема с тем, что у многих стоят жестокие спам фильтры и наши ответы просто не проходят. При положительном ответе, очень редко кто утруждает себя откликом, типа спасибо ответ получен, вопрос решен… Поэтому я не имею уверенности, что все ответы дошли. С нашей стороны есть совершенно противоположная проблема: мало обратной связи и информации для внесения исправлений, по крайней мере от российских пользователей. Разработчики увы не обладают божественным даром предугадывать мысли желания каждого пользователя. Каждый новый релиз включает множество доработок. Пожалуйста, присылайте вопросы и замечания. Предложения по введению дополнительных функций вполне можем здесь обсудить. Все что реально сделать и действительно нужно, будет обязательно делаться.

На мой взгляд, заманчивый вариант написать визуализацию самому. Я готов к ошибкам, по крайней мере, я могу их исправить. А в случае, когда ошибка обусловлена несовершенством HMI - что прикажете делать?..

Что делать если есть проблема с контроллерами, реле, клеммами и др.? Все делать самому? Это не реально…
При покупке ПО заключается договор, по которому изготовитель обязуется исправить все обнаруженные дефекты в установленный срок или вернуть деньги. Этого единственное цивилизованное решение.

И почему вас удивляет 3D визуализация на несколько входов - выходов?

Визуализации бывают очень разные. Выше я уже писал, что визуализация CoDeSys заточена под самый нижний уровень. Она должна работать на простерших и дешевейших контроллерах и панелях, приделанных к машине в цеху. Украшательства здесь нужны как коту банный веник. Не нужны и всяческие месячные архивы и распечатки отчетов, анализаторы экономической эффективности и т.п. Нужна простая форма представления, быстрота реакции и надежность работы. Т.е. HMI не имеет цели конкурировать со скадами. Это разные области применения. В хороших современных скадах столько всяких разных функций наворочено, что самостоятельно сделать за одну жизнь не реально. С другой стороны на нижнем уровне применять скаду вообще не всегда и получится. Для этого есть HMI.

[Прохожий]

IAR - очень неэффективно, MPLAB чуть лучше, но все равно алгоритм с указателями получается сущ. больше аналог. с индексами, тогда как на др. архитектуре (к примеру ARM) все наоборот.
Массированное использование указателей - на PIC просто невозможно - не влезает, рост размера в 3-4 раза по сравнению а AVR!

Согласен. 16-е и 18-е PICи предназначены для работы с непосредственной адресацией. Тогда и код меньше и скорость выше.
Но вопрос про CoDeSys касался и AVR в том числе. На AVR CoDeSys не портируется, хотя это модифицированный (в лучшую сторону) клон MSC51. Почему?

+ у PIC-а очень мало памяти и она по идиотски разбита на маленькие банки. Даже у древнего 8051 архитектура памяти лучше, что и позволяет портировать на него CoDeSyS.

Это касается только младших версий PICов (16-х и 18- х). Старшие версии PIC24F/dsPIC33 имеют сплошное адресное пространство, шириной 16 бит. Кроме этого, в отличие от младших версий, любой из 16 регистров (кроме 0, 14 и 15), расположенных непосредственно в ядре, может быть указателем на данные в арифметических и логических командах. Эдакое PIC+AVR сочетание при 16 битовых данных.