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

[Sniper007]

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

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

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

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

Потребность в ООП, судя по моему опыту, так же всплывает либо при неправельном выборе оборудования, либо при элементарном краилове.

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

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

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

[Sniper007]

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

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

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

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

Потребность в ООП, судя по моему опыту, так же всплывает либо при неправельном выборе оборудования, либо при элементарном краилове.

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

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

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

[Гость_ggg__ggg_*]

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

[Sniper007]

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

[Гость_ggg__ggg_*]

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

[Sniper007]

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

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

[Гость_ggg__ggg_*]

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

[Sniper007]

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

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

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

[Lexman]

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

[Гость_ggg__ggg_*]

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

[Sniper007]

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

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

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

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

[Lexman]

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

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

[ManMadeGod]

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

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

[Гость_ggg__ggg_*]

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

[Sniper007]

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

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

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

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

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

[Olex007]

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

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

[Sniper007]

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

Сообщение отредактировал Sniper007 - 14.4.2009, 7:20

[Olex007]

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

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

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

[Sniper007]

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

[Гость_ggg__ggg_*]

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

[Olex007]

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

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

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

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

[Sniper007]

Про 10 классника, я сказал для сравнения.
Я вот лично тоже не встречал электриков подключающихся к сименсу. И думаю не встречу. Я считаю так "кесарю - кесарево". Многому научились ваши электрики при обучении сименсу?

Кроме того. Я думаю тут даже никто и спорить не будет - выполнять арифметические расчеты и работу со времем на ST гораздо удобнее. А про строки, вообще молчу. Просто вопрос отсюда - "нафига козе баян?" Если есть язык с которым можно без проблем написать и дискретную логику, и со временем работать, и со строками, то зачем нужен язык который можен нормально работать только с дискретной логикой?

Хотя.. Вообще я вас понимаю. Я ведь раньше тоже на LD молился... Но потом прозрел

Сообщение отредактировал Sniper007 - 14.4.2009, 9:53

[Olex007]

Я вот лично тоже не встречал электриков подключающихся к сименсу. И думаю не встречу.

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
Вильям наш, Шекспир

Многому научились ваши электрики при обучении сименсу?

Быстро найти неисправность - уж больно дорог простой оборудования, а Стэп уже вмонтирован в панель-писи.

Кроме того. Я думаю тут даже никто и спорить не будет - выполнять арифметические расчеты и работу со времем на ST гораздо удобнее. А про строки, вообще молчу.

А никто и не спорит

Хотя.. Вообще я вас понимаю. Я ведь раньше тоже на LD молился... Но потом прозрел

Я по натуре атеист. И на ситуацию смотрю и стороны разработчика и со стороны эксплуататора . А у Вас ,как у программиста на стрельбище - у меня пули ушли, это у Вас с мишенью что-то не так..

Предлагаю прекратить сравнивать красное и кислое. Может кто-нить расскажет наконец об опыте работы с "прочими ICPDAS"?

[Sniper007]

Быстро найти неисправность говорите...
Ну даже не знаю. Я вот щас пишу программку для химучастка. Написал на SFC и ST. Все аварии и нештатные ситуации у меня отображаются на дисплее. Никакого знания LAD и ST обслуживающему персоналу не надо - достаточно прочитать то что написано. А потом подергать нужные датчики и посмотреть на светодиодики на контроллере.

А вот теперь вас послушал - наверно зря я так сделал.. Написал бы все тупо на LD, а всех операторов и электриков отправил бы на курсы Codesys. Думаю руководство очень было бы радо потратить пару тысяч енотов

[Гость_ggg__ggg_*]

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

[Olex007]

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

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

[Sniper007]

ggg__ggg уж не хотите ли вы сказать что невозможно опознать аварию большинства датчиков?
Вот давайте так. Порассуждаем издалека. Вот скажите, какова вероятность того что в Москве 4 января на улицах будет лежать снег? Очень высокая, потому что в России снегу свойственно выпадать в декабре-феврале.
Вот и здесь также! Датчик ведь выполняет одну и ту же функцию. Дискретный - проверяет наличие/отсутсвие объекта. Так ведь можно же предугадать его поведение?!
Допустим у нас есть некий ковейер. По нему идет какой то объект, на одной части конвеера, оптический датчик увидел объект, через 4 метра другой датчик его не увидел. Почему? Вероятно - обрыв второго датчика (или объект украли ). Можно выдать соответсвующее предперждение на панель оператора (скада систему).
С аналоговыми датчиками. Ну допустим датчик уровня. Когда происходит изменение уровня? Когда происходит наполнение или слив емкости. Допустим идет заливка емкости, а датчик в течении какого то времени не изменяет показания - очевидно что застрял поплавок (заклинил клапан заливки). Или наоброт... Может это "выловить" контроллер? Легко!
Какая связь между всем этим и ООП, языком C и ST? Да вот в чем. Конечно можно все это написать на LAD, но времени на это уйдет на порядок больше, чем на языке ST с использованием принципов ООП (в частности классов и наследования).

А теперь все таки скажите. Какая программа лучше - та которая сама "скажет" оператору (электрику, инженеру) что с ней не так (какой датчик не срабатывает, какой клапан заел), или ту для которой нужно принести ноутбук, привести электрика с высшим образованием (и курсами STEP 7), и который полчаса будет ковырятся в лестницах нормальнооткрытых-нормальнозакрытых контактов и в итоге что-то там найдет? С моей точки зрения - вопрос риторический...
Это знаете... Какой прибор лучше - тот который легко починить, или тот который не ломается?

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

[Olex007]

Какой прибор лучше - тот который легко починить, или тот который не ломается?

Конечно который не ламается, не потребляет электроэнергии. сам себя программирует...

Какой у вас опыт работы на производстве, непосредственно в цехах?

[Sniper007]

Какой у вас опыт работы на производстве, непосредственно в цехах?

Это что-то вроде - "Сам дурак"?

Достаточный, чтобы спокойную беседу.
Занимаюсь как эксплуатацией (потому знаю что такое километр релейных контактов языка LD, грохочущие прессы, агрессивные среды) и разработкой.
А вот вам, я так понимаю, сказать больше нечего...

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

[Olex007]

Ну у нас тоже и АСУТП и КИПиА вроде как занимались экплуатацией - на экскурсии в цех ходили или с проверками - очень удобно. Вот только их премия от простоев никак не зависела.

[Sniper007]

Повторяю еще раз - я ЗНАЮ что такое километр лестничных релейным диаграмм, у меня гудело в ушах после калибровки Омрона на машине шум который соизмерима с раскатами грома, у меня трещала голова после нескольких часов работы на хим участка с парами азотной и серной кислоты, меня неоднократно вызвали в выходные дни и по ночам (однажды меня вызвали 23 февраля в 9 часов вечера).
Поэтому давайте оставим тему о профессионализме и "экскурсиях" за пределами темы. Дармоеды думаю на этом форуме не сидят.