Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Какое железо выбрать? (страница 5)

Версия для печати (настроить)
Страницы: 1 2 3 4 5 6

Новая тема | Написать ответ

Подписаться

Автор Тема:   Какое железо выбрать?
ColdFire
Member

Сообщений: 243
Откуда: Россия
Регистрация: Ноябрь 2004

написано 25 Июня 2007 09:49ИнфоПравкаОтветитьIP

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

P.S. И слава богу - если доходит до контракта, потом всю душу вымотают при сдаче.

Я мотаюсь по стране по два раза в неделю, и констатирую - уже далеко не только Москва и Питер хотят жить хорошо, ценник в той же Перми, Самаре, окрестностях Е-бурга и проч. примерно сравнялся с нами, если кое-где не обогнал. И в зарплатах тоже сильно не отстают. Наколенное лабание было популярно лет 5 назад и более (неужели где-то еще осталось ?!) - я даже знаю несколько заводов, где принципиальная позиция старших технических начальников тогда была "нах нам контроллер за 10 тысяч баксов, когда у нас склад забит списанными "трешками", спаяем на коленке плату под ISA и заплатим сто баксов в месяц местному программеру - полгода будет разгребать геморрой, зато выйдет вдвое дешевле". В итоге уж не знаю судьбу тех начальников, надеюсь их погнали на пенсию, но те заводы давно перешли на Siemens (два завода точно) или что там еще.

Dmitry M. Gaidash
Member

Сообщений: 234
Регистрация: Сентябрь 2005

написано 25 Июня 2007 10:00ИнфоПравкаОтветитьIP

blackpitch
100 баксов вполне хорошие деньги на модернизацию шкафа управления скажем
Речь идет о "шкафе управления" автоматической поилкой в коровнике? Мало-мальски серьезное промышленное оборудование само по себе стоит сотни тысяч долларов, и 100 баксов на модернизацию автоматики - это максимум на покраску шкафа.

IP
Member

Сообщений: 83
Откуда: Russia
Регистрация: Июнь 2006

написано 25 Июня 2007 11:14ИнфоПравкаОтветитьIP

Один заказчик сейчас просто стонет по поводу установки, на которой поставлен пром. PC и программа написана на Си. Охотно верю, что написана она очень красиво и оптимально. Но при любом мелком изменении он вынужден падать в ноги к ее автору. А у того полно другой более интересной работы и от командировок уже тошнит. Вторая установка сделана на ПЛК. С ней проблем нет вообще. Теперь вот обсуждается: поставить на пром. PC МЭК систему и переделать ПО или ли ПЛК.

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

blackpitch
Junior Member

Сообщений: 26
Откуда: Россия, Тула
Регистрация: Ноябрь 2006

написано 25 Июня 2007 11:17ИнфоПравкаОтветитьIP

ColdFire
Согласен, руководсво прогрессирует в этом смысле Если хотим, что-то хорошее, то надо обращаться в серьезную контору.

Добавление от 25 Июня 2007 11:20:

