PDA

Просмотр полной версии : Конфигуратор ПЛК



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

Филоненко Владислав
13.06.2007, 08:35
Быстрые процессы - например одиночный импульс от датчика положения.
Вариант с отд. сбросом рассматривался - но был отвергнут, т.к. требует больше вычислительных ресурсов на уровне ядра и доп. область ввода/вывода, что тоже нехорошо (для огр. лицензии).
Легко реализовать программный блок, к-й будет выполнять те-же функции.

Fanat
13.06.2007, 09:25
Быстрые процессы - например одиночный импульс от датчика положения.
Вариант с отд. сбросом рассматривался - но был отвергнут, т.к. требует больше вычислительных ресурсов на уровне ядра и доп. область ввода/вывода, что тоже нехорошо (для огр. лицензии).
Легко реализовать программный блок, к-й будет выполнять те-же функции.

Согласен, но тогда сам тригер уже и не нужен - он как раз и будет блоком реализован. Так что ситуация двоякая - встроите в оболочку - займете ресурсы, напишу я свой блок - сам скушаю эти ресурсы - вот и вся арифметика. По области ввода-вывода я не понял - по идее сброс из программы происходить будет - причем тут область вв/выв - Вам виднее.
Но по моему опыту - то тригер, который встроен использовать будут в 5-10% случаев, а тот, который я предлагаю 50-70%. Пример я уже описал - авария + ее квитирование - в программе этот момент не виден, а в конфигураторе настраивается за 5 секунд - упрощение получается.

Еще из вопросов:
1. Ранее говорили о возможности работы, когда 485 итерфейс занят под опрос слэйвов, Ethernet под диспетчеризацию, а по 232-м вы предложили работать с панелью, но в описании пишется, что 232 работает только в режиме ASCI, в то время как ИП320 работает в режиме RTU пока что. Что делать?
2. Еще есть мнение по поводу организации работы с аналоговыми входами ПЛК. Целесообразнее было бы реализовать битовым каналом аварии, т.к. оценивать код аварии не всегда целесообразно - иногда достаточно самого факта авариной ситуации.
3. При работе аналогового входа в качестве дискретного - есть ли возможность все-таки сразу реализовать булеву переменную, хотя подозреваю, что такой возможности нет. Да и оценить не сложно, но есть "хотелка" так сказать, да и не только для себя страюсь.

Fanat
13.06.2007, 10:20
еще непонятки:
1. по работе с константами описание очень куцое. и все же - как с ними работать? они сохраняются в энергонезависимой памяти?
2. по работе с архиватором - каким образом считать файл? по идее после доступа к файловой системе. на сколько показывает интуиция через Plc браузер, но можно ли поточнее или ссылку на доку. может это описано ниже, в данный момент я на странице 84 руководства конфигуратора.
3. так и не нашел в глубинах документации ссылку на то, что модбасовские переменные при работе плк как слэйва - сохраняются в энергонезависимой памяти.

Филоненко Владислав
13.06.2007, 10:21
С помощью программных средств проргаммы ПЛК модно отловить импульсы длительностью более 1 мс! А если надо меньше, то только тригеры/счетчики/энкодеры/модули спец. обработки (делаем по заказу). С быстродействующими оптронами вход ПЛК может обрабатывать сигналы с частотой до 200 кГц! С обычным оптроном - до 10-15 кГц.

1. У вас старое описание.
2. Блок анализа входного значения DECODE_FLOAT выдает 0, если всё нормально и !0, если ошибка. Вставить If-then и все нормально, разницы с битовым каналом никакой! Хватит экономить память, это не Logo!
3. If (value>=1) then есть контакт
else нет контакта.
Зачем бит?
И решение получается независимым от типа датчика.

Вообще ресурсы ПЛК позволяют использовать в качестве интерфейса между различными FB и программами значения типа REAL, что позволяет делать типонезависимые FB, к-е можно комбинировать в любом сочетании без операций преобразования - это просто фантастическая возможность.
А приведение к/от битам/др. форматам производить только на этапе ввода/вывода. Это очень удобно!

Fanat
13.06.2007, 10:49
С помощью программных средств проргаммы ПЛК модно отловить импульсы длительностью более 1 мс! А если надо меньше, то только тригеры/счетчики/энкодеры/модули спец. обработки (делаем по заказу). С быстродействующими оптронами вход ПЛК может обрабатывать сигналы с частотой до 200 кГц! С обычным оптроном - до 10-15 кГц.

1. У вас старое описание.
2. Блок анализа входного значения DECODE_FLOAT выдает 0, если всё нормально и !0, если ошибка. Вставить If-then и все нормально, разницы с битовым каналом никакой! Хватит экономить память, это не Logo!
3. If (value>=1) then есть контакт
else нет контакта.
Зачем бит?
И решение получается независимым от типа датчика.


Старое описание на что? То есть как я понимаю 232 работает в режиме RTU таки.
if then нас учили - просто я высказал свое мнение. И все же подумать стоит, я думаю.
А про тригер я с вами не согласен все-таки. Нужен он со сбросом ручным - проще так. Вы опрос проведите и поглядите, раз мне не верите. Но я не настаиваю.

Филоненко Владислав
13.06.2007, 11:47
еще непонятки:
1. по работе с константами описание очень куцое. и все же - как с ними работать? они сохраняются в энергонезависимой памяти?
2. по работе с архиватором - каким образом считать файл? по идее после доступа к файловой системе. на сколько показывает интуиция через Plc браузер, но можно ли поточнее или ссылку на доку. может это описано ниже, в данный момент я на странице 84 руководства конфигуратора.
3. так и не нашел в глубинах документации ссылку на то, что модбасовские переменные при работе плк как слэйва - сохраняются в энергонезависимой памяти.

1. Константы нужны для программы EasyWorkPLC, хранятся в энергонезависимой памяти (не Retain), других применений нет. Какое описание? Вбил число в параметр - появилось в канале.

2. Online->Read file from PLC. Или нашей утилитой.
3. Значит забыли внести, учтем.

про тригер - когда я его использовал, то делал сл-е:
смотрю, когда появляется единичка и делаю действие, тригер сам сбрасывается, удобно, что не надо отслеживать фронт и сбрасывать. Зачем еще внешний сброс? Лишнее действие. Память экономить?

RTU работает.

Fanat
13.06.2007, 11:53
про тригер - когда я его использовал, то делал сл-е:
смотрю, когда появляется единичка и делаю действие, тригер сам сбрасывается, удобно, что не надо отслеживать фронт и сбрасывать. зачем еще внешний сброс? лишнее действие. память экономить?

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

Филоненко Владислав
13.06.2007, 11:56
при такой логике - да, однако если надо различать одиночный импульс аварии (нажатие на кнопку) от многократного (судорожные конвульсии пальца оператора, плавно втягиваемого в аппарат), то ваше предложение не работает. и все это ради экономии 1 бита?

Fanat
13.06.2007, 12:31
при такой логике - да, однако если надо различать одиночный импульс аварии (нажатие на кнопку) от многократного (судорожные конвульсии пальца оператора, плавно втягиваемого в аппарат), то ваше предложение не работает. и все это ради экономии 1 бита?
вы меня не поняли. допустим на вход 1 пришел сигнал аварии 0 или 1 неважно. тригер взвелся. в программе авария оценена и произведены необходимые дейтствия, система остановлена. но авария никуда не делась - он все еще есть (причем не на выходе тригера а на самом входе плк). опреатор нажал на кнопку сброса - фигушки ему - импульс не пройдет. и лишь когда он найдет аварию и устранит ее причину тогда сможет сбросить триггер. такова идея.

Филоненко Владислав
13.06.2007, 12:53
если бы мы обсуждали прибор с фиксированной логикой, то необходимо было бы реализовать ту или иную модель поведения при аварии (в нек-х случаях и объектах - вашу), но мы говорим о плк, поэтому, имхо, надо жестко реализовывать лишь минимальный функционал, а лог. оьработку отдавать на откуп программисту плк, т.к. именно он точно знает, как должен функционировать прибор.
обсуждение не имеет практического смыла, т.к. вариантов может быть много, их все реализовывать?
объёмы кода и данных таковы, что на плк можно реализовать систему управления бурана, не не то что логику обработки аварий.

Василий Куц
13.06.2007, 19:57
что-то я не пойму, а зачем сброс-то на "хардварном" триггере???

собственно поскольку процесс быстрый, то "хардварным" триггером определяем его сработку, далее с него кидаем на вход взвода софтового триггера со входом сброса. соответственно на вход сброса кидаем (not авария And сброс от оператора) и получаем то, чего и требовалось.

Safron
20.01.2010, 12:56
вопросик о подключении энкодера. в руководстве о конфигурации как- то скупо описано. получается что для каждой фазы а и в я должен объявлять подмодуль энкодер, но тогда нафига First Input и Second Input. дважды что-ли вводить одни и те же значения.
неужели нельзя просто на програмном уровне считать количество импульсов в единицу времени и естественно обнулять при этом???

Филоненко Владислав
20.01.2010, 15:43
1 энкодер - 1 модуль энкодера. First Input и Second Input естественно должны иметь разные значения