PDA

Просмотр полной версии : Hmi визуализация



Milchuk
03.06.2007, 17:16
Проблема следующая: когда визуализация просматривается в CoDeSys, текст шрифтом редактора (а именно аварийные сообщения и всплывающие подсказки) отображается нормально. При запуске HMI - текст не русский. Как решить проблему??? Видимо где-то нужно подставить шрифт и для HMI?

Milchuk
04.06.2007, 09:00
Нужно переносить настройки из CoDeSys.ini в CoDeSysHMI.ini, в частности и настройки шрифта
Size=-13
FaceWeight=400
Italic=No
CharSet=204
Я думаю, что настройки должны переноситься автоматически, но я пробовал на нескольких машинах - не работает.

Nekit
04.06.2007, 19:34
Пользую шрифт System на русском языке, пока везде работает, проблема токо с размером шрифта и его начертанием

Вячеслав В
17.07.2007, 10:49
подскажите, как сделать визуализацию в CoDeSysHMI. В CoDeSys все работает нормально. При запуске CoDeSysHMI.exe выдает, что данная программа работает в демо режиме. Т.е. визуализацию нельзя делать, пользуясь бесплатной версией CoDeSys, выложенной на сайте?

Малышев Олег
17.07.2007, 10:56
Да, CoDeSysHMI не бесплатна, в отличие от среды разработки (среда разработки CoDeSys не у всех производителей контроллеров бесплатна). Лицензия на использование CoDeSysHMI стоит порядка 200 евро.

Nekit
17.07.2007, 21:36
уточним. визуализацию для Hmi сделать можно. и работать она будет только втечении 1 часа. либо через менеджер лицензий получить пробную рецензию на 14 дней и работать будет без проблем (но 2 недели).

удачи.

Прохожий
07.08.2007, 06:21
уточним. визуализацию для Hmi сделать можно. и работать она будет только втечении 1 часа. либо через менеджер лицензий получить пробную рецензию на 14 дней и работать будет без проблем (но 2 недели).

удачи.

В связи с HMI вопрос. А на кой, спрашивается, пениц, она нужна? Тем более за 200 еврорублей...
Все данные чудесным образом передаются через штатный GatewayDDEServer от CoDeSys прямо в простенькую программку на Buildere. В моем варианте порядка 200 единиц данных. Используются штатные компоненты Builder'а, как-то: DDEClientConv и DDEClientItem.
Я так думаю, что в Builder - это не кривая HMI, это несколько получше будет.

Малышев Олег
07.08.2007, 07:27
К сожалению, не все пользователи слышали про Builder,C++,DDE. Да и купить лицензию в ихних европах на HMI проще чем на Builder ;) Все же 200 евро vs 800 евро, а не 200 евро vs 100 рублей.

Прохожий
07.08.2007, 12:18
К сожалению, не все пользователи слышали про Builder,C++,DDE.

Ну Вы нас прямо обижаете... Мы в основной своей массе ленивые и жадные, но не тупые, иначе бы не выжили. Поэтому мы с Вами, а не с SIEMENSом или OMRONом.


Да и купить лицензию в ихних европах на HMI проще чем на Builder ;) Все же 200 евро vs 800 евро,

Вы тут не совсем правы. Я могу купить C++Builder 6 Personal за 79 бакинских рублей, у нас в России не выходя из дома (не хочу делать рекламу, поэтому не указываю где) а это гораздо меньше, вышеобозначенной суммы за HMI. То же касается и более навороченных версий типа Professional (+457 б. р.) или Enterprise (+1717 б. р.)
И еще, я интересовался вопросом приобретения HMI в России. Так вот, минимальное предложение составило 8000 рублей (Пролог), а это несколько больше, чем 200 евро. Причем речь шла о двух лицензиях (могли бы оптовую скидку сделать...) Дык, Builder все-таки вещь, даже в урезанном Personal варианте, а HMI по сравнению с ним даже рядом не валялся.
Я думаю, в ихних Европах, а так же в Пендостане, дела обстоят не хуже, чем у нас.


а не 200 евро vs 100 рублей.

Ну не 100 рублей, а все 150. Тут Вам не Москва...
К стати, в Вашем изделии стоит ARM9 и куча PIC-ов.
Считаем: EWARM (5700 б.р.) минимум + компилятор МСС18 (450 б. р.) + эмулятор для ARM9 (750 б. р.) + эмулятор для PIC - (500 б. р.) + все тот же Builder (цены см. выше) или Visual Studio для конфигураторов и таргет установщиков. И это без учета того, что в Вашем случае наверняка применяются сетевые версии вышеперечисленного добра, которые стоят еще больше.
Я уже не говорю про AVR, примененных в других Ваших девайсах.
Неужели за все это добро отвешено полновесным золотом? (вопрос риторический, не требующий ответа).

Малышев Олег
08.08.2007, 07:42
Как вариант можно применять саму среду для HMI визуализации. Для этого надо все закрыть паролями, что бы любопытный наладчик/оператор не поменял проект.

Игорь Петров
09.08.2007, 14:18
HMI – это нормальный программный продукт, цена которого объективно рассчитывается из объема необходимого технического сопровождения. Она абсолютно одинакова во всех странах + местный НДС.
В HMI не предусмотрены никакие технические ограничения по числу переменных. Т.е. его цену правильнее было бы сравнивать с ценой SCADA систем, по строке прайса 'неограниченное число каналов'…

На этапе проектирования и отладки для визуализации вполне можно использовать CoDeSys – это бесплатно. На серьезные проекты операторам лучше все же ставить HMI, чтобы оператор мог видеть только то, что ему положено и делать только то, что он должен делать и гарантированно не мог ничего испортить. При установке HMI в программе вообще нет никаких переделок – чисто орг. вопрос. В рамках всего проекта затраты на HMI незначительны и вполне оправданы. (Конечно, если речь идет не об автоматизации сортира для бомжей на их же средства…)

Технически плюсы использования встроенной визуализации CoDeSys и HMI такие:
- Быстродействие, надежность, очень скромные требования к компьютеру. HMI работает с контроллером напрямую по его родному протоколу связи. DDE сервер же использует механизм сообщений Windows (передаются через общую очередь без всякой гарантии времени доставки). Т.е. время обновления данных и время реакции на команды оператора в HMI по определению лучше, чем через OPC и тем более DDE. Компьютер под HMI можно ставить самый дешевый, требования к процессору и памяти практически никакие.
- Простота применения. Все картинки рисуются прямо в среде программирования и элементарно связываются с переменными проекта. Не нужно конфигурировать всякие серверы и пр. промежуточные штуки. Никакого программирования нет вообще, не нужно ничего настраивать (есть связь со средой программирования == визуализация гарантировано работает). Не нужно разбираться со вспомогательными инструментами, все интегрировано в одной среде.