IP
Господа, а как на счет qnx? Тама на сколько я помню работаем на С++ (серьезный проект

ColdFire
Member

Сообщений: 244
Откуда: Россия
Регистрация: Ноябрь 2004

написано 25 Июня 2007 12:03ИнфоПравкаОтветитьIP

Я полностью поддерживаю IP. Несомненно, что МЭКовские языки в некотором смысле связывают руки ПРОГРАММИСТУ. В некоторых задачах даже не то что связывают, а душат. А некоторые задачи на них вообще не сделать (банальная задача с локальным архивами "внизу" делается на МЭКовских языках, и то не везде, виртуозным почесыванием левого уха правой ногой, а отладка - мечта телепата). И само собой, что PC плюс C (или C++) - несоизмеримо гибкий инструмент.

Но... одно дело - сделать неимоверно красивую систему на C, от которой потом обслуга будет вешаться, и другое - типовые или почти типовые АСУТП, где времени колупаться с API просто нет между проектом, заказом оборудования и т.д. Голова должна быть занята именно основной задачей. Кстати МЭКовские языки именно оттуда и пошли - американец наш знакомый говорит, что программы управления там пишут ТЕХНОЛОГИ.

plazma
Junior Member

Сообщений: 9
Регистрация: Июнь 2007

написано 25 Июня 2007 13:25ИнфоПравкаОтветитьIP

Именно для "сложных случаев" в CoDeSys предусмотрен язык ST и указатели
Можно сделать всё и даже чуть-чуть больше

Dmitry M. Gaidash
Member

Сообщений: 235
Регистрация: Сентябрь 2005

написано 25 Июня 2007 14:44ИнфоПравкаОтветитьIP

ColdFire
А некоторые задачи на них вообще не сделать
За 5 с небольшим лет работы в этой отрасли неоднократно слышал такое утверждение применительно к МЭК-языкам, но ни разу автором данного высказывания не было приведено примера такой задачи. Зато много раз демонстрировалось незнание возможностей МЭК-языков и неумение ими пользоваться. Может быть Вы сможете разрушить устоявшиеся стереотипы?

банальная задача с локальным архивами "внизу" делается на МЭКовских языках
Легко и непринужденно - нужно лишь наличие соответствующих технических средств. Никаких принципиальных ограничений МЭК-языки на данную задачу не накладывают.

IP
Member

Сообщений: 84
Откуда: Russia
Регистрация: Июнь 2006

написано 25 Июня 2007 15:12ИнфоПравкаОтветитьIP

цитата:
Dmitry M. Gaidash писал:
..не было приведено примера такой задачи..

Нисходящий рекурсивный разбор

ColdFire
Member

Сообщений: 245
Откуда: Россия
Регистрация: Ноябрь 2004

написано 25 Июня 2007 15:27ИнфоПравкаОтветитьIP

Dmitry M. Gaidash
Не буду пробовать В особенности в связи с тем, что наверное я всех нюансов реализации всех предусмотренных языков не знаю - так что пожалуй сгоряча я ляпнул насчет "на них" и "вообще".

Мы же говорим не об абстрактных МЭК языках, а о конкретных их реализациях в конкретных контроллерах. Тот же LD с успехом решит задачу, например, расчета скользящего среднего, если конкретном случае будет иметься "элемент, реализающий функцию расчета скользящего среднего", а без него...

Dmitry M. Gaidash
Member

Сообщений: 236
Регистрация: Сентябрь 2005

написано 25 Июня 2007 15:59ИнфоПравкаОтветитьIP

ColdFire
Ну так поэтому МЭК-язык и существует не один Причем каждый из языков оптимизирован под свои собственные задачи.

IP
Нисходящий рекурсивный разбор
Ну это будет не в чистом виде рекурсия (она в МЭК просто-напросто запрещена), но никаких принципиальных сложностей не вижу - FB или FC+DB. Просто надо немного отойти от принятых и привычных для не-МЭК-систем приемов и стандартов Я бы даже сказал догм

plazma
Junior Member

Сообщений: 10
Регистрация: Июнь 2007

написано 27 Июня 2007 09:36ИнфоПравкаОтветитьIP

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

Dmitry M. Gaidash
Member

Сообщений: 238
Регистрация: Сентябрь 2005

написано 27 Июня 2007 11:19ИнфоПравкаОтветитьIP

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

IP
Member

Сообщений: 85
Откуда: Russia
Регистрация: Июнь 2006

написано 27 Июня 2007 11:40ИнфоПравкаОтветитьIP

Применение никакое, просто был вопрос придумать, что нельзя сделать в языках МЭК. ИМХО: их диапазон применения очень широк, но не безграничен. Известны примеры приложений с идентификацией по отпечатку пальца на ПЛК и др. и пр. Однако МЭК языки четко ограничены снизу, в смысле возможностей доступа к железу (это уже обсуждалось выше касательно дайверов). Но они также ограничены и сверху. Рекурсия (наряду с регулярными выражениями) – один из моих любимых фантиков, при аккуратном использовании вероятность пробить стек не выше чем при использовании библиотек с неизвестным уровнем вложений. Это пример ограничений сверху. Самый сильный в МЭК язык ST рожден в период рассвета классических Паскаля и Си, когда идеи структурного программирования считались пионерскими. Эти уже развились в сторону ООП и МЭК туда дорога

bessonov3
Junior Member

Сообщений: 19
Регистрация: Май 2007

написано 28 Июня 2007 10:19ИнфоПравкаОтветитьIP

IP
Эти уже развились в сторону ООП и МЭК туда дорога
Возникает вопрос - зачем повторять, то что уже сделано в С++ прочих ОО языках? Если я правильно понимаю MatLab и LabView не плохо обогнали МЭК языки в плане своего развития. Смысл в МЭК языках пропадает.

IP
Member

Сообщений: 86
Откуда: Russia
Регистрация: Июнь 2006

написано 28 Июня 2007 13:14ИнфоПравкаОтветитьIP

цитата:
bessonov3 писал:
Возникает вопрос - зачем повторять, то что уже сделано в С++ прочих ОО языках?

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

Эти требования легли в основу разработки CoDeSys V3. В нем МЭК языки расширены ключевыми словами из Java, позволяющими опционально использовать ООП. Т.е. все старые программы будут работать, кто не хочет, может не использовать ООП. Кто хочет, может постепенно его осваивать.

ИМХО заданный вопрос близок к вопросу: зачем делать электронное управление впрыском в грузовиках, если оно уже сделано в легковых машинах

цитата:
Если я правильно понимаю MatLab и LabView не плохо обогнали МЭК языки в плане своего развития. Смысл в МЭК языках пропадает.

Эти системы заточены несколько под другой класс задач и развиваются в разные стороны. С таким же успехом можно утверждать, что с MatLab пропадает смысл использования C++ или что языки функционального программирования вытеснят все прочие…

Dmitry M. Gaidash
Member

Сообщений: 239
Регистрация: Сентябрь 2005

написано 28 Июня 2007 15:10ИнфоПравкаОтветитьIP

bessonov3
Если я правильно понимаю MatLab и LabView не плохо обогнали МЭК языки в плане своего развития
Судя по всему, ты неправильно понимаешь смысл МЭК-языков

bessonov3
Junior Member

Сообщений: 21
Регистрация: Май 2007

написано 28 Июня 2007 16:13ИнфоПравкаОтветитьIP

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

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

Добавление от 28 Июня 2007 16:15:

Dmitry M. Gaidash
Судя по всему, ты неправильно понимаешь смысл МЭК-языков
Был бы язык, а смысл найдётся

Dmitry M. Gaidash
Member

Сообщений: 240
Регистрация: Сентябрь 2005

написано 28 Июня 2007 16:58ИнфоПравкаОтветитьIP

bessonov3
Для С++ это проще дописать, чем разрабатывать новый ОО ST
Ты заблуждаешься В МЭК-средах все уже давно написано, а вот реализовать подобное для C++ может оказаться вообще принципиально невозможно

Был бы язык, а смысл найдётся
МЭК-языки - это очень правильный и заточенный под конкретное использование в узкой предметной области инструмент Мнение программистов тут опять решающим не является, т.к. используют эти языки вовсе не программисты МЭК-языки - технологические языки. А никаких прикладных наработок в области АСУТП, которые требуют ООП, просто-напросто не существует в природе

blackpitch
Junior Member

Сообщений: 27
Откуда: Россия, Тула
Регистрация: Ноябрь 2006

написано 29 Июня 2007 08:12ИнфоПравкаОтветитьIP

Dmitry M. Gaidash

Ты заблуждаешься В МЭК-средах все уже давно написано, а вот реализовать подобное для C++ может оказаться вообще принципиально невозможно
Вот здеся я в принципе не согласен, ты еще скажи что на ассемблере вооще ничего написать незя

очень правильный и заточенный под конкретное использование в узкой предметной области инструмент
Разве не обратное утверждение?

Dmitry M. Gaidash
Member

Сообщений: 241
Регистрация: Сентябрь 2005

написано 29 Июня 2007 08:39ИнфоПравкаОтветитьIP

blackpitch
Напоминаю - речь идет о сервисных возможностях МЭК-сред разработки.

bessonov3
Junior Member

Сообщений: 22
Регистрация: Май 2007

написано 29 Июня 2007 10:13ИнфоПравкаОтветитьIP

Dmitry M. Gaidash
Ты заблуждаешься В МЭК-средах все уже давно написано, а вот реализовать подобное для C++ может оказаться вообще принципиально невозможно
Если для МЭК среды всё написано, тоже самое можно написать для С++, думаю даже проще.

МЭК-языки - это очень правильный и заточенный под конкретное использование в узкой предметной области инструмент
LD - для "перерисовки" релейных схем.
FBD - для "перерисовки" аналоговых схем.
Остальные языки и особенно ST тяготеют к программерским.

используют эти языки вовсе не программисты
НА МЭК прогрограммируют чаще программисты, а не технологи. Как раз обратная ситуация с LabView и MatLab - если программист там и нужен, то в самой минимальной степени.

Dmitry M. Gaidash
Member

Сообщений: 242
Регистрация: Сентябрь 2005

написано 29 Июня 2007 10:27ИнфоПравкаОтветитьIP

bessonov3
тоже самое можно написать для С++, думаю даже проще
Не "можно" - ты заблуждаешься, настаиваю на этом в который раз Практика - критерий истины. PC-совместимых контроллеров существует великое множество, но нет ни одной среды разработки с поддержкой C++ и стандартными сервисными возможностями МЭК-сред. Скажешь "не нужно"? Нужно и еще как. Так почему же этого до сих пор нет?

У нашей фирмы есть своя собственная среда разработки для PC-based контроллеров, причем весьма продвинутая, но до "убогого" (по твоему мнению) STEP7 по части сервисных функций ей как до луны пешком Больше скажу - есть другая фирма, которая уже в течение 7-ми лет, если не больше, развивает наш продукт силами весьма квалифицированных специалистов, так они только сейчас подобрались к резервированию контроллеров, а никакими онлайн-модификациями программы у них и не пахнет. Максимум - это кривоватая отладка (кривоватая по сравнению с возможностями МЭК-сред, опять же).

На МЭК прогрограммируют чаще программисты, а не технологи
Не согласен с тобой Программисты программируют на С++, а на МЭК больше конфигурируют, чем программируют И это есть правильно и хорошо - не нужно в АСУТП программирование, оно там только вредит.

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2 3 4 5 6

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика