Ставим два таймера, один с замкнутым выходом, другой с разомкнутым. Данный пример отображает работу гидравлического механизма с двумя катушками Y21 и Y22.

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

Если будут вопросы, пишите.

Про ОРС Сервер и CoDeSyS 3.5

OPC сервер ОВЕН свяжется по Ethernet С ПЛК200 чтобы в SCADA передать?

Можно использовать OPC сервер ОВЕН в режиме Modbus TCP Master

С ОРС сервера записываю напрямую в Retain переменные, почему они не сохраняются при пропаже питания?

Поднимайте slave через библиотеку OwenCommunication

Примеры реализаций в CoDeSyS 3.5

Какой-нибудь пример, как расходомер реализовать?

См. в библиотеке OSCAT Basic блок FLOW_METER

У Codesys есть такая функция, вот управление клапаном открыть, закрыть, задаёшь полный ход клапана в сек, чтоб можно было задать ему проценты, и он открывал на нужное в процентах?

Вы можете использовать ФБ APID_POS_VALV из библиотеки CmpOwenPidRegs

Подскажите пожалуйста, а у ПЛК200 есть системная переменная времени цикла?

Видео на Youtube

Разное-всякое в CoDeSyS 3.5

глобальные переменные в cds3.5 они энергонезависимые?

По умолчанию нет

Как в ПЛК200 в символьной конфигурации папки создавать?

Для OwenCloud папкой будет являться каждая программа/список глобальных переменных, которая используется в символьной конфигурации

Owen Logic и Облако

ПР103 на 24 В сколько может влезть всего целочисленных переменных с облака?

примерно 150-200 переменных целочисленных

Owen Logic вопросы по программе

В Owen logic есть функция MOVE, чтобы мне можно было записать переменную?

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

ПР103 включили в режим DHCP для подключения к облаку Owen Cloud, включить то включили, все здорово, а овен лоджик перестал видеть прибор, как мне к нему теперь по Ethernet соединиться?

Подключиться по USB и посмотреть текущий IP, указать его в настройках подключения в ОЛ.

Вопрос-ответ по PLC Soft (Optimus Drive)

в Optimus Drive есть таймер который делается меньше 10 ms ?

T252~T255, но если Вы хотите получить действительно 1 мс строго, то к каждому из этих таймеров можно привязать подпрограмму прерывания. I49 – I52

Я могу в каждом шаге один и тот же таймер T252 использовать?

Таймеров 4 штуки, использовать можно таймер 1 раз в программе. Но его контакт Вы можете использовать неограниченное количество раз.

пример опроса Модуля тензодатчиков A01WG

Обращение к регистрам через команды FROM/TO.

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

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

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

И так, в конце 1987 года создалось КБ, а в апреле 1988 года я перешел туда инженером-программистом. Вроде бы так моя должность называлась. КБ было преимущественно молодежное. Руководил им грамотный товарищ, который через полгода стал замом Главного инженера, а я стал начальником КБ.

Политех разрабатывал нам АРМы проверки и один АРМ «центральный процессор» для управления процессом и ведения архивов, как на бумажном носителе, так и в электронном виде. Женская часть КБ разбиралась с КД по проверки и помогала в языке высокого уровня ТурбоБейсик сочинять политеховцам программу центрального процессора. Вернее, разрабатывали прогу девчонки при постоянном контроле и подсказке работников политеха. А мужеска часть КБ, на тех же условиях разрабатывала в ассемблере программу для контроллера К1-20 микропроцессорной 580-й серии микросхем.

И не смейтесь над нами. Никаких Виндоус тогда еще не было, ТурбоБейсик был крутой язык и в ассемблере было не западло писать программу. Напомню, что это был далекий 1988-й год. Мы планировали писать программу центрального процессора на отечественной ЭВМ ДВК, но потом разжились IBM-ками. И если на ДВКшках мы в редкие минуты отдыха гоняли компьютерную игру Тетрис, то на IBMках начали кроме игр серьезно изучать языки высокого уровня типа Турбо- и Квикбейсика.

Поскольку я в университете прослушал курс лекций программирования на Алголе и Фортране, а также прошел практику по программированию, я тоже начал вместе с дамами нашего КБ программировать на Бейсике. А не осваивал один ассемблер для К1-20. Изучение Бейсика мне кстати очень пригодилось в дальнейшем. Ну об этом потом. А пока расскажу о составе и характеристиках контроллера К1-20. Это его типовое что ли название. Реально у нас были две опции контроллеров с шифрами МС2702 и МС2721.

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

Питание 5В было мощное – 3А. Контроллер грелся, но работал. Скажу, что мы успели поставить три АРМа в одном цехе и один в другом. Работа кипела. Собирались внедрять программу «центральный процессор» и увеличивать количество АРМ и диапазон охвата. Но (как часто в жизнь вмешивается это чертово «Но») наступила конверсия и датчики стали нужны в значительно меньших количествах, а с ними не стала нужна и наша автоматизация.

Хотел привести краткие технические характеристики контроллеров, но у меня документации давно нет. А в интернете что-то не нашел. Поэтому пишу, что помню.

Эти контроллеры содержали полноценные микропроцессорные комплекты 580-й серии. С контроллером прямого доступа к памяти, контроллерами прерываний и последовательного интерфейса. Разница была в конструкции пульта и количестве разъемов.