Малышев Олег
09.08.2007, 14:42
ИМХО, все же самое важное про HMI было упомято ранее - значительное число пользователей не знает и хочет разбираться с DDE, OPC, Builder C++ и т.п. . Про себя скажу - лично мне проще и быстрее построить график в CoDeSys, чем париться с вышеупомянутым билдером.

Прохожий
10.08.2007, 03:39
ИМХО, все же самое важное про HMI было упомято ранее - значительное число пользователей не знает и хочет разбираться с DDE, OPC, Builder C++ и т.п. . Про себя скажу - лично мне проще и быстрее построить график в CoDeSys, чем париться с вышеупомянутым билдером.

А мне лично гораздо проще нарисовать график на канве формы в Builder-е, чем разбираться почему здесь рисует, а там нет в предлагемом HMI. Согласитесь, что в общем случае - это личное дело разработчика.

Прохожий
10.08.2007, 04:16
HMI – это нормальный программный продукт, цена которого объективно рассчитывается из объема необходимого технического сопровождения. Она абсолютно одинакова во всех странах + местный НДС.
В HMI не предусмотрены никакие технические ограничения по числу переменных. Т.е. его цену правильнее было бы сравнивать с ценой SCADA систем, по строке прайса 'неограниченное число каналов'…

Да кто бы спорил. Продукт действительно конкурентоспособный. Тем более по сравнению со SCADA.



На этапе проектирования и отладки для визуализации вполне можно использовать CoDeSys – это бесплатно. На серьезные проекты операторам лучше все же ставить HMI, чтобы оператор мог видеть только то, что ему положено и делать только то, что он должен делать и гарантированно не мог ничего испортить. При установке HMI в программе вообще нет никаких переделок – чисто орг. вопрос. В рамках всего проекта затраты на HMI незначительны и вполне оправданы. (Конечно, если речь идет не об автоматизации сортира для бомжей на их же средства…)

Не скажите, стоимость ПЛК100 порядка 8000 руб., стоимость дешевого аппарата с монитором 12 000 руб. При этом стоимость Вашей HMI составляет 8000 руб. А это не иначе как 30% от проекта.
А фразу про сортиры для бомжей я обязательно передам своему заказчику. Он из тех, кто привык считать свои кровно заработанные деньги. Надеюсь это его позабавит.



Технически плюсы использования встроенной визуализации CoDeSys и HMI такие:
- Быстродействие, надежность, очень скромные требования к компьютеру. HMI работает с контроллером напрямую по его родному протоколу связи. DDE сервер же использует механизм сообщений Windows (передаются через общую очередь без всякой гарантии времени доставки). Т.е. время обновления данных и время реакции на команды оператора в HMI по определению лучше, чем через OPC и тем более DDE.

А мне наносекунды не нужны. И потом, расшифруйте достаточно общую фразу про родной протокол. Что там за механизмы? Неужели именованные каналы? С учетом того, что Винда - система многозадачная и многопотоковая сам механизм доставки на эту самую доставку практически не влияет. А то, что DDE использует обычные сообщения так это не минус, а плюс. Это дает жить другим процессам и потокам полновесной жизнью в рамках операционной системы.



Компьютер под HMI можно ставить самый дешевый, требования к процессору и памяти практически никакие.
- Простота применения. Все картинки рисуются прямо в среде программирования и элементарно связываются с переменными проекта. Не нужно конфигурировать всякие серверы и пр. промежуточные штуки. Никакого программирования нет вообще, не нужно ничего настраивать (есть связь со средой программирования == визуализация гарантировано работает). Не нужно разбираться со вспомогательными инструментами, все интегрировано в одной среде.

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

Пункт номер 2.
В бесплатный комплект поставки CoDeSys входит GatewayDDEServer. Получается, что я не могу его использовать, хотя фирма 3S этого делать не запрещает.
Объясните мне, почему я должен отдать 8000 руб. за копию достаточно примитивной HMI фирме "Пролог", хотя 3S предлагает мне не делать этого.

Малышев Олег
10.08.2007, 08:10
А мне лично гораздо проще нарисовать график на канве формы в Builder-е, чем разбираться почему здесь рисует, а там нет в предлагемом HMI. Согласитесь, что в общем случае - это личное дело разработчика.
Уважемый прохожий, ни сколько не сомневаюсь что Вам проще использовать билдер.
А вообще безумно рад, что 3S максимально открытая система (за что ее и любим :) ). Хочешь встроенной визуализацией пользуйся, не хочешь делай сам. А хочешь купи SCADA за n тыс у.е. и пользуй OPC. А жалко денег на комп - и негде его ставить бери ИП320 или другую и пользуй.
Интеграция и открытость - вот путь к сердцу современного пользователя

Прохожий
11.08.2007, 00:18
А вообще безумно рад, что 3S максимально открытая система (за что ее и любим :) ). Хочешь встроенной визуализацией пользуйся, не хочешь делай сам. А хочешь купи SCADA за n тыс у.е. и пользуй OPC. А жалко денег на комп - и негде его ставить бери ИП320 или другую и пользуй.
Интеграция и открытость - вот путь к сердцу современного пользователя
Вот и я про то же. В связи с этим, не могу не сделать комплемент конторе, на чьей площадке мы общаемся, по поводу CoDeSys и ПЛК100/150. Все сделано вовремя и абсолютно верно. Несмотря на все недостатки и трудности, готовый продукт получается в разы дешевле, чем аналогичный на любой другой платформе.
Опять же соглашусь с Вами по поводу гибкости и некого универсализма. Хочешь примитивный ПЛК - пожалуйста, хочешь к ПЛК систему сбора данных - тоже пожалуйста. Хочешь приделать к системе свой уникальный девайс - нет проблем. Практически есть все и в общем-то достаточно дешево.
В связи с ИП320 вопрос - планируется ли увеличение разрешения и площади экрана, сенсорная панель и прочие прелести?

Малышев Олег
13.08.2007, 07:58
Пока идет анализ ситуации с панелями. Если бы Вы порекомендовали что именно для Вас интереснее(параметры) было бы просто замечательно.

Игорь Петров
13.08.2007, 15:16
Вообще, с какого фонаря железо должно быть дешевле чем ПО? Железки могут штамповать роботы, чем больше, тем дешевле. ПО – штука сложная, требует постоянного человеческого внимания и заботы…


Не скажите, стоимость ПЛК100 порядка 8000 руб., стоимость дешевого аппарата с монитором 12 000 руб. При этом стоимость Вашей HMI составляет 8000 руб. А это не иначе как 30% от проекта....

Попутно, в этом расчете Windows не учитывается? :)

К одному единственному ПЛК на 8 входов стыкуется компьютер + полноценная визуализация? Очень уж шикарно получается… Обычно HMI ставят на системы с большим числом входов/выходов + датчики, арматура, привода, стоимость проектирования, монтажа и др. Тут совсем другие проценты…

Для локальных же систем есть ИП320. Очень здорово, что компания Овен делает именно то, что хотят заказчики, не пытаясь объяснять, что они должны хотеть.


И потом, расшифруйте достаточно общую фразу про родной протокол. Что там за механизмы?
Это достаточно простой протокол, основанный на обмене сообщениями. Он используется для загрузки программы, отладки, в том числе чтения/установки значений переменных. Он не зависит от физического канала. Может быть RS232, CAN, можно запустить и по именованным каналам. Это не важно. Суть в том, что OPC сервер и DDE сервер работают через него, естественно добавляя свои накладные расходы по памяти и скорости передачи.

Сейчас сервер DDE с CoDeSys используют очень редко, обычно OPC.

У 3S существует еще один дополнительный продукт: PLC Handler. Это инструментальный набор библиотек для C++, позволяющий напрямую (без OPC и DDE серверов) обращаться к данным в контроллерах с CoDeSys. (Подробнее (http://www.3s-software.ru/index.shtml?ru_PLCHandler)) Этот продукт не дешевый, он предназначен для разработчиков специализированных SCADA систем и др. спец. ПО верхнего уровня. Иногда бывают такие приложения (например, ЧПУ или панели управления на локомотивах), когда скорость или надежность OPC не устраивают и есть задача исключить все промежуточные компоненты. Такая нужда возникает редко, но сильно, поэтому 3S придумано решение и на этот случай.


… картинки в Вашей HMI достаточно примитивные, а у меня запланирована анимированная 3D графика. Сейчас это достаточно модно…
В CoDeSys визуализации действительно нет 3D графики и не планируется ее реализовывать. На это есть стратегические соображения: HMI принципиально нацелен несколько на другие задачи чем SCADA системы и внутри устроен иначе. Главная идея его развития состоит в том, чтобы все вычисления делались в контроллере (в перспективе), а не в компьютере, включая преобразование графики в элементарные команды прорисовки, которые затем отдаются собственно отображалке. 1) Это позволит использовать 'сверхтонкие клиенты' для отображения. Т.е. сама отображалка должна быть примитивно простой (ПО - две странички исходного текста). Это может быть тупая графическая панель (подключенная к ПЛК), web-браузеры, наладонник, сотовый телефон, HMI (причем все это одновременно и параллельно). Поток данных между отображалкой HMI и контроллером (в CoDeSys V3) – это не значения переменных, а перемещения мышки, коды клавиш и команды прорисовки. 2) Рост числа переменных в ПЛК вовлеченных в визуализацию не приводит к росту трафика. Можно снимать достоверные тренды с любой частотой, даже при не надежном канале связи. 3) Визуализация – это просто одна из задач МЭК, она полностью написана на МЭК языках. Все типовые элементы графики написаны на МЭК языках. Прямо в программе ПЛК можно рисовать картинки и писать свои биб-ки элементов. 4) С графикой можно связывать программы. Например, щелчок мышкой по элементу = немедленный вызов соотв-го обработчика, а не просто изменение переменной. 5), 6) пока секрет :)
Чтобы все это хорошо работало на любых железках (включая самые дешевые контроллеры и панели) приходится отказываться от всяческих украшательств, в пользу быстродействия и функциональности.
Для верхнего уровня операторского управления уже есть масса замечательных SCADA систем и нет смысла изобретать велосипед, интереснее делать то, что еще никто в мире не делал.


В бесплатный комплект поставки CoDeSys входит GatewayDDEServer. Получается, что я не могу его использовать, хотя фирма 3S этого делать не запрещает. Объясните мне, почему я должен отдать 8000 руб. … "Пролог", хотя 3S предлагает мне не делать этого.
Абсолютно никто не заставляет покупать HMI. Если он не подходит по любым причинам, то не нужно никому это доказывать, просто не используйте его. Это дополнительный инструмент. Все необходимые для работы инструменты комплекса CoDeSys поставляются в комплекте с контроллерами Овен бесплатно, включая OPC и DDE серверы.

Прохожий
14.08.2007, 19:32
Пока идет анализ ситуации с панелями. Если бы Вы порекомендовали что именно для Вас интереснее(параметры) было бы просто замечательно.
Вполне бы устроило на первое время что-то вроде NT2S от OMRON (сейчас снята с производства).
На память приблизительно следующее:
Монохром с разрешением 240 х 320 (2 градации).
Сенсорный экран
Подсветка белая
Память на 3000 экранов
Число тэгов не точно не помню.
Только цена не должна быть очень большой (до 15000 рублей).

Прохожий
14.08.2007, 19:59
Вообще, с какого фонаря железо должно быть дешевле чем ПО? Железки могут штамповать роботы, чем больше, тем дешевле. ПО – штука сложная, требует постоянного человеческого внимания и заботы…

Вообще-то железку разработать и сопровождать в производстве надо, да и роботы денег стоят, и в цеху противно и шумно. Опять же электричество, материалы и пр.
А про ПО не стоит. Постоянно сталкиваюсь, да и сам занимаюсь понемногу. Так, что сравнить условия могу абсолютно квалифицированно. ПО должно быть бесплатно и распространяться вместе с "железом". Например, как CoDeSys с ПЛК "Овен".
Какие там финансовые отношения между 3S и фирмой Овен меня совершенно не интересует. Главное, что конкретный результат вполне пристойный по соотношению цена/возможности и ПО для меня бесплатно.



Попутно, в этом расчете Windows не учитывается? :)

Windows98, по-моему, уже бесплатна, или нет?



К одному единственному ПЛК на 8 входов стыкуется компьютер + полноценная визуализация? Очень уж шикарно получается… Обычно HMI ставят на системы с большим числом входов/выходов + датчики, арматура, привода, стоимость проектирования, монтажа и др. Тут совсем другие проценты…

Скажем так, все остальное аппаратно привязано к старому оборудованию через Modbus/RTU за не очень большие деньги. А для того, чтобы растянуть сетку много затрат не надо.



Сейчас сервер DDE с CoDeSys используют очень редко, обычно OPC.

Но OPC - это COM технологии, на мой взгляд, вещь достаточно скользкая.



Абсолютно никто не заставляет покупать HMI. Если он не подходит по любым причинам, то не нужно никому это доказывать, просто не используйте его. Это дополнительный инструмент.

А на мой взгляд, общественность должна быть осведомлена о более дешевых способах отображения информации. Что я и посчитал своим долгом сделать.



Все необходимые для работы инструменты комплекса CoDeSys поставляются в комплекте с контроллерами Овен бесплатно, включая OPC и DDE серверы.

Так давайте ими и будем пользоваться. Сэкономим денег заказчику и себе немного больше заработаем.

Игорь Петров
15.08.2007, 12:27
Вообще-то железку разработать и сопровождать в производстве надо, да и роботы денег стоят, и в цеху противно и шумно. Опять же электричество, материалы и пр. А про ПО не стоит… .

:confused: Совершенно не понятно, почему ПО (любое) должно быть бесплатным. Работа программиста нисколько не легче, чем электромонтажника или наладчика. По моему мнению, даже тяжелее. Вполне имеет право на жизнь бизнес модель с платным ПО и бесплатным железом (такое встречается с эволюционными платами для компиляторов).
:cool: Беда в том, что в своем отечестве мы уже привыкли использовать ворованное ПО, покупая CD за 30 руб. со всем возможным софтом. В итоге ПО вообще не воспринимается как продукт. Обычно заказчик невинно улыбаясь спрашивает: 'А почему я должен тебе платить за программу? Она у тебя уже написана. Просто перепиши мне ее на дискету. За дискету я заплачу…' Вот такой клин в головах практически у всех сидит.
То, что инструментальное ПО CoDeSys идет с контроллерами бесплатно – это абсолютно верно для России в силу описанного выше клина. В западных странах ситуация иная: слово 'бесплатное' воспринимается людьми как синоним словам 'халтурное' 'бросовое', в том числе и по отношению к ПО (как и дешевая еда = просроченная, протухшая). Поэтому многие изготовители ПЛК берут деньги за инструментальное ПО. В процентном отношении к общей прибыли – это слезы, больше мороки с оформлением документов, но так надо для создания правильного имиджа компании.


А на мой взгляд, общественность должна быть осведомлена о более дешевых способах отображения информации. Что я и посчитал своим долгом сделать. Так давайте ими и будем пользоваться. Сэкономим денег заказчику и себе немного больше заработаем. .

Это так, если считать свою собственную работу бесплатной. Зачем платить за экскаватор, если котлован можно выкопать лопатой?
Можно купить готовый отработанный инструмент и быстро сдать работу и спокойно взяться за новую, если она есть и выгодна. Можно делать все самим, если есть время и желание (включая железо). Кому как удобнее. Разные варианты доступны, можно придумать и еще десяток.

Еще один момент: бесплатность самой среды программирования CoDeSys не означает, что бесплатными обязаны быть все дополнительные (не обязательные) компоненты и сервисы. Это относится к компонентам, которые может сделать любой человек или компания (включая 3S, Пролог и др.). Вы вполне можете написать свои биб-ки, свою супер-пупер среду визуализации и др. для CoDeSys и продавать их. Этого никто не запрещает. Против такой позиции нет возражений?

Василий Куц
15.08.2007, 13:04
Игорь Владимирович - есть, все еще не прояснен механизм лицензирования ;)

Игорь Петров
15.08.2007, 17:27
..все еще не прояснен механизм лицензирования ;)

Чего именно?
Если вопрос относится к CoDeSys HMI, то нормальная последовательность его покупки следующая:
1) Используя встроенную в CoDeSys визуализацию, полностью выполняем разработку. Покупать пока ничего не надо. Ставим CoDeSys HMI из бесплатного дистрибутива, на машину где будет работать оператор. Все окончательно проверяем и отлаживаем, убеждаемся, что все хорошо и HMI нас устраивает.
2) Посылаем заявку на приобретение HMI в свободной форме, с указанием реквизитов компании, в адрес 3S или любого ближайшего дистрибьютора. (Цена у всех абсолютно одинакова) Оплачиваем счет. Данные о вашей компании и количестве имеющихся лицензий заносятся во внутреннюю базу данных 3S.
3) На операторской машине запускаем 3S Licensing Manager. Нажимаем кнопку Add Licence и следуем инструкциям (выбираем CoDeSys HMI в списке, вводим название компании и др.). На последнем шаге есть 3 варианта: 1) Запросить лицензию в online автоматически, если машина связана с И-нет. Либо записать инф-ю в файл, который нужно будет передать в 3S (мыло, факс и др). 2) Либо по телефону. 3) Либо можно активировать срочную лицензию. Она активируется моментально и действует 14 дней, в теч. которых нужно получить нормальную. Для варианта 1, от 3S приходит мыло с лицензионным файлом. Он активируется кнопкой InstallLicense.
Все. Почтой высылается счет-фактура, CD и стикер - лицензионная марка, которая является документальным подтверждением наличия лицензии. При желании, ее можно наклеить на компьютер, дабы всем было видно, что все ПО лицензионное. Активировать лицензию можно сразу, не дожидаясь почтовой доставки. Лицензии бессрочные. Если вдруг компьютер сломается и будет заменен, то всегда можно моментально активировать срочную лицензию.

Василий Куц
15.08.2007, 17:36
Понятно, спасибо за разъяснения. Неплохо было бы, если бы все эти ньюансы были бы представлены где-либо.

Прохожий
15.08.2007, 21:44
Совершенно не понятно, почему ПО (любое) должно быть бесплатным. Работа программиста нисколько не легче, чем электромонтажника или наладчика. По моему мнению, даже тяжелее.

Работа программиста гораздо легче, чем работа сменного инженера или наладчика на реально работающем производстве, который постоянно имеет дело с плодами труда этого программиста. Условия труда, нагрузки абсолютно разные. У программиста на обдумывание или поиск того или иного решения времени гораздо больше, чем у наладчика.



Вполне имеет право на жизнь бизнес модель с платным ПО и бесплатным железом (такое встречается с эволюционными платами для компиляторов).

Ни разу не видел. Как правило, что компилятор, что демобоард стоят несуразных денег.



Беда в том, что в своем отечестве мы уже привыкли использовать ворованное ПО, покупая CD за 30 руб. со всем возможным софтом. В итоге ПО вообще не воспринимается как продукт. Обычно заказчик невинно улыбаясь спрашивает: 'А почему я должен тебе платить за программу? Она у тебя уже написана. Просто перепиши мне ее на дискету. За дискету я заплачу…' Вот такой клин в головах практически у всех сидит.

Страну нам с Вами никто не поменяет. А софт должен стоить денег только в случае, когда его (этот софт) просят сделать. К примеру, софт для протоколирования состояния технологического оборудования, изначально на этом оборудовании не предусмотренный.



То, что инструментальное ПО CoDeSys идет с контроллерами бесплатно – это абсолютно верно для России в силу описанного выше клина. В западных странах ситуация иная: слово 'бесплатное' воспринимается людьми как синоним словам 'халтурное' 'бросовое', в том числе и по отношению к ПО (как и дешевая еда = просроченная, протухшая).

Ну да, поэтому зачастую многие производители софта берут OpenSourse проекты, косметически перерабатывают и продают как свое. А источники называют "халтурой". Это не более, чем маркетинговый ход. Я лично наблюдал как те же немцы самогон пили ведрами, потому как на халяву.



Поэтому многие изготовители ПЛК берут деньги за инструментальное ПО. В процентном отношении к общей прибыли – это слезы, больше мороки с оформлением документов, но так надо для создания правильного имиджа компании.

Особенно фирма SIEMENS плачет, но продает свой софт по совершенно "бросовым" ценам. Кургузый S7 по цене автомобиля.



Это так, если считать свою собственную работу бесплатной. Зачем платить за экскаватор, если котлован можно выкопать лопатой?
Можно купить готовый отработанный инструмент и быстро сдать работу и спокойно взяться за новую, если она есть и выгодна. Можно делать все самим, если есть время и желание (включая железо). Кому как удобнее. Разные варианты доступны, можно придумать и еще десяток.

Про лопату. Можно и динамитом. Дешево и быстро.:). Только далеко не все умеют.
Каждому заказчику - индивидуальный подход. Кому-то, у кого деньги, можно и подороже и побыстрее, другим, кто победнее, можно подешевле и помедленнее. Нельзя всех стричь одинаково. Прически должны быть разные и индивидуальные.



Еще один момент: бесплатность самой среды программирования CoDeSys не означает, что бесплатными обязаны быть все дополнительные (не обязательные) компоненты и сервисы. Это относится к компонентам, которые может сделать любой человек или компания (включая 3S, Пролог и др.). Вы вполне можете написать свои биб-ки, свою супер-пупер среду визуализации и др. для CoDeSys и продавать их. Этого никто не запрещает. Против такой позиции нет возражений?

Я занимаюсь такого рода вещами в индивидуальном порядке. Только тогда, когда заказчик изначально готов оплатить эту работу и только в рамках заранее оговоренного ТЗ и не говорю при этом, что мой софт супер, а тем более пупер.:)

Игорь Петров
16.08.2007, 14:17
Работа программиста гораздо легче, чем работа сменного инженера или наладчика…У программиста на обдумывание или поиск того или иного решения времени гораздо больше, чем у наладчика
Ну, ну… Голова к вечеру от этой легкой работы такая, что не всегда заснуть к утру получается. На часовом заводе мне останавливали конвейер на обед для корректировки ПО. Условие было простое: 'не успеешь переделать свою программу за час, будешь сам работать вместо сборочного автомата'. При социализме было время на размышления, сейчас хлеб с вареньем пролетает мимо рта с такой скоростью, что повернуться не успеваешь, как его уже кто-нибудь проглотил.


Страну нам с Вами никто не поменяет.
Страну менять и не надо, но отношение к плодам интеллектуального труда постепенно обязано измениться в цивилизованную сторону. ПО – это точно такой же продукт как ботинки или автомобиль. Более того, хороший изготовитель обязан его постоянно поддерживать, иначе это ПО помрет. Т.е. программист обязан постоянно работать с ним. Если он написал программу и получил зарплату в январе, он что всю оставшуюся жизнь обязан работать бесплатно?


А софт должен стоить денег только в случае, когда его (этот софт) просят сделать.
Потрясающая мысль! Рассмотрим пример: допустим, лично Вы просите меня сделать некую специальную штуку, расширяющую возможности CoDeSys. Я вижу, что идея отличная и штука эта нужна многим.
Подход 1: я выставляю Вам счет на нормальные деньги за всю эту разработку. Выполняю работу. Затем всем другим пользователям раздаю эту штуку даром. Нравится?
Подход 2: я вкладываю в разработку свои собственные средства. Затем со всех кому это реально надо, беру небольшую сумму, которая делится на всех. За счет большого числа заказчиков цены оказываются доступными. Перед покупкой можно все проверить и убедиться, что это именно то, что нужно.

Сейчас мы работаем исключительно по второй схеме. На мой взгляд, она более демократичная. Разве нет?


Я занимаюсь такого рода вещами в индивидуальном порядке. Только тогда, когда заказчик изначально готов оплатить эту работу…
Хорошо, если так получается. Как правило, в разработку никто не хочет вкладывать средства.

Прохожий
17.08.2007, 03:06
Ну, ну… Голова к вечеру от этой легкой работы такая, что не всегда заснуть к утру получается. На часовом заводе мне останавливали конвейер на обед для корректировки ПО. Условие было простое: 'не успеешь переделать свою программу за час, будешь сам работать вместо сборочного автомата'. При социализме было время на размышления, сейчас хлеб с вареньем пролетает мимо рта с такой скоростью, что повернуться не успеваешь, как его уже кто-нибудь проглотил.

А у меня, как у сменного инженера, каждый день такое. Все очень просто. Простой машины в 10 - 15 мин. выливается в очень крупную сумму. Делай что хочешь, но машина должна работать. Причем разбираться надо отнюдь не в своем софте... И таких машин у меня в смене порядка нескольких сотен.
На фоне этой работы есть еще и задачи модернизации устаревшего, но необходимого производству оборудования. Тут же всякие бумажки по заказу запчастей, расходных материалов, отчеты по смене и т. д.
Опять же и подработать помимо основной деятельности тоже надо... Заказчик хочет подешевле. Отсюда CoDeSys и DDE сервер.
Вопрос. Кому все-таки жить проще? Мне или программисту, катающему целый день карандаш по столу?



