Проектирование шкафов управления автоматики учебник
Обновлено: 01.05.2024
ТС умничка, но надо бы какой-то тег для таких постов. Библиотека, например.
Не могу скачать(( помогите!
вопрос по сабжу, работаю в эксплуатации асутп, есть похороненная и.д. и пробелы в пониманий работы некоторых алгоритмов, к контроллеру доступ есть (бернекер, семен, Алёна бредли , но зачастую не хватает знаний для понимания логики, к примеру есть запуск компрессора при таких то условиях, и идут перечисления и проверка состояния условий, вижу ссылки на фбд, но некоторые аспекты все же не знаю как интерпретировать, отсюда страх. возможно есть какието книги направленные именно на описание (структурного?) языка именно в работе плк? спасибо кто поделится советами и знаниями.
кстати особенная сложность возникает с бернекером, прям тёмный лес.
Господи, дай бог тебе здоровья и большой золотой шекель, сегодня же все скачаю
Отличная подборка. Но многая литература устаревшая.
Моя работа
Сегодня закончили тестовую пусконаладку очередной машины, на этот раз - пивной пастеризатор.
Нагрев продукта происходит в пластинчатом теплообменнике при помощи пара, регулировка подачи осуществляется клапаном с пневмоприводом. Надеюсь, продукт будет достойным)
Здравствуйте, сегодня произвёл тестовый запуск очередного агрегата, на этот раз - ультрапастеризатор с электрическим нагревом
Молоко в этой установке подвергается быстрому нагреву до 145 градусов, а потом также быстро охлаждается, что позволяет убить всякую каку и обеспечить долгий срок хранения продукта.
Мое участие в производстве данной машины состояло в создании системы автоматики, которая выполнена на базе программируемого реле Овен ПР-200, панели Кинко, пускорегулирующей аппаратуры Чинт. Нагревательные элементы управляются твердотельными реле.
Ну и, собственно, критика, как всегда приветствуется)
Платить зарплату "своим" или "чужим"?
Решил запилить свой комент в виде отдельного поста. К вот этому высказыванию
В качестве эпиграфа:
a) Зачем вам платить зарплату - вы же ничего не делали, поломок же не было?
b) Зачем вам платить зарплату - пока вы ремонтировали, оборудование же не работало, это же одни убытки из-за вас!
- Требования к кандидатам: молодые, желательно с опытом, высшее профильное образование, знание английского, ПК, отсутствие вредных привычек, способность к обучению ("учить ты будешь, а кто еще?"). Зарплата - курам на смех. Числиться будут рабочими, электриками. Потом, когда все закрутится и будет приносить хозяевам охеренные бабки, попытаемся выбить для них должности ИТР.
- Да блин, народ приходит, но услышав про размер зарплаты, грустнеет лицами и уходит.
- Начальство сказало: "больше платить не будем, за забором народу полно!"
Ну да, своих ремонтников можно и не содержать пока оборудование работает. Пока.
До поры, до времени.
А все когда-то ломается или ломают. И что тогда?
Искать ремонтников на стороне?
Ну, во-первых, толковые люди без дела не сидят.
А во-вторых, они именно ваше оборудование в первый раз видят, даже ерундовую неисправность первое время они могут очень долго искать.
Простейший пример (из рассказов коллеги, все совпадения абсолютно случайны ;-) Коллега мой, поэтому тэг "моё" - тоже мой)
- Вот, сигнал не приходит от этого датчика. А где он? Все кабели в трубах и лотках, мы, конечно. его найдем, но времени это займет. Есть схема расположения дачиков и пр. на установке?
- Да хер его знает, где этот датчик стоит! Не мое дело, мы только кнопки нажимаем! А чего вы его полгода ищете?
- Мы тут в первый раз вообще-то, а вы хоть что-то знаете, где какие датчики, клапана? Кто оборудование принимал?
- А запчасти есть?
Нет конечно же, никто этим не занимался.
Схемы и прочая документация - в состоянии: ". а нам так дали!" и "..да где-то было, но хер его знает, где оно сейчас".
Что именно "дали", а что - нет, никто не вникал, некому было. Это ведь начальство сразу и в обязательном порядке укомплектовывается, а всякая там "шелупень": АСУ-шники, КИП-овцы, слесаря, электрики - да нафиг надо, им всем зарплату подавай! Сломается - тогда и нанимать будем!
- Нам же сказали, что оборудование автоматическое, оно само работает!
- А что, ремонтируется оно тоже само?
- Нам про ремонты ничего не говорили!
- Ну ты же взрослый мужик уже, у тебя автомобиль же есть? Тебе говорили в автосалоне, что его когда-то ремонтировать придется, или сам догадался?
Досконально знает это оборудование его производитель, но у них выезды - очень небесплатные, особенно если они знают, что клиент никуда не денется.
Так что это - снова деньги, немалые и еще - ВРЕМЯ. Это у вас простой, это - ваши проблемы и убытки, остальным это не так горит, особенно - при наличии других, более жирных заказов.
А еще "закладки" бывают, и тогда странно видеть, как многомиллионное оборудование стоит потому, что своих спецов содержать посчитали ненужным, а "фирмачи" это видели и поставили таймер: гарантийный срок вышел и все встало.
Да, они готовы помочь вашему горю, никто не отказывается:
"Платите $50K авансом, оплачиваете авиабилеты, гостиницу, и наши специалисты в недельный срок прибудут, найдут неисправность, может даже сразу решат проблему. Если нужные запчасти у вас будут. А потом доплатите, сколько скажем" - такая вот "экономия" финансов вышла.
Когда нашли "по знакомым" своих спецов из смежной отрасли, те таймер нашли и убрали. Хозяева предприятия стали думать:
- а не взять ли вас на постоянку? Сколько вот вы бы хотели?
- ХХХ р в месяц!
- Давычто?! У нас начальник цеха столько не получает! Много хотите! Давайте за ХХХ/4!
- Вот пускай ваш "начальник цеха" тогда этим и занимается, зачем мы вам тогда?
- Запчастей нет, ремонтировать нечем!-
- Как же так. Ты запчасти заказывал. Это твой проjoб!
- Вот, - достает из папки, с собой носит, опытный уже, - заказывал. Бумажку вам приносил, вы подпись поставили!
Проектирование шкафов управления автоматики учебник
Артур, Проектирование под ключ, от создание фс, до проектирования щита автоматики, базовые знания есть, я это смогу сделать, но не хватает более углублённых знаний, студенческие задачки слишком приметивны, хочется серьёзней вникнуть в тему, так как видел промышленную тех док разработка автоматизированной котельной без участие персонала, очень интересно её изучать, но она сделана не так как нас учили вузе, более сложнее и развёрнутый. Туда фходит фс, схема внешних проводок, Эл принципиальная схема, схемы щитов автоматики, спецификация, да и вообще хочу научится разрабатывать проект пусть не большой но под ключ.
Анатолий, а зачем разбирать UL508A если в России проектируют установки на базе IEC? Крайне не советую копать UL стандарты, если вы хотите научиться проектировать системы в Европе или России, так как расчеты и методология там опирается на стандарт NEC который в свою очередь написан на имперской системе исчисления. Токи, типы оборудования, номиналы и тд. сильно отличаются. Я сам адаптировал несколько больших проектов с IEC на UL508A, и это был ещё тот геморрой. UL508A более требователен к оборудованию и запасам.
Андрей, без контроллера и программы это уже не "под ключ". Схемы это одно, а запуск объекта с нуля - это более широкий спектр работ.
Не пытайся "схватиться за сисю и писю одной рукой" - начни проектировщиком, потом АСУ ТП подхватишь
Мля, в принципах построения АСУТП за 30 лет точно ни чего не изменилось. И уж если видишь разницу между АСУ и САУ тогда проблем нет.
Владимир, Принцип не изменился, даже госты не менялись, но появилось новое оборудование, должны быть другие обозначения. Вообще раньше больше аналога было, сейчас цыфра.
Владимир, ну здрасте не чего не изменилось. Надеюсь вы не проектируете по стандартам 30 летней давности.
Владимир, вы опять не правы. Простой пример. Теперь системы ПАЗ можно делать полностью на profinet. 30 лет назад о таком даже мечтать нельзя было.
Принцип изменился от слова совсем.
Егор, ни чего не изменилось, то в каких рамках вы будете исполнять проект, зависит только от техзадания.
Владимир, вы с вашим тезисом определитесь сначала что бы что то утверждать. То вы про принцип построения, то про ТЗ. И там и там вы не правы. Элементарно даже требования к системе заземления изменились за 30 лет.
Владимир, но а если по существу, то вы хороший пример того, как инженер не развивается, а стоит на месте. "Я всё и так знаю". Вы вообще в курсе что с 2012 года теперь главенствующую роль имеют нормативы ЕАЭС?
Егор, вы просто путаете понятие принципа и метода реализации. И кстати принцип не один и они не изменились.
Владимир, нет, так не пойдёт. Общими словами любой мастак что то обсуждать. Давайте конкретику. Что вы вкладываете в слова "принцип реализации" ?
Егор, принцип, это изначальное представление системы, ее идеал. И на основе этого идеала уже создаются методы его реализации. Это рассматривается в самом начале курса теории автоматизации.
Владимир, понятно, вы оказывается и в вопросе не разбираетесь от слова совсем. Ещё ачх характеристики вспомните.
Владимир, самое смешное что вы начали игру в дурака только потому что с вас спросили, и как только вы поняли что ляпнуть ляпнули по незнанию лишнего, начали в игру слов клоунауду устраивать.
Пока ручками все не прошупаешь - никакие буквари не помогут
Наталья, знаем. мы таких проектировщиков, которым не доступны простые слова про единообразие и общую логику. когда два щита близнеца почему то имеют разный принцип обозначения устройств, а маркировка датчиков сделана как бог на душу положил. а на вопрос была ли логика, проектировщик говорит - была, но объяснить чем руководствовался не может.
Станислав, почему не доступны. Я вообще тоже за единообразие, логику, но также и за адекватную обратную связь и здоровые отношения между участниками процесса. Иногда нужно просто открыть рот и нормальным русским языком сообщить, что там у тебя не так, а не сидеть и растить свое ЧСВ и корону и материть всех подряд.
Наталья, порой именно те, кто занимается ПНР и монтажом знают и умеют больше проектировщиков. Лично у одного спрашивал: "Что это нарисовано?" - "Не знаю. ". "А фамилия не твоя в штампе, в графе разработал?" Евгений, бывает, не спорю. А бывает и так, что наладчик кричит что проект гавно, а конкретики никакой. А хорошее образование и изучение матчасти ещё никому не мешало. В прочем, если человеку дали образование, это ещё не значит, что он смог его взять Наталья, работаю инженером АСУ ТП и виде какие КИПовцы и АСУшники приходят - даже схемы читать не умеютЕвгений, ну тут готов поспорить. Знать и уметь - это все таки разные вещи. Хорошо быть умным, когда кто то спроектировал условно шкаф, а ты его уже собранным тестируешь в поле и материшь "тупых проектировщиков" что они не чего толком делать не умеют. Проблема в том что во многих компаниях проектировщики не ездят в поле и не получают обратную связь. А очень умные "наладчики" принести обратно замечания проектировщиком не в состоянии объяснив в чем именно была проблема. Это же на много сложнее когда у тебя есть собранное оборудование на объекте и найти проблему, чем проектировать в слепую по документации производителя(если она ещё имеется).
Егор, на своей работе у нас уже обыденность - одна контора монтирует насосы со шкафами управления, вторая - шкаф автоматизации, третья - шкаф диспетчеризации. Нихрена никто ни с кем ничего не согласовывает и в итоге один "боевой" АСУТПшник и монтаж ведёт, и шкафы модернизирует, и схемы правит, и программы корректирует. Вот тут опыт и приходит. Но бывают подрядчики, у которых обязательно проектировщик и программист на ПНРе.
Егор, а кто говорит, что тут равенство. Тут смысл в том, что знания приходят когда ручками сам щапаешь, а не ПДФ книгу листаешь.
Работал в организации, где вот тебе ТЗ, через месяц у тебя шеф-монтаж и ПНР. И все в одно лицо, от разработки схемы и заказа комплектующих, до отладки программы уже на объекте в собственноручно собранном шкафу.
Евгений, знания приходят когда ты читаешь и в живую трогаешь. Основной бич наладчиков - ни хрена не читают стандарты и знают в лучшем случае автокад. Поэтому нормальным проектировщиком который способен что то спроектировать серьезнее насосной станции стать не могут.
Егор, посерьёзнее насосной насосной станции должно проектировать целый проектный отдел. Или ты считаешь, что один проектировщик в силах "сваять" рабочий проект станции обеспечивающий город водой с несколькими агрегатами и десятками исполнительных органов, учтя при этом кучу защит что агрегатов, что питающей сети?
Евгений, это от куда у вас такие данные? Я в одиночку много какие проекты делал, но суть не в объеме, а в типе проекта. Требования к насосной станции обычно совершенно мизерные со стороны нормативных документов(если объект опять же простой). Другое дело если это ТЭЦ или нефтянка, где нужно знать массу документации для того что бы спроектировать систему.
Всем привет, я инженер программист и очень мне нравится собирать шкафы автоматизации. Хочу поделиться процессом сборки
Самое начало, снимаем панель шкафа, размещаем короба, крепим дин рейки, устанавливаем релюшки, блоки питания, контроллеры.
Ставим клеммы, розетки
Получаем вот такой результат, и начинается веселье- соединяем все проводами
Каждый провод маркируется и обжимается
У нас этим монтажницы тетки занимаются с образованием в ПТУ.
Это просто монтаж)))Ту и обезьянку можно посадить.Но надо обязательно инженера.Не забудьте-потом на производстве куда воткнут этот шкаф-столько косяков вылезет.Из-за непрожатого концевателя,плохого контакта,потому что клеммники эти нажимные уебище еще то))И там уже разбираться придется слесарю киповцу,а инженер-программист будет собирать где то далеко свой очередной шкаф.И где хваленное импортозамещение?
Вы не инженер-программист, а сисадмин
О! Собрат по несчастью :) Переферия ET-200SP рулит. Да и вся новая линейка контроллеров тоже ничего. Только вот никак из руководства маркиратор проводов не выбью:(
тс, красота, однозначно
Будто лего собирать.
Шкафчики, перфолотки, кабельные маркеры - ух! Это прямо "наше всё"!
Круто, чувак! Нас много)) Я тоже собираю такие вещи на фениксе и вайдмюллере
У кого комплектующие закупаете?
Да, это не СЦБ. это детские игрушки. Но красиво.
Как правильно такие маркеры для проводов называются?
лично мое мнение что двухуровневые клеммники неудобные при поисках неисправностей, но самое зло это трех уровневые и провод в шкафу моножила.
Про любимое дело.
Хочу поделится своим любимым делом. Деятельность моя относится к области промышленной электроники и автоматизации технологических процессов. Пытаюсь я найти довольно интересные для себя проекты, которых уже не один и не два. И вот с такого решил начать.
На одном предприятии, производитель вентиляционного оборудования (Бренд пусть остается тайной), есть отдел производства систем автоматического управления промышленной вентиляцией. Работа кипит, заказов у предприятия становится все больше и больше, и модификаций систем управления так же не мало. Конструкторский отдел справляется прекрасно, программисты от них не отстают. На производстве все налажено до автоматизма и работает как часики. Но вот не задача, собранная система управления требует программирование ПЛК, предварительной настройки и какой-то отладки. Что в свою очередь отнимает хороший кусок времени во всем технологическом процессе. Вот тут пришло в голову создание автоматизированного стенда для проверки собранных систем управления. Ну хотябы не всей линейки продукции, но как минимум большого объема однотипных систем.
Основа проекта составила контроллерное оборудование фирмы Siemens и вся системы была построена с использованием линейки S7-1200, а система визуализации на WinCC. Почему именно это решение а не, скажем, OWEN. Могу только ответить: потому)))
Первоначально система проявила себя очень удачно и проверка всех алгоритмов программы проверяемой системы управления происходило за считанные минуты или даже в некоторых случаях менее минуты. В проверку входило настройка схемы вентиляции, т.е. выбор устройств проверки, которых можно было выбрать около 13-15 штук. Видно на фото системы визуализации максимальной конфигурации. Так же опрашивался ModBus и алгоритм проверки сводился к тому, что получая сигналы от внешних исполнительных механизмов (сигналы от проверяемой системы), сравнивались с таблицей modbus и состоянию системы в целом. При удовлетворительной проверки узла, осуществлялся переход к следующему. Прелесть этой системы в том, что она значительно сократила проверку и отладку выпускаемой системы, свело к минимуму человеческий фактор, повысила производительность данной операции в технологическом процессе производства.
Дальнейшая работа показала что проекты на предприятии растут, заказы появляются довольно не простые и выпускаемые системы становятся так же громоздкими. Это привело к тому, что потребовалось небольшая модернизация системы управления.
Было закуплено пару дополнительных модулей и шкаф благополучно разобран и началась работа практически с нуля.
Когда железо было все собрано, началась работа над программным обеспечением. Цель работы была максимально задействовать все оборудование и отображение максимального количество сигналов. А так же алгоритмов процессов. Кстати, забегая вперед, пределу совершенствования нет, поэтому система в процессе эксплуатации подвергается всевозможным модернизациям и доработкам.
Система усложнилась значительно и количество обрабатываемых сигналов так же увеличилось. Изменены алгоритмы, добавились дополнительные блокировки и переключатели. Подключение к испытуемой системе осуществляется с помощью диагностических штыревых разъемов, а обмен данными о состоянии системы через RS485 ModBus.
Всего было создано шесть таких систем и полноценных рабочих мест во благо трудящихся)).
Надеюсь некоторым было интересно, что даст мне стимул продолжить публиковать свои, довольно интересные, проекты в области автоматизированных систем управления)) Всем добра!
Мой путь в пром. автоматизацию. Инженер-программист АСУТП
Итак, не так давно был пост Замкнутый круг - Siemens вокруг! не думал, что оставленный мною комментарий приведет к появлению у меня подписчиков и интересу к вопросу как стать программистом АСУТП.
Опишу вкратце саму специальность, обязанности и как я к этому пришел. Будет много текста.
Что делает любой программист? Правильно - программирует. И на этом можно было бы окончить описание, но не все так просто. Начнем.
АСУТП - автоматизированные системы управления технологическим процессом. Из расшифровки аббревиатуры уже можно понять, что задача инженера по автоматизации - создание программного продукта, который упрощает жизнь в первую очередь оператору механизма, который нужно автоматизировать (чаще происходит наоборот, так как не все хотят учить новое и упираются нововведениям всеми силами).
Обязанности могут быть самые разнообразные. В небольших компаниях инженер-программист может проектировать электрические схемы для автоматизируемого устройства, а затем и писать программу. В более крупных компания только программирование. Работал в компании где было 10 человек, не считая монтажников и в компании, где было свыше 200 сотрудников. Всегда будут командировки - вы будете участвовать в пуско-наладочных работах. Это если из основного. Не удивляйтесь и ситуации когда программист будет с отверткой что-то ковырять в щите управления чем-либо, отсюда следует, что вы обязаны уметь читать и при необходимости изменять электрические схемы, знать технику безопасности и ПУЭ ваша настольная книга. Иногда меня хотели заставить что-то изменить в силовой части подключения, но я этого не делал как бы косо на меня не смотрели электрики/монтажники. А вот объясню почему, на всех фирмах, где я работал у меня не было допуска по электробезопасности, а отсюда следует, что я вообще не должен лезть туда, где есть напряжение. Так что нет допуска - нет и каких-либо изменений схемах шкафа управления.
Часто бывает, что изначальная схема и то, что собрано по факту на объекте отличается. Причины могут быть разные - экономия (купили дешевле оборудование, решили поставить, что на складе нашлось, кто-то откат получил и т.д.). Задача программиста, который приехал на пуско-наладку подружить это все и заставить работать. Иногда это бывает очень непросто. Но про это будет позже, сначала необходима программа, а потом уже запуск объекта.
В общем выполнение работ по автоматизации проходит следующие стадии (упрощенно, на самом деле все немного сложнее):
1. Если участвуют несколько отделов в реализации проекта, то, когда приходит запрос из отдела продаж, каждый отдел предоставляет часы, которые потратит специалист на реализацию своей части. Далее это все суммируется и возвращается в отдел продаж. Они офигевают и ообычно на этом этапе уменьшаются часы, заложенные различными заинтересованными отделами, ибо дорого, и нужно продать. Ненавижу за это "продажников", хотя и понимаю, что это бизнес. Чтобы было понятно, в компании, где было больше 200 сотрудников были: департамент проектирования, департамент разработки ПО, департамент пуско-наладочных работ. И каждое подразделения выдавало кол-во часов на этот проект, необходимое для выполнения их части работ. И как итог выиграли тендер (если повезло, не будем говорить про остальные схемы).
2. На этом этапе обычно пишется ТЗ (технологическое задание) программистом на автоматизацию, хотя должно быть наоборот, заказчик должен предоставить описание того, что он хочет получить. Но у меня было так, как описываю. Дальше это ТЗ долго и нудно согласовывается с заказчиком, вносятся правки, ставятся подписи. Хотя это совсем не гарантия того, что ТЗ останется неизменным. Правки могут прийти, когда до начала пуско-наладочных осталось совсем немного времени, но почти всегда фирма-исполнитель прогибается под заказчика и программист потом в панике вносит изменения, что приводит к тому, что ПО будет не протестировано до конца, что приводит к задержкам при вводе в эксплуатацию и т.д. Но никого это обычно не волнует, хоть спи на объекте, но оно должно работать.
3. Когда есть ТЗ начинается, собственно, и реализация/придумывание того, как же оно все должно работать. Помимо программы для контроллера (ПЛК - программируемый логический контроллер) иногда нужно сделать и визуализацию. Для визуализации, в зависимости от поставленных целей применяется SCADA или HMI. В чем отличия отлично гуглится (статья и так уже огромная, сам не ожидал).
4. Тестирование программы на стенде или в симуляторах. Отлично работающая программа в симуляторе не равно иногда даже работающей на «живом объекте».
5. И самый интересный момент — это пуско-наладка (ПН). Об этом напишу подробнее.
Итак, что должен делать инженер во время ПН. Для удобства разделю на этапы.
2. Если предыдущий этап закончился успешно и все собрано правильно (на более-менее больших объектах с первого раза никогда все правильно собрано не будет) – то приступаем к проверке в ручном режиме. Для этого либо со SCADA либо HMI включаем/выключаем узел агрегата и смотрим все ли правильно работает и все ли правильно отображается. Часто бывают ошибки (если используется визуализация) в привязках переменных к объекту на визуализации. Например, запустили один механизм, а на панели/скаде отображается, что включился другой, хотя работает правильный ну и т.д. Эти ошибки сразу же исправляются и процесс проверки продолжается.
3. Когда закончили ручное тестирование – переходим к самому сложному и интересному (вот тут симулятор, если тестировалась программа на нем, и дает прикурить иногда). Автоматический режим. Ну с ним все ясно, перевели все механизмы в автомат и запустили объект.
С этим режимом всегда могут быть проблемы. И когда вы пишете программу нужно учитывать максимально возможные варианты. Например, на двигателе перестал работать датчик температуры и из-за этого запускать этот узел в автоматическом режиме нельзя (ведь датчик не просто так там установлен), но если этот узел нельзя запустить в автомате, то и остальные по идее тоже нельзя, так как в автоматическом режиме реализовываются блокировки, которые отключат механизм при неисправности. Неисправность одного узла не дает запустить другой от него зависящий ну и т.д. И теперь нужно ждать пока починят неисправность, а производство в это время стоит. И владелец кричит какие в обще все, хм, хорошие люди. Но обычно так не делается. Почти всегда есть возможность запустить все в автомате, даже если какой-то из узлов агрегата не может работать в автомате. Часто дается возможность отключить контроль какого-то сигнала, например, тот же датчик. Активируем эту функцию и все у нас работает в автомате, так как сигнал от датчика не учитывается и в дальнейшем это может привести к проблемам, но это уже ответственность заказчика. Все эти режимы описываются в инструкции и с большими предупреждающими знаками. При использовании систем визуализации часто делают так называемый лог событий сюда входят аварии (это всегда делается) и действия оператора (имя оператора, что нажал, какой режим выбрал, что изменил и т.д.). И если возникает поломка механизма по вине заказчика, так как отключили какой-то элемент контроля – то это уже не гарантийный случай и фирма, что делала автоматизацию не попала на деньги. Так как любой гарантийный ремонт делается за счет изготовителя, а в этом случае они сами виноваты.
На этом пока хочу закончить. И так уже вышел далеко за рамки того объема, который хотел написать. Возможно получилось как-то не слишком структурировано, но я старался))) Будет кому-то интересно возможно продолжу еще что-то по теме автоматизации писать.
Коллекция книг по проектированию, АСУТП, КИПиА
Читайте также: