Вэлкам то все, кто сталкивался с этими девайсами. Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете, хотя Адастра и "яписитую" активно их рекламируют. Перешли на эту серию (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... Инженер-электроник не обязан знать Си и прочую требуху!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

"Почему-то практически полное отсутствие обсуждений этих контроллеров в рунете,"
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 - это что-то типа фетиша от программирования:))...

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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


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

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


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


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

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

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


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

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

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

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


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

Язык 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 лучше...

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

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

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

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

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

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

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


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

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

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

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


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

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

Ну паять контроллер никто здесь не кому не предлагал.
В какую сторону расширять? Я думаю во все. "Одно другому не мешает".

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


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

Ну тогда объясните мне. Чем плохо использовать ООП при больших проектах, с большим количеством однотипного оборудования (насосы, копрессоры, клапаны)?

to Snipper007
Думаю, это Вы не очень понимаете, что такое ООП . Идеология эта возникла много лет назад, когда казалось, что еще чуть-чуть - и будет написан компиллятор, позволяющий ФОРМАЛЬНО распараллеливать задачи. Именно тогда и появилось понятие "объект" - базовый элемент РАСПРЕДЕЛЕННОЙ обработки данных. НУ НЕТУ СЕГОДНЯ (по-крайней мере- в открытом доступе) ТАКИХ СИСТЕМ, и будут они не скоро (по разным причинам). Многоядерные поделки от Intel и АМD не в счет - это ДЕТСКИЙ ЛЕПЕТ по отношению к распределенным системам.
Когда появятся такие системы в варианте контроллеров - НЕИЗВЕСТНО, а, ГЛАВНОЕ - так ли они нужны?
Вот так вот, приблизительно....

Либо что такое ООП каждый понимает по своему, либо мы говорим о разных вещах.

Да нет, говорим мы об одном и том же . Просто Вы принимаете это "как данность", благо книжек с середины 80-х наклепали массу, "запудрив мозги" народу. Уже мало кто и помнит, откуда "ноги растут". Я же просто знаю, откуда все начиналось, т.к. небольшая компьютерная фирма IBM
собирала программистов из "капиталистического и социалистического лагерей" для решения задач по многопроцессорным системам. Я был в числе приглашенных от "социалистического лагеря". Именно после провала этой затеи (очень анекдотичная, но крайне поучительная история) было и принято решение сосредоточить усилия на "разгоне" тактовых частот процессора. Длилось этот "разгон" 20 лет, но теперь достигнут физический предел. Ну и начался "развод" с многоядерными процессорами. А как еще заставить нас что-то покупать...
Совсем оффтоп....

Да нет, наверно все таки о разных...
Я всегда считал что ООП направлено не на убыстрее программ, исполнение кода, а на облегчение труда программиста. На то чтобы сократить дублирование кода, скрыть часть кода от "чужих глаз". Но тогда я не вижу связи между ООП и частотами процессора.
ggg__ggg может через личку поговорим?

Связь проста: два пути развития рынка PC. Первый путь : многопроцессорные системы и, как перспектива, создание глобальных вычислительных сетей. В этом случае особую актуальность приобретают языки (и компилляторы с них), которые позволяли бы программисту не думать о распределении ресурсов для решения задачи. Как пример - подумайте, как можно ФОРМАЛЬНО решить задачу инициализации массива из 1000 элементов, если у вас в распоряжении есть от 2 до 100 процессоров. и во сколько раз это будет быстрее, чем на одном процессоре. Так появились ОБЪЕКТЫ, и их атрибуты (методы и свойства).
Второй путь : "разгон" тактовой частоты ОДНОГО процессора, благо в середине 80-х появилась физическая и химическая возможность для этого. Правда, тут было очевидное ограничение : те же физические и химические законы. Т.е. предел был ясно виден, но "за имением гербовой пишем на простой". Маркетинговых ход себя оправдал, и покупатели охотно покупали процы с "более высокой тактовой частотой", наивно думая, что это АВТОМАТИЧЕСКИ ведет к повышению производительности на указанное число процентов. Родисля целый класс - оверклокеры, для них - свои производители. Вообщем, все "кайфовали", пока не достигли границю Вот теперь ударились в "многоядерные" системы.
Это вкратце....