Страну менять и не надо, но отношение к плодам интеллектуального труда постепенно обязано измениться в цивилизованную сторону. ПО – это точно такой же продукт как ботинки или автомобиль. Более того, хороший изготовитель обязан его постоянно поддерживать, иначе это ПО помрет. Т.е. программист обязан постоянно работать с ним. Если он написал программу и получил зарплату в январе, он что всю оставшуюся жизнь обязан работать бесплатно?


ПО, кроме компьютерных игрушек - это не конечный продукт, как ботинки или автомобиль. Поэтому и отношение к нему такое.
Насчет поддержки. Скажите мне, как часто к Вам приходят специалисты из Merloni Eletrecciti , чтобы перезалить софт в микроконтроллере Вашего Indesit-а или Ariston-а? Софт надо создавать приблизительно как кирпич -положил его в стену и забыл. И не нужно с ним после этого работать.
За это разработчик и получает зарплату, как в январе, так и во все остальные месяцы. Он создает новые модели стир. машин и холодильников, а не исправляет старые.



Потрясающая мысль! Рассмотрим пример: допустим, лично Вы просите меня сделать некую специальную штуку, расширяющую возможности CoDeSys. Я вижу, что идея отличная и штука эта нужна многим.
Подход 1: я выставляю Вам счет на нормальные деньги за всю эту разработку. Выполняю работу. Затем всем другим пользователям раздаю эту штуку даром. Нравится?
Подход 2: я вкладываю в разработку свои собственные средства. Затем со всех кому это реально надо, беру небольшую сумму, которая делится на всех. За счет большого числа заказчиков цены оказываются доступными. Перед покупкой можно все проверить и убедиться, что это именно то, что нужно.

По пункту N1. Если я, как заказчик оплатил Вам разработку в полном объеме, то ничего Вы раздавать не будете. Потому, что разработка после оплаты становится моей, а не Вашей. Если Вам угодно, то раздавать это дело буду я.
По пункту N2. Стоимость лицензионной копии компьютерной игрушки составляет в среднем 10 - 20 $, в редких случаях 30$. Стоимость специализированного пакета от Borland я уже озвучивал.
Почему же Вы, как разработчик и продавец софта вынуждаете меня заниматься несвойственной мне работой в виде написания собственной HMI из-за несуразной дороговизны Вашего продукта?
Если бы HMI стоила 40-50$ и обеспечивала бы надежную поддержку базы данных минутных событий на год, то я бы никогда не заморачивался с DDE сервером.



Хорошо, если так получается. Как правило, в разработку никто не хочет вкладывать средства.

Это смотря как подойти к этому вопросу. Если заниматься с каждым клиентом индивидуально, то еще как хотят. Просто желания у них достаточно экзотические и у всех разные.

И еще. Просто любопытно. Почему 3S не делает порты CoDeSys на вычислители с бесплатной средой разработчика?

Игорь Петров
17.08.2007, 14:03
…Кому все-таки жить проще?
ОФФ: Каждому чужая работа кажется проще, оставим вопрос для философского форума.


Софт надо создавать приблизительно как кирпич -положил его в стену и забыл. И не нужно с ним после этого работать.
Даже и встраиваемое ПО также не забивается в стену и не выбрасывается. Оно постоянно развивается. Многие новые модели бытовой техники отличаются только новыми программными функциями. Программист постоянно исправляет и дорабатывает старое ПО, а не пишет его с нуля. Чтобы получить стир. машину, которая лучше стирает и не скачет по полу при отжиме, мне пришлось купить новую, несмотря на то, что железо вообще не требовало замены. Т.е. апгрейд ПО здесь получается очень дорогой.

Инструментальное ПО очевидно также должно постоянно развиваться, дабы удовлетворять развитию запросов пользователей и быть конкурентоспособным. Сверх того, с ним работает человек, у него возникают вопросы. На них нужно отвечать = нужен специалист, который будет этим заниматься. Нужно грамотно и внятно написать документацию = нужен еще один специалист. Всех нужно кормить. Поэтому ничего удивительного в том, что инструментальное ПО стоит денег нет.


Если я, как заказчик оплатил Вам разработку в полном объеме, то ничего Вы раздавать не будете. Потому, что разработка после оплаты становится моей, а не Вашей.
Это как составить договор. Как и ожидалось идея, заплатить за все не понравилась. Т.е. 3S должна таки провести разработку за свой счет, затем продавать готовый софт, а не раздавать даром.


Стоимость лицензионной копии компьютерной игрушки составляет в среднем 10 - 20 $…
Сравнение HMI с игрушками ошибочно, тиражность тут близко не сравнима. Ближе всего SCADA системы. HMI стоит минимум раз в 5 дешевле. Сделать еще дешевле пока просто не реально, поскольку разбегутся работники, зарплата у которых и так оставляет желать…


Если бы HMI стоила 40-50$ и обеспечивала бы надежную поддержку базы данных минутных событий на год, то я бы никогда не заморачивался с DDE сервером.
Запись архива событий на год в HMI несложно организовать с использованием механизма алармов. Например, можно задать хранение данных в файлах по месяцам и автоматическое удаление старше года. Программировать для этого вообще ничего не надо.

С большой вероятностью можно предположить, что заказчику купившему 10 комплектов HMI не потребуется в 10 раз большая тех. поддержка. Поэтому вполне можно говорить о существенных скидках для постоянных покупателей.


Почему 3S не делает порты CoDeSys на вычислители с бесплатной средой разработчика?
Не понял вопроса. 3S вообще не делает никакие порты. Какие именно вычислители?

Прохожий
17.08.2007, 19:49
ОФФ: Каждому чужая работа кажется проще, оставим вопрос для философского форума.

Оставим...



Инструментальное ПО очевидно также должно постоянно развиваться, дабы удовлетворять развитию запросов пользователей и быть конкурентоспособным. Сверх того, с ним работает человек, у него возникают вопросы. На них нужно отвечать = нужен специалист, который будет этим заниматься. Нужно грамотно и внятно написать документацию = нужен еще один специалист. Всех нужно кормить. Поэтому ничего удивительного в том, что инструментальное ПО стоит денег нет.

