Недостатки контроллеров фирмы Siemens

[Михайло]

Я считаю обратное - программировать должен программист.

Бедный программист... Ему же не просто программу писать надо будет, но и изучать толстенные талмуды про объект управления и про элементы системы автоматики. Иначе программу не напишешь...

[Alexander]

Дык этого мало бедному программисту. Нужно не просто знать процесс, а знать его досконально. Зачастую много лучше, чем его знает и представляет технологический персонал. Иначе т.н. программист НИКОГДА в приемлемые сроки не напишет адекватную процессу программу. Если это сделано программистом, который умеет только красиво писать программу - результат, как правило, однозначный: все выбрасывается и делается заново, и уже другими людьми....

[Marrenoloth]

Дык этого мало бедному программисту. Нужно не просто знать процесс, а знать его досконально. Зачастую много лучше, чем его знает и представляет технологический персонал. Иначе т.н. программист НИКОГДА в приемлемые сроки не напишет адекватную процессу программу. Если это сделано программистом, который умеет только красиво писать программу - результат, как правило, однозначный: все выбрасывается и делается заново, и уже другими людьми....

Думаю, что под этими словами размашисто подпишется каждый из нас !

[Василий Иванович]

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

[Владимир Кузнецов]

ИМХО качество любой АСУТП определяется прежде всего уровнем разработчика, а не используемым железом

Причем уровнем как самого проекта АСУТП (железа), так и уровнем проекта алгоритма (про который часто вообще забывают и пусконаладчик пишет его сам на коленке).
(всё это зверский офтопик, который лучше выделить в отдельную тему).

[Владимир Кузнецов]

Нужно не просто знать процесс, а знать его досконально. Зачастую много лучше, чем его знает и представляет технологический персонал. Иначе т.н. программист НИКОГДА в приемлемые сроки не напишет адекватную процессу программу.

Вы забываете про ТЗ и проект алгоритма, где должно быть всё описано (когда/что происходит, реакция на события, алгоритмы управления устройствами, ...).

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

Скорее всего Вы ни разу не видели "красивой" программы, и приводите пример работы как раз низкокачественного разрабтчика, какого нибудь малограмотного студента.

[Marrenoloth]

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

Скорее всего Вы ни разу не видели "красивой" программы, и приводите пример работы как раз низкокачественного разрабтчика, какого нибудь малограмотного студента.

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

Но аццкий конечно попер!

[san]

Я уже путаюсь, какие темы читаю :-) Как минимум три ветви слились в одну тему: PC-base vs PLC. Причем все три функционируют одновременно.

[Владимир Кузнецов]

но технологии конкретной установки не знал

Где в этот момент был технолог и почему не было проекта?

Просто потому, что доводилось в запарке и часть не успели

Но виноват конечно же программист АСУ, да :)

Как сказано в подписи участника Barsik

Запуск и модернизация оборудования без проекта и документации. Дорого.

В этом всё.

[Marrenoloth]

Владимир! Я себе эти вопросы уже 8 лет задаю! И, сдается мне, что я такой не один! :D
А подпись - таки да! Правильная!

[Михайло]

Вы забываете про ТЗ и проект алгоритма, где должно быть всё описано (когда/что происходит, реакция на события, алгоритмы управления устройствами, ...).

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

[Alexander]

"Вы забываете про ТЗ и проект алгоритма, где должно быть всё описано (когда/что происходит, реакция на события, алгоритмы управления устройствами, ...)."

Гы... Сколько я их перевидел, вот таких алгоритмов, "где все должно быть описано", еще с советских древних времен! Солидные институты писали, наверное тысячными коллективами. Вот только ни разу не видел чего нибудь путнего, реализованного на основании этой писанины. Проектировщики и алгоритмисты не учитывают массы нюансов, и именно эти нюансы гробят все на корню. Это один момент. Другой момент - откуда этому алгоритмисту знать, как это можно реализовать на конкретных технических средствах?