Все что вы рассказываете ggg__ggg, это очень, очень интересно (правда!). Еще интереснее мне было бы послушать вашу историю про работу на компанию IBM.

Но ответьте мне, ООП позволяет ускорить написание программы?
Т.е. мы создали базовый класс, скрыли часть его кода используя инкапсуляцию, потом занаследовали от него другой класс (тем самым избежав рутины переписывания повторяющегося кода), потом перекрыли часть методов используя полиморфизм. Это разве не ускоряет разработку программы? Не сокращает количество ошибок, не позволяет их быстрее выявлять и устранять?

Честно говоря, тоже не улваливаю связи между частотой, поточностью и ООП Вполне возможно, что когда-то это возникло исходя из совсем иного, нежели сейчас, и цели были другие. Но сейчас ООП - это метод логической структуризации программного кода, и программной системы (пардон за кривое определение) вцелом.
Вы же не рассматриваете человека как набор атомов, а как сущность со своими свойствами, далёкими от валентностей, ядерных масс и расположения в таблице Менделеева? ) Так вот - я вижу суть ООП именно в этом (далеко не только в этом, разумеется!!!).
А историю про IBM тоже с удовольствием прочёл бы ))

Сейчас ООП - это просто ООП. Можно привести и более простой пример. Бутерброд - это ХЛЕБ и МАСЛО, есть еще СЕНДВИЧИ, но в общеупотребительном смысле - бутерброд этохлеб с чем-то, например, бутерброд с салом, колбасой, сыром, где маслом и не пахнет. Так и ООП.
Термин прижился, понравился, под это дело "подогнали" теорию, написали книги. Пример из нашего - "нанотехнологии".
Что касается "структурирования" программ и логики их построения, то тут можно забраться в такие дебри, что и не выберешься .
Мы с моими старыми друзьями под эти споры немало выпили, но зато пришли к простому выводу: без разницы, как написано, лишь бы работало .
Вообще-то ФОРМАЛИЗАЦИЯ структурирования ПО (что ОСОБЕННО важно при тестировании) - это очень СЛОЖНАЯ задача, над решением которой долгие годы бьются лучшие умы . И это совершенно без иронии....

Ну вот кажется более менее начинает прояснятся... А то я правда уже начал думать, что я не понимаю что такое ООП
Сразу скажу, меня ООП интересует только с точки зрения упрощения создания кода.
"Мы с моими старыми друзьями под эти споры немало выпили, но зато пришли к простому выводу: без разницы, как написано, лишь бы работало"
Я с вами, qqq_qqq абсолютно согласен. НО! Давайте расссмотрим такой пример (навскидку, без претензий на реальность) и сделаем вывод нужно ли ООП в промышленных контроллерах.
Мы имеем цех в котором установлено 50 насосов. Они используются в цехе нескольких типов - погружные, поршневые, центробежные. Каждый из типов насос имеет свои особенности работы и, соответственно, программную реализацию.
Допустим, мы не знаем ни одной концепции ООП (даже инкапсуляции). Как будем решать задачу? Нам придется описать каждый из насосов, не один десяток раз повторить код. Будет это работать? Безусловно! Будет и соверешенно спокойно.
Но допустим придет к вам технолог, и скажет: "знаешь, я хочу чтобы у меня поршневые насосы работали не так, а вот так". Придется проделать большой объем работы, исправить много кода, и наверняка допустить много ошибок...
Теперь допустим мы использовали бы ООП. Как можно сделать. Создаем базовый класс - nasos. Прописываем в нем методы и свойства присущие всем насосам. Далее наследуем от этого класса и получаем классы - centr_nasos, porsh_nasos, pogr_nasos. В каждом из классов прописываем те методы и свойства присущие именно этому классу насосов.
После этого создаем экземпляры классов и работаем.
Теперь если придет технолог, и попросит изменить свойства центробежных насосов, это займет на порядок меньше времени.
Кроме того, большинство программистов работают в одной отрасли, и редко ее меняют на другую. Поэтому создав один раз класс насосов для одного цеха, то можно впоследствии (пусть даже с небольшими переделками) использовать его для другого цеха. Т.е. экономится время (которое как известно деньги).

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

P.S. При создании сегнетика использовался компилятор под Atmel - IAR Embedden. Так в нем реализованы основные функции ООП - классы, наследование, полиморфизм. Т.е. даже в микроконтроллерах используют ООП.
Ну а мы чем хуже? Что в автоматике менее масштабные проекты?

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

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

Ну не надо так, пожалуйста. Макрос как понятие не имеет отношения к ООП никакого, это ПОВТОРЯЕМЫЙ ВТУПУЮ кусок кода, это определение. Какое наследование, какой полиморфизм? Сделайте на LD функциональный блок "поршневой насос" и изменяйте только его, когда понадобится Вашему технологу. ООП тут ни при чем, это просто натыкивание одинаковых кусочков кода. По-вашему ООП можно реализовать на ассемблере, просто в текстовом редакторе скопировав кусок листинга и запомнив в голове, какие регистры выходные, а потом приделав туда еще пару операций. Да, по секрету, в Сегнетиксе так и случается, никакого Вам ООП

Ну, давайте поговорим об этом.. ООП (Очень Ограниченном Программировании , есть и другие варианты ...).
1) Методика программирования "сверху вниз" и "снизу вверх" - думаю, термины известные.
2) Допустим, Вы создаете класс "насос". Свойства и методы придумываете сразу или как? (см. п 1). Далле, вы должны понимать "степень и глубину"
отличия потомков от предков хотя бы во втором поколении, а то начнете с насоса, а закончите автомобилем, у которого есть насос. Как говорилось в одной юмореске, "все началось со шпинделя". Таки образом, вы должны СПРОЕКТИРОВАТЬ класс, максимально ухватив его суть (так обычно пишут в умных книгах). Постарике, это выглядело бы так. Написать библиотеку примитивов и из нее "шлепать" программы. Либо написать программу с "заглушками" и под них "нашлепать" библиотеку примитивов. Далее, если потребуется что-то изменить вы просто пишите новую функцию с таким же именем, а linker автоматически подставит ее, а не библиотечную при сборке кода. Ьак делалось ЗАДОЛГО до появления ООП
3) Макросы, библиотеки появились много раньше термина ООП.
4) Главное - осталась НЕРЕШЕННОЙ одна ма-ааленькая проблема - как построить (спроектировать) класс так, чтобы изменения в методах и свойствах не привели к разрушению самого класса или, что хуже, к непредвиденным последствиям. Задача проектирования класса, как и много лет назад, чисто ЭВРИСТИЧЕСКАЯ, и нчем не отличается от "допотопных" методов. Да, существуют специальные методики и программы для проверки формальной логики, но они ОЧЕНЬ ДОРОГИЕ. Под ООП они, как правило, не заточены совсем . Впрочем, это отдельная тема.
Так что выгоды ООП что-то совсем не видать...
4) Теперь немного о самой идеологии ООП. Изначально полиморфность и наследование (в привычном смысле) и не подразумевалась. Основное предназначение объекта - "рождаться", выполнять свои функции, отдавать себя ЦЕЛИКОМ другим объектам (как атомы в молекулу) и "умирать".
Сильно смахивает на человечество... Ни о какой АДРЕСНОЙ арифметике, замене свойств и речи не было - просто не зачем это.

Хорошо.
Давайте сперва о классах. Вы сейчас выделили пробемы с которыми сталкивается програмист решивший реализовать приниципы ООП. Где то слышал выражение ООП - это не стиль программирования, это стиль мышления. Способность видеть объектность должна прийти с опытом.
Кроме того, проектируя класс, ведь по сути ничто не мешает дорабатывать предыдущие уровни. Ведь есть же полиморфизм, который позволяет перекрыть метод базового класса новым.

Про макросы и библиотеки. Да, конечно они появились раньше. Но вот сами посудите. Что есть макрос (или функциональный блок)? Это некий программный объект реализующий некую функцию. Возможно даже не вы его написали, но вам сказали - "Вот тебе макрос (ФБ), сюда дай ему переменную времени сколько нужно качать, сюда дай какое давление держать и т.д." Ну это же не что иное как инкапсуляция!

"Главное - осталась НЕРЕШЕННОЙ одна ма-ааленькая проблема - как построить (спроектировать) класс так, чтобы изменения в методах и свойствах не привели к разрушению самого класса или, что хуже, к непредвиденным последствиям."

Допустим у вас класс погужного насоса, который занаследован от класса nasos (от него же занаследован центробежный и поршневой насос), если вы повредите методы этога класса. То базовому классу ничего не будет, и тем классам которые незанаследованы от класса porsh_nasos, тоже ничего не будет.

Вообще все что вы говорите - верно. Действительно нужно знать ряд правил, чтобы писать качественные программы с использованием ООП.
Но это разве плохо? Ведь то что на дорогах есть правила движения (пусть даже иногда нарушаемые) никого не смущает?

Эк далеко ушли от исходной темы. Вставлю и свои пять копеек.
Про ООП - ясен пень штука необходимая, особенно в масштабных проектах, если работает команда а не шахид-одиночка. Вот только часто ООП, полиморфизм и т.д. используются для шаманского камлания, чтоб иметь надлежащий вид.
Про языки программирования - а это смотря для чего:
а - скажем тестоделительная машина на хлебозаводе - S7-300 по одному модулю входов и выходов, панелька OP7 или 17, пара частотников болтаются на профибасе - серийное изделие, выполняет практически одну и ту-же операцию от рождения до смерти. Все возможные баги можно отловить еще на первом образце и персоналу нефиг в контроллер лазить. Программировать можно на чем хош - хоть в машкодах, если кто помнит.
б - например комбикормовый завод на птицефабрике - пара Vipa Speed7, куча периферии на профибасе и ASI, MPI и Ethernet тоже не гуляют - сколько-бы подобных заводов во всём мире именитый брэнд не построил, каждый такой объект индивидуальный - читай - пожизненная отладка. Ну не так чтоб ежедневно, основное вылизано - но иногда где-то, че-то подправить надо. И че - будут держать ради этого супер-пупер программиста с полиморфизмом и наследованием? ".. только балет и керамика.." - т.е. LAD и тп, что-бы можно было за небольшую мзду пригласить стороннего дядю для небольших правок, причем даже отсутствие исходников не является непреодолимым препятствием. А вот если проект на сях-дельфях и иже с ними - мздеть придется намного больше.

Так что каждому инструменту своё применение, а мастера видно по инструменту.

Господа офицеры, да что за ахинею вы несете???
Нет, я конечно все понимаю - некоторые из вас учились еще в СССР когда Си был еще без плюсов, а компьютеры на лампах. Но посмотрите что происходит сейчас - программированию учат уже в школе (как правило Бейсик или Паскаль). LAD не так актуален как 10 лет назад.
И почему мздеть придется больше? Ну сами посудите - написанный на ООП код (если он конечно хорошо написан) компактер и гибок. Исправление каких нибудь недочетов не займет времени больше, чем поиск в среди кучи нормально-открытых, нормально-закрытых контактов.
Да и почему вы решили что познать принципы ООП - это "супер-пупер"? Мне кажется единственное, что сейчас сдерживает полное (подчеркиваю - полное, потому частично используют ООП все - в виде функциональных блоков) применение принципов ООП для ПЛК, это то что системы программирования для ПЛК не поддерживают полностью ООП (кроме Codesys 3).
Мне кажется здесь идет спор не о том, что лучше, а к чему больше привыкли.

Так и я о том-же.

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

СТОП. Ну кто видел электрика ковыряющего в LAD? Да никакой электрик в жизни не полезет дальше 3 фаз, ну в лучшем случае - датчик поменяет.
Далее. Ну какая разница что менять? Изменит он неправильно LAD, или изменит неправильно ST или C#, в любом случае можно будет доказать виновность или невиновность. Ну возьмите старый проект, сравните с новым - вот и результат.
Я не понимаю, почему вы думаете что программа на C# будет сложнее чем на LAD? Я уже говорил - надо хорошо документировать программу, ставить комментарии, тогда разберется даже 10 классник только что вернувшийся с урока информатики.

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

Я видел. И даже добился, в свое время, чтобы завод оплатил учебу пары дежурных электриков S7-PRO1.
И по поводу умных десятиклассников - хорошая шутка, я посмеялся. Чейто в жизни таких не встречал на производстве.



Именно - добавить нечего.