Правильно. Но продажа чистого ПО, на мой взгляд, в нашей стране не пройдет никогда. ПО длжно быть к чему-то: CoDeSys к ПЛК100/150/154, программка стирки к МК от стир. машины, MPLAB к микроконтроллерам от Microchip.
Иными словами, никто не запрещает Вам увеличивать стоимость изделия - ПЛК, стир. машины, микросхемы МК на величину потраченного на него времени в виде программирования как такового или создания инструментального софта к нему.



Это как составить договор. Как и ожидалось идея, заплатить за все не понравилась. Т.е. 3S должна таки провести разработку за свой счет, затем продавать готовый софт, а не раздавать даром.

Никто не говорит про "раздавать даром". За софт фирме 3S платит производитель ПЛК. А я, как потребитель, покупая его (ПЛК) оплачиваю, как труд разработчиков ПЛК, так и труд сотрудников 3S. Очень похоже на стиральную машину. Именно к такой форме оплаты софта я и призываю. Здесь все просто и понятно.



Сравнение HMI с игрушками ошибочно, тиражность тут близко не сравнима. Ближе всего SCADA системы. HMI стоит минимум раз в 5 дешевле. Сделать еще дешевле пока просто не реально, поскольку разбегутся работники, зарплата у которых и так оставляет желать…

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



Не понял вопроса. 3S вообще не делает никакие порты. Какие именно вычислители?

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

Филоненко Владислав
20.08.2007, 08:44
Дело не в платности/бесплатности, а в ресурсах процессора.

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

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

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

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

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

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

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

Игорь Петров
22.08.2007, 14:31
Никто не говорит про "раздавать даром". За софт фирме 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 компаний, способных делать передовые изделия соответствующего качества.

Игорь Петров
22.08.2007, 15:56
Попробовав написать проект для HMI я, к сожалению не встретил активной поддержки - пользователи, видимо, не слишком часто его используют, да и фирма 3S с ПРОЛОГом не очень-то активно отвечают на вопросы..
Только что вернулся из командировки с завода, где только на одной машине используется 40 ПЛК с визуализацией в CoDeSys. Таких машин много. К HMI у прикладных программистов замечаний нет вообще. Это квалифицированные люди, имеющие большой опыт работы. Возможно, они просто умеют правильно применять встроенную визуализацию? Практически HMI используется и достаточно широко, ежедневно и круглосуточно.

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


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


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

Прохожий
22.08.2007, 21:41
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 битовых данных.

Прохожий
22.08.2007, 22:58
Именно так и есть, причем никто не собирается это менять. Это касается всех базовых компонентов. Обратите внимание, что даже OPC и DDE серверы поставляются бесплатно!

Вот за это фирме 3S большое спасибо (без всяких шуток), поскольку - это абсолютно правильный и взвешенный подход.



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

И здесь я с Вами соглашусь насчет огромной разнообразности требований.
Но в силу специфики моего (опять же условно) подхода - конечный продукт получается уникальным, ориентированным, исключительно на конкретного заказчика. В ряде случаев приходится рисовать подробные 3D модели уникального оборудования заказчика и включать их в проект.
В то же время, имеются готовые проверенные заготовки - та же работа с базами данных, стыковка с определенными типами ПЛК разных производителей (SIEMENS или OMRON), ну и еще всякие разности. И все это добро собирается в единый проект, исходя из ТЗ заказчика. В этом случае там не остается ничего лишнего, в отличие от SCADA систем. Но с другой стороны, такой проект больше никому не интересен, поскольку лишен универсализма и избыточности SCADA.



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

Насчет трудоемкости позволю себе не согласиться.
Дело в том, что для того, чтобы сделать ту же самую приличную базу данных (с многочисленными формами, кешированием, и прочей ерундой) на любой из SCADA систем, Вам все равно придется написать большое количество текста, в виде скриптов (в свое время пришлось заниматься именно этим). Как правило, перепрыгнуть через SQL и прочую атрибутику БД не удается, особенно, если требуется еще и экспорт в различные специфические пакеты. А когда объем становится значительным, то становится жалко собственный труд при переходе с одной SCADA к другой. Отсюда и возникает желание делать все с помощью некого универсального инструмента, каковым и является тот же Builder или Visual Studio.
Иными словами, надеоело каждый раз разбираться со спецификой той или иной SCADA, в том числе и HMI. На это уходит огромное количество времени.



Практически все изготовители оборудования дают OPC сервера для стыковки с SCADA.

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



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

Ответ исчерпывающий, большое спасибо.
Только одно НО. Базовые технологические прорывы осуществляются именно в малых конторах. Пример той же самой 3S с их CoDeSys - отнюдь не исключение из правила. Вспомните Microsoft или Apple двадцатипятилетней давности. Лучше уж держать "кустарей-самодельшиков" под присмотром и тем или иным способом утилизировать их наработки, чем потом стремительно терять рынок, как это было в свое время с IBM или DEC и как это происходит нынче с тем же SIEMENS-ом.

незарегистрированный
23.08.2007, 21:53
Только что вернулся из командировки с завода, где только на одной машине используется 40 ПЛК с визуализацией в CoDeSys.
Очень хорошо, помогите разобраться.
1. При использовании трэндов назначил хранение данных на ПК (Recording->Hystory), но удаления файлов с устаревшими данными добиться не смог (delete old data after).
2. В тех же трэндах использовал маркер, но данные в переменной, назначенной маркеру, значительно отстают от линии маркера, причём от масштаба временной оси это не зависит.
3. Нарисовал примитив - линию поверх прямоугольника. Если линия горизонтальная, случается так, что средняя часть линии исчезает.
Заранее спасибо за ответ.

Игорь Петров
24.08.2007, 20:11
Очень хорошо...
:) Кому хорошо?


1. При использовании трэндов назначил хранение данных на ПК (Recording->Hystory), но удаления файлов с устаревшими данными добиться не смог (delete old data after).
Зачем? Здесь никакие файлы стираться и не должны, просто затираются старые записи по кольцу.


2. В тех же трэндах использовал маркер, но данные в переменной, назначенной маркеру, значительно отстают от линии маркера, причём от масштаба временной оси это не зависит.
Трассировка читает данные из ПЛК с некой периодичностью. Она задается настройкой Degree of accuracy (Степень детализации). Точность выдержки периода определяется тиками системного таймера контроллера. Значение переменной считывается, буферизируется и передается на компьютер.
Итак, в памяти ПЛК имеем массив замеров и ничего более! Маркер (переменная в памяти ПЛК) берет по заданному времени значение предыдущего замера. Все! Что еще он может взять даже теоретически?
При отображении плавной линии на компьютере выполняется интерполяция. Ее можно отключить и включить отображение только реально замеренных точек (Curve type – Points). Тогда будет четко видно, что маркер честно берет текущий замер.
http://www.prolog-plc.ru/3s/CoDeSys/Images/trace_xz1.gif
Реально можно гарантировать точность 'наведения' маркера по времени 2 Degree of accuracy.


3. Нарисовал примитив - линию поверх прямоугольника. Если линия горизонтальная, случается так, что средняя часть линии исчезает.
Попробовал на компьютере и контроллере (ПЛК Berghof (http://www.berghof-automation.de/Automation/en/Products+_+Solutions/CANtrol+Dialog/Dialog+Controller.html)со встроенным сенсорным экраном) не вижу этого. При каких условиях проявляется? Какова толщина линии? Возможно, связано с драйвером панели, линия при масштабировании целиком не попадает на отображаемые пиксели. С наклонными и толстыми линиями такого быть не должно.

Пожалуйста, обратите внимание: чтобы устранить проблему, ее нужно как минимум четко воспроизвести!!! Это совсем не так просто как кажется, она может не проявляться при других условиях. Системы исполнения CoDeSys SP и некоторые детали реализации могут иметь отличия в разных контроллерах, важно знать какой ПЛК, все настройки и др. Поэтому нужно максимально локализовать проблему (т.е. сделать предельно упрощенный проект, в котором она явно вылезает), создать архив проекта в CoDeSys, подробно описать, желательно указать название компании, когда продукт приобретен, координаты для связи и отправить это все группе поддержке.

Надеюсь, мои ответы оказались полезными!

Milchuk
25.08.2007, 13:53
Спасибо за ответ.
Использую ОВЕН ПЛК 150 У.М. CoDeSys 2.3.8.1

Зачем? Здесь никакие файлы стираться и не должны, просто затираются старые записи по кольцу.
Я пробовал вести один файл и устанавливал удаление данных после 1 часа. Безрезультатно - за 3 часа наблюдений файл пропорционально рос в размере.
Пробовал заводить новый файл по достижении определённого числа записей - файл заводится, но старые данные не стираются.
По вопросу с маркером период обновления данных трэнда был выбран примерно равным одному пикселю горизонтального масштаба, а отставание равнялось 20-30 сэмплам. ( Хотя почему бы маркеру не индицировать и апроксимированную величину?)
По вопросу с линией выходил из положения - в случае, если она горизонтальная, заменял прямоугольником. Постараюсь воспроизвести.

Игорь Петров
27.08.2007, 15:14
Использую ОВЕН ПЛК 150 У.М. CoDeSys 2.3.8.1
Я пробовал вести один файл и устанавливал удаление данных после 1 часа. Безрезультатно - за 3 часа наблюдений файл пропорционально рос в размере...

OK, спасибо за информацию. Проверим.

Хотя почему бы маркеру не индицировать и апроксимированную величину?

Как, подумайте? Маркер – это переменная в памяти ПЛК (именно это и требовалось при реализации этой фишки), интерполяция происходит уже наверху в ПК. В памяти ПЛК есть только замеры.
Прямо с графика можно снять значение в HMI. Оно будет точным, если его сразу тут моментально и отображать (так сделано в трассировке). Если же его переслать в ПЛК, затем вернуть в компьютер, то за это время маркер уедет.
Чтобы было и точно и доступно в ПЛК, нужно интерполяцию делать внутри ПЛК. См. выше описание стратегии развития визуализации в CoDeSys V3.
В V2.3 точности считывания значения по маркеру можно добиться при медленной (относительно частоты семплирования) скорости нарастания тренда.
Никакой ошибки тут нет, возможно не достаточно подробно описано в документации, обязательно добавлю в след. редакции.

Milchuk
30.08.2007, 00:39
Может я туплю...!?
Насколько я понимаю, данные о положении маркера рождаются в HMI и передаются в контроллер, где из массива данных, по-вашему, выбирается ближайшая точка, её значение передаётся переменной маркера. Так почему в этом месте не взять две ближайшие точки и не подсчитать, скажем, линейно аппроксимированное значение?
Но, в общем то не критично. Повторюсь, меня больше удивило несоответствие значений с картинкой графика, и это не объясняется попаданием маркера между точками сэмплирования.

Игорь Петров
30.08.2007, 12:58
...почему в этом месте не взять две ближайшие точки и не подсчитать, скажем, линейно аппроксимированное значение?
Где гарантия, что оно будет ближе к реальности? Между замерами вполне мог быть выброс. Сейчас маркер честно сообщает значение, которое контроллер некогда намерил. Его можно использовать в программе, оно совпадет с неким значением, которое реально использовалось в нашей программе. Сейчас маркер позволяет организовать обратную связь отображения с контроллером. Формируя выдуманное значение, мы лишаемся этой возможности.

Дискретная природа периодических отсчетов предполагает, что для адекватного отображения значение наблюдаемой переменной не должно существенно изменяться между замерами (что описывает теорема Котельникова). В противном случае кривая вообще не будет соответствовать действительности. Этот факт + движение графика и конечная скорость обмена данными (ПЛК-ПК) определят точность самого отображения и естественно данных маркера. Это нужно четко понимать и правильно использовать. Никакой аппроксимацией из линейки не сделать микрометр.

Для изучения быстрых процессов с считыванием значений маркеров непосредственно с графиков в CoDeSys есть инструмент Sumpling Trace, позволяющий снимать значения переменных в каждом рабочем цикле. При необходимости, здесь можно задать триггерное событие, по которому данные будут сфотографированы с нужной пред и после историей. Т.е. мы можем использовать данный инструмент как 'черный ящик' встроенный в ПЛК.

Chupakabra
10.09.2007, 15:28
Можно ли установить/запустить CoDeSysHMI отдельно от CoDeSys? Или ему требуется наличие CoDeSys?

murdemon
15.08.2018, 21:57
ну для 3-3 если вдруг RTC на ПК сломались и переставилось на год прибытия Т-800, а потом после 3-3 вдруг обратно. То Сара Коннор не погибнет, через 14 дней. :)