"Скорее всего Вы ни разу не видели "красивой" программы"

А чего мне их видеть? Я их сам массу переделал за те годы, что занимаюсь разработкой систем... И здается мне, что многие из них ну просто откровенно красивые :D (кто-же будет хаять свое любимое дитя? ;) )

Ацкий офф топик, согласен!

[Михайло]

Всех с днем программиста!

[Владимир Кузнецов]

Хм... Нафига тогда существование программиста, если уже все описано и написано?

Вопрос из серии "зачем нам режиссёр, в сценарии и так всё расписано".

[Михайло]

Не из той серии.

[Barsik]

Как сказано в подписи участника Barsik

Запуск и модернизация оборудования без проекта и документации. Дорого.

В этом всё.

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

[Владимир Кузнецов]

Не из той серии.

В чем спор то?
Пытаетесь доказать, что разработчик АСУ не должен уметь программировать?

[Михайло]

Я лишь талдычу о том, что "чистые программисты" в АСУ - время насмарку. Программисты должны участвовать в разработке ТЗ, составлении алгоритма и на прочих стадиях, но в таком случае они уже не становятся "чистыми" и времени на вылизывание кода не остается.

[Владимир Кузнецов]

Я лишь талдычу о том, что "чистые программисты" в АСУ - время насмарку.

Я про "чистых" и не писал :)

Разработчику автоматизации необходимо изучение и технологии и программирования.

[Sergeyvmm]

По теме: Я не знаком с АБ, работаю в основном с симатиком, раньше работал с омроном, модиконом, АББ. Единственное, что меня бесит в симатике - монструозность программных пакетов. На компе, где он встал, остальное жить нормально уже не будет. Все остальное вполне терпимо, а по появлению привычки и вообще не заметно. Кстати, отладка совершенно точно лучше, чем у омрона и абб. Есть даже плохо понимаемый плюс, который многие считают минусом - это жесткая привязка к адресам. Для ввода новой переменной в программу не нужно перекомпилить ее, она и так уже есть в адресном пространстве. Почему считаю это важным: сейчас параллельно я программирую на B+R и могу сказать, что при создании новой переменной в программе на С нужно компилировать и перезаливать прогу с остановкой контроллера. А в случае сименса я могу любое изменение программной части делать на лету, уже при идущем техпроцессе.
По оффтопику: Без знания технологии программиста лучше не пускать к объекту. Но иногда бывает, что технология по-настоящему сложна и тогда нужен отдельный человек, который разъяснит программисту нюансы или недопустимые варианты. Но лучший способ, и это жесткое ИМХО - программиста делать из технолога. Я сам имею технологическое образование, но програмил еще с института. После института пошел по управлению объектами из специализации, а там и переключился на новые технологии.

[san]

По теме: Я не знаком с АБ, работаю в основном с симатиком, раньше работал с омроном, модиконом, АББ. Единственное, что меня бесит в симатике - монструозность программных пакетов. На компе, где он встал, остальное жить нормально уже не будет. Все остальное вполне терпимо, а по появлению привычки и вообще не заметно. Кстати, отладка совершенно точно лучше, чем у омрона и абб. Есть даже плохо понимаемый плюс, который многие считают минусом - это жесткая привязка к адресам. Для ввода новой переменной в программу не нужно перекомпилить ее, она и так уже есть в адресном пространстве. Почему считаю это важным: сейчас параллельно я программирую на B+R и могу сказать, что при создании новой переменной в программе на С нужно компилировать и перезаливать прогу с остановкой контроллера. А в случае сименса я могу любое изменение программной части делать на лету, уже при идущем техпроцессе.

Вот это уже сравнение! Только вот тут просят только недостатки указать, а не преимущества.

[atamkosta]

Да сложно обсуждать красоту программирования когда алгоритм уже написан грубо говоря за программиста. Ведь наш главный алогритм - это ТП. Он дан и нам надо в нем плясть. И разумеется прежде всего знание ТП, основ производств, ТАУ и ТОЭ. Красивый алгоритм чего? ПИД реглера? Красиво написанный и отлаженый лабораторно ТП это и есть наше ТЗ и наш базовый алгоритм.

Тем более перспектива ухода от централизации - то ...?

Ну и обсуждать как бы без примеров не интересно. Я имею в виду примеров своей дееятельности, методов и мыслительного процесса при этом. Свой опыт с S5,S7 и АБ я черпаю из пищевки, фармы и бродилки. И по себе могу сказать будь то новый ферментер или "гниющая" с проблемами чистая комната, знание предмета это основа. Алгоритм правится и меняется глядя в микроскоп. Начиная от базового цикла развития микроорганизма, собственно этот цикл, точнее его оптимум и есть последовательность наших шагов.
И действительно растишь, смотришь каждый день на инверсном микроскопе, считаешь, красишь на живые/мертвые, считаешь, подбираешь... Это все в ферментере в 10 литров с АББшкой 07CT41 (31ая серия). Потом считаешь на пятидесятитонный реактор, и пишешь на четырехсотке симатике, и опять смотришь в отладке, считаешь, видишь те же картинки.... Изысканность кода здесь 2% остальное: знание ТАУ и биохимии. Аналогично: алгоритм сан.обработки в чистой комнате контаминированной дрожжами начинается с определения рода и вида, (измерений ламинарных потоков, определении качества фильтраций...), разведения высеянного и определения факторов безоговорочной капитуляции обнаруженных негодяев и потом излитии этого в ПЛК.
То же самое можно сказать о металлургии и о многих других ТП.
Поэтому и предлагаю сказанное иллюстрировать личными примерами. А то как то не красиво сказать - "Вы просто не видели..."

[Looker]

По теме: Я не знаком с АБ, работаю в основном с симатиком, раньше работал с омроном, модиконом, АББ....

Вот это уже сравнение! Только вот тут просят только недостатки указать, а не преимущества.

Чтобы корректно сравнивать нужно очень хорошо знать сравниваемые системы.

Из моего опыта - обучал эксплуатацию тезнике AB, после объяснения работы таймеров дал задачу - включение двигателя с переключением "звезда-треугольник" и ушел на перекур.
По возвращению - результата нет. Спрашиваю: "Помощь нужна".
"Спасибо. Попытаемся сами". Через несколько минут потребовали помощь. Когда с моих подсказок сделали работающий код, наступило удивление: "Вот так просто!".
Потом было мое удивление: "Почему должно быть сложно?"
"Мы пытались делать как для Симатика".

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

Как можно "любить" Симатики после такого:
http://vdt-automation.com.ua/modules.ph ... opic&t=691

[san]

Вы сами себе перечите.

Чтобы корректно сравнивать нужно очень хорошо знать сравниваемые системы.

С Симатиками дело не имел, не имею, не буду иметь..

Как Вы можете обсуждать недостатки Симатиков, ни разу не работая с ними?
"Ваши контроллеры такие плохие", "А откуда Вы знаете?", "У меня друзья с ними работали, рассказывали".
И совсем другая противоположность, когда человек работал только с Симатиками, и все недостатки ПЛК (если они для этого человека появляются) связаны только с желаниями иметь лучше.
Я например, не работал с АБ, но наслышан о них только хорошое. Но я точно не буду их хвалить и хаить, пока не сделаю хотя-бы один проект с использованием этой техники.

[Looker]

Вы сами себе перечите.

Чтобы корректно сравнивать нужно очень хорошо знать сравниваемые системы.

С Симатиками дело не имел, не имею, не буду иметь..

В чем противоречие?
То, что с Симатиками дел иметь не буду. Хватило почитать Бергера..
Давно, очень давно, выбирали на чем делать...
Тогда выбирали из 4 брендов, Сименс оказался на 4-ом месте.
АБ на первом, и уже 20 лет не жалею, что работаю с их техникой.