WinCON, WinPAC и прочий ICPDAS, Рунет глух, пора начинать обсуждать. Опции

[Lexman]

Вэлкам то все, кто сталкивался с этими девайсами. Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете, хотя Адастра и "яписитую" активно их рекламируют. Перешли на эту серию (WinCON) летом 2008го, сейчас на смену пошёл WinPAC. Есть некоторые проблемы с новинками, пока не буду изливать суть, по скольку не ясно, пользует ли их кто нибудь.
На всякий случай, для несведущих, напишу свои впечатления от использования , может появятся неравнодушные.
.
Вприницпе, железка неплохая. .
Модификации с разным кол-вом модулей расширения, от нуля до __ (см. в гугле).
На борту WinCE 4.2 (WinCON) и WinCE 5.0) (WinPAC). По идее, первый должен был смениться вторым, первый уже успели снять с проивзодства (поторопились!), но тем не менее, пока есть проблемы, и полностью перейти не удалось.
Из портов имеются несколько RS232 и RS485 (см гугл)., 2хUSB1.1 на WinCON и 1хUSB1.1. на WinPAC (зачем сократили?!), но на последнем также есть встроенный слот и флешка microSD на 1Гб. Ну, ессесно, в наличии VGA порт (цепляется любой дисплей), поддержка внешних клавиатур, мышек, тачпадов (проблема вот тут как раз). Плюс 2хEthernet 10.
Питание 12-36В, монтаж на DIN35 либо плоскость.
Короче, на руках вполне мощный компьютер, могущий гораздо больше, чем стандартные ПЛК. Ну и наличие достаточно мощной OC на борту, что очень удобно для программистов.
Программное обеспечение делал в VS2003 (WinPAC) и VS2008 (WinCON), на C#. Достаточно удобно: отладка через Ethernet, полностью аналогична отладке обычного софта на РС. Есть возможность установки дополнительных программных фитч для "превращения" в обычный ПЛК, или в SCADA-контроллер, но это за дополнительные деньги, не щупал. Кстати, есть ещё поставляемые в комплекте бесплатные утилиты, для превращения контроллера в точку сбора информации, но глубоко не вникал.
С точки зрения экономии финансов - почти не проигрывает ПЛК, т.к. нет необходимости программирования HMI (и покупки спец. софта для HMI, соответственно).
Но естественно - есть недоработки, которые на сей момент пытаюсь разрулить.
Если есть люди с опытом по даннму железу - вэлкам ещё раз. Сам поделюсь, чем смогу.

[Lexman]

Вэлкам то все, кто сталкивался с этими девайсами. Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете, хотя Адастра и "яписитую" активно их рекламируют. Перешли на эту серию (WinCON) летом 2008го, сейчас на смену пошёл WinPAC. Есть некоторые проблемы с новинками, пока не буду изливать суть, по скольку не ясно, пользует ли их кто нибудь.
На всякий случай, для несведущих, напишу свои впечатления от использования , может появятся неравнодушные.
.
Вприницпе, железка неплохая. .
Модификации с разным кол-вом модулей расширения, от нуля до __ (см. в гугле).
На борту WinCE 4.2 (WinCON) и WinCE 5.0) (WinPAC). По идее, первый должен был смениться вторым, первый уже успели снять с проивзодства (поторопились!), но тем не менее, пока есть проблемы, и полностью перейти не удалось.
Из портов имеются несколько RS232 и RS485 (см гугл)., 2хUSB1.1 на WinCON и 1хUSB1.1. на WinPAC (зачем сократили?!), но на последнем также есть встроенный слот и флешка microSD на 1Гб. Ну, ессесно, в наличии VGA порт (цепляется любой дисплей), поддержка внешних клавиатур, мышек, тачпадов (проблема вот тут как раз). Плюс 2хEthernet 10.
Питание 12-36В, монтаж на DIN35 либо плоскость.
Короче, на руках вполне мощный компьютер, могущий гораздо больше, чем стандартные ПЛК. Ну и наличие достаточно мощной OC на борту, что очень удобно для программистов.
Программное обеспечение делал в VS2003 (WinPAC) и VS2008 (WinCON), на C#. Достаточно удобно: отладка через Ethernet, полностью аналогична отладке обычного софта на РС. Есть возможность установки дополнительных программных фитч для "превращения" в обычный ПЛК, или в SCADA-контроллер, но это за дополнительные деньги, не щупал. Кстати, есть ещё поставляемые в комплекте бесплатные утилиты, для превращения контроллера в точку сбора информации, но глубоко не вникал.
С точки зрения экономии финансов - почти не проигрывает ПЛК, т.к. нет необходимости программирования HMI (и покупки спец. софта для HMI, соответственно).
Но естественно - есть недоработки, которые на сей момент пытаюсь разрулить.
Если есть люди с опытом по даннму железу - вэлкам ещё раз. Сам поделюсь, чем смогу.

[Михайло]

