Конфигуратор ПЛК

[Fanat]

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

[Филоненко Владислав]

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

[Fanat]

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

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

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

[Fanat]

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

[Филоненко Владислав]

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

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

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

[Fanat]

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

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

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

[Филоненко Владислав]

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

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

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

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

RTU работает.

[Fanat]

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

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

[Филоненко Владислав]

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

[Fanat]

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

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