У МС2702 было 3 разъема, но большие. У МС2721 – 5, из которых 4 – меньшего размера, а пятый – такой, кажется, как у МС2702.

В коробочке в фольге микросхема ППЗУ для прошивки пользовательских программ. ЗИП в конденсаторную бумагу завернут, кроме картонной упаковки. Маленькая отвертка присутствует. В общем – кайф или мечта автоматизатора советских времен. Итак, переходим к основной части.

Состав АРМ:

1. Контроллер МС2702 (2721)

2. Блок питания контроллера ГН 09-01

3. Вольтметр В7-28 (В7-34)

4. Блок сопряжения

5. Жгуты

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

А вольтметр В7-34 работал с индуктивными датчиками. Они питались от напряжений с частотой 400 Гц или 2000 Гц, и спокойно обсчитывались умеющим измерять переменку В7-34. Для потенциометрических датчиков опорное напряжение бралось со штатного блока питания ГН 09-01. Индуктивные же запитывались со специализированного блока переменного тока заводской разработки.

Блок сопряжения состоял из отдельного корпуса и платы коммутации и платы связи с вольтметром. Плата коммутации осуществляла перебор датчиков на коллекторе. Плата вольтметра программировала вольтметры и посылала команду «Пуск» при считывании данных с каждого проверяемого датчика. Корпус служил для подсоединения плат и соединения разъемов внешних жгутов.

Жаль, что у меня нет фото АРМа целиком, фото блока сопряжения и схем АРМа. Могу только по памяти изобразить функциональную или структурную схему АРМа и блока сопряжения.

Все пропало в период перестройки и дикого капитализма. И так промышленный уклад у нас в стране был не очень крепкий. А в период позднего Горбачева и Ельцина стал вообще ни в дугу.

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

Хорошо сейчас процесс потихоньку налаживается.

Еще раз благодарим Михаила Непомнина за рассказ, а также дополним его историей развития Московского завода тепловой автоматики (МЗТА), а точнее кратким перечнем приборов автоматизации, также предшественников современных ПЛК, которые были созданы до событий, о которых идет речь в статье, то есть до 1988 года.

• 1955-60 гг. – первый электронный прибор – ЭР-111-К – «КОМЕГА», дифференциальные манометры и электронные приборы регулирования – РБ-100

• 1960-е – комплекс – КРИСТАЛЛ, регулирующий прибор импульсного действия с бесконтактным выходом – РПИБ, дифференциатор ламповый – ДЛ-Т, электронные сигнализаторы и ограничители температуры ЭСП-К, ЭОС-Т

• 1974 – регуляторы энергетических установок – КАСКАД, КОНТУР

• 1975 – прибор регулирующий – Р25, прибор корректирующий – К15.3

• 1981 – прибор контроля пламени – Ф34

• 1982 – фотодатчик низкочастотный – ФДЧ, блок управления релейного регулятора – БУ21

• 1983 – индикатор положения – ИПУ

• 1984 – устройства для автоматизации промышленной энергетики и теплоснабжения – Р29

• 1986 – программируемый регулятор – ПРОТАР

• 1987 – многофункциональные регуляторы ТЕПЛАР, ПРОЛОГ, прецизионный регулятор температуры – ПРОТЕРМ

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

Материалы исследования опубликованы в сборнике «Химия. Экология. Урбанистика», 2024 год. Исследование выполнено в рамках программы стратегического академического лидерства «Приоритет 2030».

Чтобы оптимизировать процессы производства, обеспечить безопасность и снизить нагрузку на персонал, разрабатывают специальные системы мониторинга сигнализаций, которые контролируют и обрабатывают поток сообщений. Но существующие системы отличаются высокой стоимостью и ограниченностью — не дают возможность адаптировать продукт под конкретное производство, им не хватает универсальности. Большинство подобных систем — зарубежные, применять их на предприятиях России становится сложно.

Научные сотрудники Пермского Политеха и компании «Промышленная кибернетика» разработали систему мониторинга, которая существенно повышает уровень безопасности на технологических площадках. Это становится возможно за счет снижения загруженности оператора, уменьшения количества срабатываний сигнализаций до уровня, рекомендованного международными и национальным стандартом РФ, и своевременного обслуживания/замены отказавших элементов системы управления.

— Наша система базируется на доступных программных решениях и обладает достаточной гибкостью для внедрения в любую действующую систему управления как иностранного производства, так и современного отечественного. Разработка выполнена в виде готовой программы и основана на универсальной платформе, благодаря чему можно использовать ее в заводских сегментах сети, выполняя все требования контроллеров безопасности в объектах критической инфраструктуры, — объясняет доцент кафедры «Оборудование и автоматизация химических производств» ПНИПУ, кандидат технических наук Борис Стафейчук.

— Предложенная система мониторинга реализована на языке программирования Python и протестирована на тестовом стенде c системой управления Yokogawa. Результаты тестовой эксплуатации программы позволяют судить о корректности ее работы. В настоящее время система постоянно усовершенствуется, за счет использования единой платформы и базы данных, которые позволяют формировать абсолютно любые формы отчетности и добавлять новые функции по желанию конечного пользователя, — дополняет студент магистратуры кафедры «Оборудование и автоматизация химических производств» ПНИПУ Вячеслав Братчиков.

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

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