О полной замене ПЛК - миф чистой воды:
1. Ненадежно по сравнению с ПЛК
2. Никто в мире простые дискретные задачи не программирует на Cи. Только LAD, FBD, IL... Инженер-электроник не обязан знать Си и прочую требуху!

[Sniper007]

О полной замене ПЛК - миф чистой воды:
1. Ненадежно по сравнению с ПЛК
2. Никто в мире простые дискретные задачи не программирует на Cи. Только LAD, FBD, IL... Инженер-электроник не обязан знать Си и прочую требуху!

По второму пункту - категорически не согласен. Я считаю как раз наоборот, инженер ОБЯЗАН знать как минимум ДВА языка - английский и С (ну или любой другой высокого уровня).
Не согласен с тем, что дискретные задачи обязательно программировать на LAD. Если конечно альтернатив нет, то да. Но если вы работаете с Codesys (или любым другим софтом поддерживающими все языки МЭК), то писать на LD - мазохизм. С моей точки зрения ST (который аналог C) - гораздо удобнее.
А насчет того, что никто в мире не программирует на С дискретные задачи... Вы, я так понимаю весь объездили? Я вам завидую, и когда вы только время находите

По первому пункту согласен.

[Сергей Долганов]

Не согласен с тем, что дискретные задачи обязательно программировать на LAD. Если конечно альтернатив нет, то да. Но если вы работаете с Codesys (или любым другим софтом поддерживающими все языки МЭК), то писать на LD - мазохизм. С моей точки зрения ST (который аналог C) - гораздо удобнее.

Имхо Вы мазохист и есть, описывать словами дискретные задачи. ST хорош для аналога, для преобразований данных но никак не для дискретной логики.

[Sniper007]

Не вижу никаких сложностей, с тем чтобы описать дискретные задачи на ST.
Вот как раз сейчас делал дискретную задачу, писал на ST + SFC. Нормально получилось...

[Сергей Долганов]

Я не говорю о сложности, я говорю об удобстве.

[Sniper007]

Как правило эти два понятия взаимосвязаны.

[Гость_Old_*]

Вэлкам то все, кто сталкивался с этими девайсами. Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете, хотя Адастра и "яписитую" активно их рекламируют. Перешли на эту серию (WinCON) летом 2008го, сейчас на смену пошёл WinPAC. Есть некоторые проблемы с новинками, пока не буду изливать суть, по скольку не ясно, пользует ли их кто нибудь.
На всякий случай, для несведущих, напишу свои впечатления от использования , может появятся неравнодушные.
.
Вприницпе, железка неплохая. .
Модификации с разным кол-вом модулей расширения, от нуля до __ (см. в гугле).
На борту WinCE 4.2 (WinCON) и WinCE 5.0) (WinPAC). По идее, первый должен был смениться вторым, первый уже успели снять с проивзодства (поторопились!), но тем не менее, пока есть проблемы, и полностью перейти не удалось.
Из портов имеются несколько RS232 и RS485 (см гугл)., 2хUSB1.1 на WinCON и 1хUSB1.1. на WinPAC (зачем сократили?!), но на последнем также есть встроенный слот и флешка microSD на 1Гб. Ну, ессесно, в наличии VGA порт (цепляется любой дисплей), поддержка внешних клавиатур, мышек, тачпадов (проблема вот тут как раз). Плюс 2хEthernet 10.
Питание 12-36В, монтаж на DIN35 либо плоскость.
Короче, на руках вполне мощный компьютер, могущий гораздо больше, чем стандартные ПЛК. Ну и наличие достаточно мощной OC на борту, что очень удобно для программистов.
Программное обеспечение делал в VS2003 (WinPAC) и VS2008 (WinCON), на C#. Достаточно удобно: отладка через Ethernet, полностью аналогична отладке обычного софта на РС. Есть возможность установки дополнительных программных фитч для "превращения" в обычный ПЛК, или в SCADA-контроллер, но это за дополнительные деньги, не щупал. Кстати, есть ещё поставляемые в комплекте бесплатные утилиты, для превращения контроллера в точку сбора информации, но глубоко не вникал.
С точки зрения экономии финансов - почти не проигрывает ПЛК, т.к. нет необходимости программирования HMI (и покупки спец. софта для HMI, соответственно).
Но естественно - есть недоработки, которые на сей момент пытаюсь разрулить.
Если есть люди с опытом по даннму железу - вэлкам ещё раз. Сам поделюсь, чем смогу.

Эти девайсы не очень надежны и обсуждать их нечего.Известны случаи когда они теряли память программ и перегружались самопроизвольно в моменты сдачи проектов заказчику.У кого нет денег на нормальное железо юзают их.По поводу программерства-каждый пишет софт на том что ему ближе.Посему наверное все высказанное применимо.

[Гость_Astilya_*]

Собственно, WinCon-то они сняли. Заменив WinPAC. И получили стандартную для тайваньцев проблему: WinPAC поддерживают высокопрофильные модули, а их номенклатура еще крайне мала по сравнению с "обычными". Таким образом, одно уже сняли, а второе "до ума" не довели.

[ScrewDriver]

Как правило эти два понятия взаимосвязаны.

Во время отладки становится понятно, почему используется столько разных языков
ДИскретка на ST/IL/FBD/SFC плохо читаема, LD же читается одним взглядом.

[Sniper007]

Помню была такая реклама:
"- А вот я не люблю кошек...
- Ты просто не умеешь их готовить"

Не испытываю проблем при отладке на SFC и ST. Кроме того, с моей точки зрения, когда пишешь на ST, меньше ошибаешься (разумеется при наличие опыта).
Скажу по секрету. Сначала я тоже боготворил язык LD, считал что ничего удобнее придумать невозможно. Потом попробовал ST... Сразу же вспомнил все навыки программирования, полученные еще в школе, и понял на LD, без острой нужды, (вроде программирования Zelio) не вернусь.

А SFC... Мне кажется большинство процессов, в той или иной степени имеют, некую строгую последовательность. Пусть даже не вся задача целиком, а какие отдельные ее элементы. Вот для этих задач лучше языка, чем SFC придумать невозможно.

А языком много, потому что у всех разное образование, квалификация, навыки, личные пристрастия.
Вот мне как программисту, нравится ST. Если вам нравится LD или FBD - используйте.

Сообщение отредактировал Sniper007 - 30.3.2009, 12:08

[Abysmo]

В каждой организации есть свои внутренние стандарты на написание. Применительно к себе и Codesys я делаю так:

- Я пишу все блоки на ST, да же если его реализовать на LD или FBD проще.
- Структура программы рисуется на CFC.
- SFC не использую.

Схема себя 100% раз оправдала - блоки легко корректировать, если попадается въедливый заказчик, которому подавай ПО по ГОСТу - распечатывается красивая картинка на формате А2 и куча страниц IL инструкций каждого блока

[Lexman]

Не ожидал, что будет столь бурная реакция на топ
Ну, свои 5 копеек в обсуждение:

О полной замене ПЛК - миф чистой воды:
1. Ненадежно по сравнению с ПЛК
2. Никто в мире простые дискретные задачи не программирует на Cи. Только LAD, FBD, IL... Инженер-электроник не обязан знать Си и прочую требуху!

1. - Некорректное высказывание. Я уж молчу об объективных аргументах, которых у вас явно нет.
2. - А никто и не предлагает решать на них простые задачи. По поводу "требухи" - есть только две бесконечные вещи: вселенная и .... Так что не стоит делать такие категоричные заявления

Эти девайсы не очень надежны и обсуждать их нечего.Известны случаи когда они теряли память программ и перегружались самопроизвольно в моменты сдачи проектов заказчику.У кого нет денег на нормальное железо юзают их.По поводу программерства-каждый пишет софт на том что ему ближе.Посему наверное все высказанное применимо.

Эти девайсы не очень надежны и обсуждать их нечего.Известны случаи когда они теряли память программ и перегружались самопроизвольно в моменты сдачи проектов заказчику. - У меня такие же случаи известны и с ПЛК . И с ПК. И с телефонами. И... вопрос - насколько часто и в каких условиях. У меня были подобные проблемы, но только в моменты сильных помех (эл. дуга рядом), и при перегрузках от некорректных программ (один раз). Зы - если предложите более качественные аналоги по функциональности, буду премного благодарен.

Собственно, WinCon-то они сняли. Заменив WinPAC. И получили стандартную для тайваньцев проблему: WinPAC поддерживают высокопрофильные модули, а их номенклатура еще крайне мала по сравнению с "обычными". Таким образом, одно уже сняли, а второе "до ума" не довели.

А вот тут согласен. Хотя проблем с нехваткой модулей не было, а вот сырые ОС - это есть ( Ждёмс...

=============
Что хотелось бы сказать по поводу языков и прочего: все языки, утвержденные МЭК - это языки специфические, предназначенные непосредстевнно для систем автоматизации и выросшие из них. Но решать задачи с боле-мене сложной математекой и логикой на этих языках - это ад кромешный (имхо!). Потому предпочитаю всякую "трепуху" типа C# ). Мне иногда звонят торговые представители и говорят "зачем вам это всё, берите наши хорошие ПЛК!" - я спрашиваю что-то вроде:
- можно ли на их ПЛК писать программы, которые в последствии персоналом конфигурируются без использования ПК и спец. софта?
- могут ли их ПЛК сохранять что-нибудь на флэшку и есть ли у них USB-порт?
- могут ли они работать без специализированных HMI, со стандартными тач-скрин мониторами?
и т.д. - вопросы сразу исчезают. Я не говорю о элементарных задачах, решаемых, к примеру, на RLL, а о более комплексных - ну не все же здесь занимаются примитивным зажиганием лампочек от двух датчиков?
К примеру, сейчас пишу софт для управления котлами и прочими агрегатами связанными со сжиганием топлива. Причем, должна быть одна программа, которую по месту можно будет "подстроить" под конкретный объект, но без использования спец. средств - ноутбука или т.п. Это означает, что по ходу "подстройки" можно будет определить число горелок, способ подачи газа/воздуха, способ регулирования соотношения, разное количество защит и блокировок, разное количество регуляторов разного типа и т.д. И после этого программа должна сама определить что и как должно быть, и свою последовательность работы - без каких-то корректировок и подстроек. Вы предлагаете это сделать на LD? )
Я уж молчу о всяких приятных мелочах, вроде сохранения "журнала оператора" (с записью параметров, аварий, времени и т.п. собоытий) в виде файлов на флешку, которая воткнута в контроллер.
Для этого можно использовать SCADA навроде нам всем известной фирмы, но это уже само по себе повышает соимость в несколько раз!
.
Короче, я что хочу сказать: стрелять из пушке по воробьям - глупо, да. Хотя работает. А вот из рогатки по танкам - ещё глупее. Тем более что не работает. Всему свои цели средства, давайте не будем путать воробьёв с танками.

Сообщение отредактировал Lexman - 31.3.2009, 19:30

[ktulu]

"Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете,"
http://iprog.pp.ru/forum/list.php?f=2
...и на всяких асутпшных форумах есть отдельные темы для ICPDAS...
"пока не буду изливать суть, по скольку не ясно, пользует ли их кто нибудь"
...мое мнение такое, использовать ICPDAS желательно только когда ты ТОЧНО понимаешь что ТЫ делаешь, и что ДОЛЖНО получиться, это требует достаточно серьезного опыта в программно-аппаратной области, т.е. если что-то не работает по алгоритму нельзя исключать, что косяк может не в программе, а возможно и в железе, и в ОС, и в библиотеках, таких случаев за мой почти 4-х летний опыт работы с I-7XXX-I-8XXX сериями было достаточно, решается поиском на ftp://ftp.icpdas.com бэта-версий:)...
...что касается задачь для ICPDAS, их удобно использовать в проектах где намешано разношерстного оборудования со своими самопал-bus протоколами, типа "умные дома", "домашняя автоматизация", если надо "дешево и сердито", или для диспетчеризации распределенного простого оборудования типа прит-выт систем, но если ты УВЕРЕН в своих знаниях и опыте, то ICPDAS- это достаточно мощная платформа для решения нестандартных задач, где требуется уровень "твой код - операционка - железо" и никаких посредников ввиде IDE-среды ПЛК...
...вот недавно в проекте надо было объединить распределенку на I-7XXX по DCON с диспетчеризацией на ModBus TCP, у ICPCON такого firmware нет, был взят I-7188EX с бат. памятью, и разработан по сути прогр-аппартный комплекс по учету энергоносителей многоэтажного дома, плюс возможность сохранять в память локальную базу учета за день, за неделю, за месяц, реализовать такое же скажем на BECKHOFF уже сложнее, все же CodeSys не "язык ЦЕ":), правда пришлось поfuck что б разобраться с библиотекой для работы с TCP-IP через сокеты, и до сих пор вопросы остались...
...а вообще.. ICPDAS - это что-то типа фетиша от программирования:))...

[Lexman]

приятно встретить единомышленников
спасибо за ссылки, пошел смотреть.

Кстати, характерная примета: полно обсуждений по железу серии I-7xxx I-8xxx, но по более современным ОС-оборудованным контроллерам (...Con, ...PAC) - обсуждений мало

"ICPDAS - это что-то типа фетиша от программирования:))..."
ну не сказал бы. Это скорее штука, которая позволяет "нормальным" программистам развязать руки

ЗЫ, а в железе я разбираюсь, слава Богу, разработчиком был, пусть недолго. Любителям RLL нас не понять )

Сообщение отредактировал Lexman - 31.3.2009, 21:36

[Сергей Долганов]

Что хотелось бы сказать по поводу языков и прочего: все языки, утвержденные МЭК - это языки специфические, предназначенные непосредстевнно для систем автоматизации и выросшие из них. Но решать задачи с боле-мене сложной математекой и логикой на этих языках - это ад кромешный (имхо!). Потому предпочитаю всякую "трепуху" типа C# ). Мне иногда звонят торговые представители и говорят "зачем вам это всё, берите наши хорошие ПЛК!" - я спрашиваю что-то вроде:
- можно ли на их ПЛК писать программы, которые в последствии персоналом конфигурируются без использования ПК и спец. софта?
- могут ли их ПЛК сохранять что-нибудь на флэшку и есть ли у них USB-порт?
- могут ли они работать без специализированных HMI, со стандартными тач-скрин мониторами?
и т.д. - вопросы сразу исчезают. Я не говорю о элементарных задачах, решаемых, к примеру, на RLL, а о более комплексных - ну не все же здесь занимаются примитивным зажиганием лампочек от двух датчиков?

И они Вам отвечают:
1. Нет, а зачем?
2. Некоторые могут, а зачем?
3. Нет, а зачем?
Прелесть МЭК языков как раз и заключается в отсутствии необходимости использовать пару программист-постановщик задачи.

К примеру, сейчас пишу софт для управления котлами и прочими агрегатами связанными со сжиганием топлива. Причем, должна быть одна программа, которую по месту можно будет "подстроить" под конкретный объект, но без использования спец. средств - ноутбука или т.п. Это означает, что по ходу "подстройки" можно будет определить число горелок, способ подачи газа/воздуха, способ регулирования соотношения, разное количество защит и блокировок, разное количество регуляторов разного типа и т.д. И после этого программа должна сама определить что и как должно быть, и свою последовательность работы - без каких-то корректировок и подстроек. Вы предлагаете это сделать на LD? )

Если у Вас и ноутбук спец. средство, то даже не знаю что сказать. А по части того что "программа определит сама"- если честно я бы Вас за такое уволил:) Вместо решения вполне понятной и простой задачи Вы развернули чуть ли не ИИ.

Я уж молчу о всяких приятных мелочах, вроде сохранения "журнала оператора" (с записью параметров, аварий, времени и т.п. собоытий) в виде файлов на флешку, которая воткнута в контроллер.
Для этого можно использовать SCADA навроде нам всем известной фирмы, но это уже само по себе повышает соимость в несколько раз!
.

И в десятки раз понижает зависимость от программиста -наколенника.

[Гость_Old_*]

Не ожидал, что будет столь бурная реакция на топ
Ну, свои 5 копеек в обсуждение:
1. - Некорректное высказывание. Я уж молчу об объективных аргументах, которых у вас явно нет.
2. - А никто и не предлагает решать на них простые задачи. По поводу "требухи" - есть только две бесконечные вещи: вселенная и .... Так что не стоит делать такие категоричные заявления
Эти девайсы не очень надежны и обсуждать их нечего.Известны случаи когда они теряли память программ и перегружались самопроизвольно в моменты сдачи проектов заказчику. - У меня такие же случаи известны и с ПЛК . И с ПК. И с телефонами. И... вопрос - насколько часто и в каких условиях. У меня были подобные проблемы, но только в моменты сильных помех (эл. дуга рядом), и при перегрузках от некорректных программ (один раз). Зы - если предложите более качественные аналоги по функциональности, буду премного благодарен.


А вот тут согласен. Хотя проблем с нехваткой модулей не было, а вот сырые ОС - это есть ( Ждёмс...

=============
Что хотелось бы сказать по поводу языков и прочего: все языки, утвержденные МЭК - это языки специфические, предназначенные непосредстевнно для систем автоматизации и выросшие из них. Но решать задачи с боле-мене сложной математекой и логикой на этих языках - это ад кромешный (имхо!). Потому предпочитаю всякую "трепуху" типа C# ). Мне иногда звонят торговые представители и говорят "зачем вам это всё, берите наши хорошие ПЛК!" - я спрашиваю что-то вроде:
- можно ли на их ПЛК писать программы, которые в последствии персоналом конфигурируются без использования ПК и спец. софта?
- могут ли их ПЛК сохранять что-нибудь на флэшку и есть ли у них USB-порт?
- могут ли они работать без специализированных HMI, со стандартными тач-скрин мониторами?
и т.д. - вопросы сразу исчезают. Я не говорю о элементарных задачах, решаемых, к примеру, на RLL, а о более комплексных - ну не все же здесь занимаются примитивным зажиганием лампочек от двух датчиков?
К примеру, сейчас пишу софт для управления котлами и прочими агрегатами связанными со сжиганием топлива. Причем, должна быть одна программа, которую по месту можно будет "подстроить" под конкретный объект, но без использования спец. средств - ноутбука или т.п. Это означает, что по ходу "подстройки" можно будет определить число горелок, способ подачи газа/воздуха, способ регулирования соотношения, разное количество защит и блокировок, разное количество регуляторов разного типа и т.д. И после этого программа должна сама определить что и как должно быть, и свою последовательность работы - без каких-то корректировок и подстроек. Вы предлагаете это сделать на LD? )
Я уж молчу о всяких приятных мелочах, вроде сохранения "журнала оператора" (с записью параметров, аварий, времени и т.п. собоытий) в виде файлов на флешку, которая воткнута в контроллер.
Для этого можно использовать SCADA навроде нам всем известной фирмы, но это уже само по себе повышает соимость в несколько раз!
.
Короче, я что хочу сказать: стрелять из пушке по воробьям - глупо, да. Хотя работает. А вот из рогатки по танкам - ещё глупее. Тем более что не работает. Всему свои цели средства, давайте не будем путать воробьёв с танками.

Эти девайсы не очень надежны и обсуждать их нечего.Известны случаи когда они теряли память программ и перегружались самопроизвольно в моменты сдачи проектов заказчику. - У меня такие же случаи известны и с ПЛК smile.gif. И с ПК. И с телефонами. И... вопрос - насколько часто и в каких условиях. У меня были подобные проблемы, но только в моменты сильных помех (эл. дуга рядом), и при перегрузках от некорректных программ (один раз). Зы - если предложите более качественные аналоги по функциональности, буду премного благодарен.
Уважаемый берите железо мировых производителей и будет вам щастье. Если не сочьтете за труд и почитаете форумы асутэпэшные узнаете про то о чем я выше говорил.Некая известная контора делала для Башнефти системы на ICPDAS поплевалась и заменила производителя контроллерного оборудования.Весь вопрос в стоимости железок и платежоспособности клиента.Все остальное лирика и рассуждать можно много.Тем паче что указанный вами производитель не отличается ни хорошим софтом ни инновациями.Тока дешев больно.

[Sniper007]

Что хотелось бы сказать по поводу языков и прочего: все языки, утвержденные МЭК - это языки специфические, предназначенные непосредстевнно для систем автоматизации и выросшие из них. Но решать задачи с боле-мене сложной математекой и логикой на этих языках - это ад кромешный (имхо!). Потому предпочитаю всякую "трепуху" типа C#

Я тоже люблю C#. Но на языке ST не возникнет проблем с математикой. Фактически язык ST это смесь Паскаля, С и Бейсика. ПОэтому ваше выражение некооректно.

Это скорее штука, которая позволяет "нормальным" программистам развязать руки

А тех кто пишет на МЭК, какие программисты? Сумасшедшие?

И они Вам отвечают:
1. Нет, а зачем?
2. Некоторые могут, а зачем?
3. Нет, а зачем?

Если мне так ответили, я положил бы трубку. Раз говорю "мне надо", значит "мне надо".

Прелесть МЭК языков как раз и заключается в отсутствии необходимости использовать пару программист-постановщик задачи.

И в десятки раз понижает зависимость от программиста -наколенника.

Сергей, я не думаю, что для программирования ICP требуется программист очень высокой квалификации.

[Lex]

...я не думаю, что для программирования ICP требуется программист очень высокой квалификации...

дело в том, что для программирования на FBD программист вообще не требуется -
все делает сам инженер.

Вообще, спор на эту тему уже был на форуме....
Условно названные ИНЖЕНЕР и ПРОГРАММИСТ подходят с разных сторон к одной и той же задаче.
Базы у них разные, поэтому и обоснования исключительно своей правильности разные...
Поэтому и не понимают друг друга....

Сообщение отредактировал Lex - 1.4.2009, 7:51

[Сергей Долганов]

Если мне так ответили, я положил бы трубку. Раз говорю "мне надо", значит "мне надо".

Я был бы рад что Вы положили трубку По крайней мере мне не пришлось бы краснеть перед другими заказчиками которые увидели бы Ваше "мне надо" с использованием моего оборудования.

дело в том, что для программирования на FBD программист вообще не требуется -
все делает сам инженер.

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

[Andy79]

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

Я и мои коллеги такие программы и пишем, причем на LD, иногда с добавлением ST. Причем, обычно в очень сжатые сроки.

- могут ли их ПЛК сохранять что-нибудь на флэшку и есть ли у них USB-порт?

В зависимости от модели, но у многих ПЛК это уже есть.

- могут ли они работать без специализированных HMI, со стандартными тач-скрин мониторами?

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

Я уж молчу о всяких приятных мелочах, вроде сохранения "журнала оператора" (с записью параметров, аварий, времени и т.п. собоытий) в виде файлов на флешку, которая воткнута в контроллер.

Вот это я как раз обычно запихиваю в программируемый терминал, там это готовое решение. Но писали отчеты и для ПЛК.

[Sniper007]

Я был бы рад что Вы положили трубку По крайней мере мне не пришлось бы краснеть перед другими заказчиками которые увидели бы Ваше "мне надо" с использованием моего оборудования.

Не понял что вы хотите сказать

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

Технолог - должен знать технологию, программист - программирование, автоматчик должен знать ВСЁ.

[Lexman]

Меня удивляет принципиальное нежелание многих специалистов расширять свой кругозор 8(, так что Sniper007 - +1000.
Почему-то у людей есть уверенность, что если они могут решить задачу одним путём, то другие пути - хуже, причём, без аргументов

Если можно, то моя "формула" хорошего специалиста - это человек, который знает функционирование системы комплексно, в нюансах. И способен видеть и исключать недостатки, и улучшать эффективность системы вцелом. А то вспомнинается присказка "к пуговицам притензий нет?" Приенительно к АСУ-шникам, для построения достаточно мощной системы считаю важным знания: технологии, принципов автоматизации (ТАУ и современных технологий построения САУ), электроснабжения, электроники, программирования (и "базового" и "специфического"!!). По всем пунктам - знания должны быть в нюансах, как практические, так и теоретические. И это только основное. В каждой отрасли добавляется ещё много специфики.

[Lexman]

А по части того что "программа определит сама"- если честно я бы Вас за такое уволил:) Вместо решения вполне понятной и простой задачи Вы развернули чуть ли не ИИ.

Я сам кого хошь уволю . Что касается "ИИ" - что-то уж больно многие занимаются у нас подобным, и успешно продают свою продукцию. Так что не вижу особых проблем.

Я тоже люблю C#. Но на языке ST не возникнет проблем с математикой. Фактически язык ST это смесь Паскаля, С и Бейсика. ПОэтому ваше выражение некооректно.
А тех кто пишет на МЭК, какие программисты? Сумасшедшие?

Напрашивается вопрос: а почему бы не сделать один язык, зачем плодить клонов? Ответ очевидный - функциональное различие, и различие в применении. Причём сомневаюсь, что ST может то же, что и C# - ST "затачивался" под удобство написания софта под промконтроллер, не даром же классические языки взяты только как отправная точка. Это не может не понести сокращения гибкости: "во благо", и "для удобства", и "чтобы не заморачиваться", конечно же. И в 95% случаев это оправдано. Но я, видимо из этих 95 выбиваюсь . Хотя не жалею. Во всяком случае, я уверен, что на C# могу сделать что угодно и какой угодно сложности.

[Sniper007]

Язык ST конечно уступает языку C#.
Но однако C# уступает по гибкости С++. По сути C# это что-то между простым Бейсиком и мощным и гибким С++. Вас же это не смущает?
ST действительно создан для промконтроллеров, и со всеми отсюда вытекающими.
Чем он проигрывает C#?
C# - объектно-ориентированный язык. ST - ммм.. ну пожалуй объектно-основанный.
Взять скажем Codesys 2.3. Что реализовано в ST из объектных принципов? Только инкапсуляция. Наследования вообщем нет... Полиморфизма соответственно тоже.
НО! Есть одно НО. Сейчас вышел Codesys 3. Где ООП реализован. Я правда пока не очень разбирался, как там все это выглядит.
Игорь Петров из "Пролог" дал ссылку на вот такую книгу:
http://www.amazon.de/Wiederverwendung-Modu...s/dp/3835631055
Она на немецком правда.

"Напрашивается вопрос: а почему бы не сделать один язык, зачем плодить клонов?"
Вы ищите не там где потеряли, а там где светлее.
Ну почему бы вам не спросить у Майкрософт и у Андерса Хейлсберга в частности, чем его не устараивал С++ и они решили создать C#?


Кстати. Я сейчас пытаюсь представить как можно реализовать полиморфизм на графических языках (LD, FBD), и честно говоря не представляю... На ST же это вполне возможно, вот вам и ответ чем ST лучше...

Сообщение отредактировал Sniper007 - 1.4.2009, 14:56

[Lexman]

Кстати, по поводу гибкости С++ по сравнению с C# многие могут поспорить (я не являюсь программистом по професии, потому не имею постоянного плотного контакта с программированием), сам не буду. Хотя на мой взгляд, С++ больше подходит для относительно низкоуровневого программирования, где есть прямая работа с памятью (ну или виртуальной памятью), процессором, гибкой адресацией, короче - чем-то близким к железу. А наличие мощной ОС само по себе позволяет "не задумываться" над этим, потому С# с NET-технологией и появились. В этом смысле, на мой взгляд, этот язык и технология идут параллельно с ST и иже с ними.

Наткнулся на довольно интересную статью, правда, 2004-го года (http://www.softcraft.ru/paradigm/plcprog/plcprog.pdf). Очень неплохо сформулировано то, о чём мы говорим. В частности - одна из главнейших проблем - стандарт-то есть, но он определяет не более чем общий вид языков, без семантики и т.п. нюансов. При этом переносимости программ с платформы на платформу нет; узаконенной унифицированности языков нет (по прежнему!) и т.д. - короче, даже еслие в Codesys и пытаются как-то расширять ST, это, по сути остаётся "самодеятельностью", увы. Если попытаться поискать стандарт (ANSI, ISO, и т.д.) на любой из языков - их нет, по вплоне экономическим причинам. Недостатки С++ в нашем деле тоже хорошо описаны. правда в тот момент ещё только начинался C#, да и контроллеры с мощными ОС на борту тоже не были так распространены, и в статье о них ничего нет.

Впрочем, мы уже вторую страницу сильно оофтопим.

[Гость_ewsey_*]

Не могу не высказаться по этой теме. Во-первых большой респект Сергею Долганову и его единомышленникам. Мы далеко не одиноки в своем мнении, большинство инженеров автоматчиков, именно инженеров, а не программистов метнувшихся в автоматизацию, считают что контроллеры программирующиеся на высокоуровневых языках типа ICP DAS, это конструктор для программиста-энтузиаста-наколенника. Большинство заказчиков на сегодняшний день прописывают в требованиях, что ПРОГРАММА ДОЛЖНА БЫТЬ НАПИСАНА НА ИНЖЕНЕРНЫХ ЯЗЫКАХ И ПОНЯТНА ОБСЛУЖИВАЮЩЕМУ ПЕРСОНАЛУ. Более того, МЭК языки создавались опираясь на основной принцип МЭК-програмирования - задача должна быть решена максимально просто и доступно на сколько это возможно. Так вот это ПРОСТО реализуется в большинстве случаев на языке LD.
90% задач автоматизации практически любого уровня можно реализовать на LD. И это в дальнейшем значительно упростит жизнь обслуживающему персоналу. Если же возникают задачи написания самопальных драйверов и таких же самопальных HMI (которые потом никто не сможет ни переделать ни перенастроить, потому что программист который это сделал - уволился, а контора закрылась. Это из опыта.) вот это уже задача действительно для программиста, которому даже не нужно обладать знаниями инженера, поскольку этот самый инженер просто объяснит ему задачу.

В интернете на самом деле полно обсуждений этого железа и проблем у народа масса, просто танцы с бубном а работают с этим барахлом скорее от безысходности, когда нужно свести бюджет проекта к абсолютному нулю.

[Sniper007]

Хочу сразу оговорится, я не сторонник ICP.

Я сторонник того, что иженер, должен быть разносторонним человеком.
Я вообщем не против языка LD. Если вы пишете программу для Zelio или для ранних Омронов, то у вас просто НЕТ альтернатив.

90% задач автоматизации практически любого уровня можно реализовать на LD.

Вопрос не в том что можно, а что нельзя (Уголовный кодекс России не запрещает использовать язык LD, значит на нем писать можно).
Вопрос в том, на чем удобнее и быстрее написать. Подчеркну - вопрос не в том в чем вы привыкли, а именно в чем быстрее.
Ответьте мне ewsey, как можно реализовать принципы ООП на языке LD?

И это в дальнейшем значительно упростит жизнь обслуживающему персоналу

Кто именно подразумевается под обслуживающим персоналом? Оператор? Электрик? Кто из них полезет ковырятся в программу?
Или может вы имеете ввиду под "обсуживающим персоналом" инженера?
Если инженер толковый, он разберется и в ST, и в LD. Если он бестолочь, он не разберется ни в одном, ни в другом.
Кроме того хорошим стилем программирования является комментирования хода программы. Ну так прописывайте на каждом ходу, что именно вы делаете. И тот кто потом будет смотреть вашу программу быстро разберется (да и сами быстрее вспомните, если ее придется модернизировать).
Мне кажется под словами "LD лучший язык всех времен и народов" кроется банальное нежелание учится и совершенствоваться... Обидно...

Кстати. Сами посудите, язык LD появился самым первым, когда еще было царство релюшек. Ну если бы он был так хорош всех устраивал, появились бы после этого языки ST, FBD, SFC?

Сообщение отредактировал Sniper007 - 3.4.2009, 10:22

[Andy79]

Меня удивляет принципиальное нежелание многих специалистов расширять свой кругозор

В какую сторону расширять? В сторону паяния контроллера самому? Или в сторону новых особенностей технологических процессов? Понимания работы новых машин? Совершенствования эргономики (о которой по моему процентов 60 автоматчиков даже и не слышало) создаваемых систем?

Ответьте мне ewsey, как можно реализовать принципы ООП на языке LD?

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

[Гость_ggg__ggg_*]

Интересный спор
Особенно улыбнуло про объектно-ориентированные языки программирования. Как ПРОФЕССИОНАЛЬНЫЙ программист ОТВЕТСТВЕННО заявляю : на данный момент их в природе НЕТ Чтобы объяснить свое заявление, придется устраивать экскурс в историю, а это слишком....
Приятно читать сравнения очередной "телеги, запущенной вперед лошади" (С#) и "седлом для коровы" (С++).
Что касается ВЫБОРА языка, то он ПОЛНОСТЬЮ определяется Заказчиком, а если ему "по-барабану" (99.9% случаев), то - Исполнителем.
Как правило, Зака интересует работа КОНЕЧНОГО продукта, а не его "потроха". И это ПРАВИЛЬНО, т.к. он - КОНЕЧНЫЙ ПОТРЕБИТЕЛЬ ПРОДУКТА, а не ОЕМщик. Мне, например, глубоко "фиолетово", на чем написан компиллятор или среда программирования - я ее даже переделывать не могу (согласно Лицензионного соглашения), да на фиг не надо, если решает задачи.
Что касается ICPDAS, то часто использовали их преобразователи интерфесов. Да, есть проблемы с софтом (кривоват малость), но скорость появления бета-версий устраивает. Вообщем, "дешево и сердито, иногда - слишком сердито".