Блок на симатике формирование импульса по времени.

[ASUTP_PLC]

Есть задача с простым заданием.

Нужно на Симатике сформировать импульс. Этот импульс должен быть настраиваемый (нужно чтоб можно было менять его длительность).

В нужное время (как пример это два раза в сутки). Он должен формироваться.

Вообщем, написан был участок кода который сравнивал уставку задаваемого времени с текущим. Как пример, контроллер ловил переход с 59 на 00 для минут.
Схема простая, и как бы рабочая. Но переход фронта этого меркера бывает формируется не четко.
/на контроллере крутится много задач, и бывает ситуация когда это FP этого меркера не формируется (есть меркеры совпадения минут и часов и объединенны с меркером такого перехода)/.

Каким решением можно воспользоваться чтоб сформировать подобный импульс четко с точки зрения метрологии.

[CHANt]

Есть задача с простым заданием.

Ага, спасибо за задание! А зарплату платить будут? :D

Нужно на Симатике сформировать импульс. Этот импульс должен быть настраиваемый (нужно чтоб можно было менять его длительность).
В нужное время (как пример это два раза в сутки). Он должен формироваться.

Прошу прощение за контрвопрос...А что у Вас за SCADA в системе используется? И сама задача - Вам надо два раза в сутки параметр сохранять?

[ASUTP_PLC]

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

[ASUTP_PLC]

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

[CHANt]

Если надо архивировать какой то параметр, да по определенным правилам, то лучше делать через архиватор винЦЦ, а с контроллера эту нагрузку снять. В TagLogging же можно кучу таймеров создать определить правила и прочее... На мой взгляд - так правильней

[ASUTP_PLC]

Нет, это должен делать именно контроллер. А с WinCC так не пройдет. Потому как клиент WinCC не один, и выполняют они дублирующие функции.

[ASUTP_PLC]

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

[Степа]

Каким решением можно воспользоваться чтоб сформировать подобный импульс четко с точки зрения метрологии.

Если с точки зрения метрологии - надо копать в сторону сертифицированных аппаратных реле времени.

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

Но архивировать какой-то параметр в контроллере... Не думаю, что это хорошая мысль.

[CHANt]

Время готовности PLC и время готовности рабочей станции с операционной системой достаточно сравнить. Все явно не в пользу рабочих систем, где даже операционные системы не реального времени.

Для чего, для архивирования Вашего технического учета? Вы же так и не сказали что за задача.
Событие в PLC можно по разному организовать, еще и зависит от модели контроллера, потому как в 300 серии возможностей работы с прерываниями по времени гораздо меньше чем в 400.
Так как работаю в основном с 300 серией, то обычно пользуюсь тактовым меркером цпу, т.е. накапливаю за несколько секунд параметров, далее, если требуется, обрабатываю, и дальше считывает винцц по своим таймерам там и обрабатывает, сохраняет. Почитайте как там настраиваются архивы, возможности обработки переменных и их буферизацию.
Если речь идет про систему коммерческого учета, то она изначально должна иметь методику выполнения измерений согласованную ВНИИМС.
Если надо в тех.учете что-то более жесткое, то тогда надо прикреплять к измерению метку времени и разбирать на верхнем уровне.

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

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

[san]

Приведите сначала свой код и толком объясните чем он Вас не устраивает.
Ещё важна точность импульса, я надеюсь вы понимаете что о микросекундах, например, и речи быть не может! Ну вобщем уточните свою задачу.

[ASUTP_PLC]

На контроллере S7-400 крутится сбор и перерасчет данных.
Это формирование производится обычным сравнением
В коде это выглядит примерно так
A M 141.1 /х.з./
FP M 155.1
= M 155.0

A M 141.2
// М141.2 переход через 0 по секундам, минутный импульс
FP M 155.3
= M 155.2

A M 141.3
// М141.3 переход через 0 по минутам, часовой импульс
FP M 155.5
= M 155.4

A M 141.4
// М141.4 переход через 0 по часам
FP M 155.7
= M 155.6

A M 142.2
// событие сутки
FP M 156.5
= M 156.4
//далее событие результат смены.

[ASUTP_PLC]

Как бы работает. Но длительность фронта того же меркера похоже не очень большая. Так как когда требовалось просто понулить резултаты событий смены - то не всегда это обнуление происходило до конца.
При этом относительно несложные преобразования происходят в блоках функций, и их очень много групп. Примерно под четверть тысячи /250/.

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

[san]

Вам получается нужно чтоб импуль спродержался, пока скада его не заметит? Тогда задача сама просится на решение средствами СКАДА. Иначе, какие бы вы большие импульсы не делали, пропуск всегда будет вероятен.

[ASUTP_PLC]

Я его спродерживаю таймером. Но что-то похоже упускаю из поля зрения. Самое важное, похоже что бывает и этот импульс не формируется.
Видимо какие-то особенности наличия фронта FP.
Если они в разные циклы FP сформируются, видимо я импульс потеряю.

[ASUTP_PLC]

Проблема есть в коде.

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

Вот этот участок кода
O(
L MW 134 //текущее значение часа
L 6
==I
)
O(
L MW 134 //текущее значение часа
L 18
==I
)
FP M 156.0 //бит сброса
= M 156.1 //импульс события

В меркерном слове MW134 хранится значение часа получаемое из системных часов контроллера.

[ASUTP_PLC]

Код простой. Но самая большая проблема, что бывает такая ситуация, что событие сброса смены не формируется.
И крутит счетчики накопленное и в результаты смены идут накопления нескольких смен.

[CHANt]

У Вас M156.1 имеет значение "1" с 6 до 7 часов и с 18 до 19 часов. Может все же стоит учитывать минуты и секунды, "импульс" ведь нужен?

[ASUTP_PLC]

Я все понимаю. Но мой разум отказывается принимать тот факт, что импульс может не сформироваться.

Бывает ситуация когда несколько смен нет сброса счетчиков вообще. Как такое вообще возможно учитывая этот код?

[Ryzhij]

А насколько Вы убеждены, что этот участок кода выполняется всё время, и нет условий по которым он по-просту "обходится" в программе?
Может где-то есть ещё один "возврат в начало" - END?
Может быть есть смысл, например, переместить этот код в самое начало или в самый конец программы?

[CHANt]

Не знаю даже, в симуляторе, в ОВ1, работает все отлично - бит M156.1 держится ровно от момента его выставления до следующего выполнения этого участка (1 скан). Так что, все что находится после этого участка должно сработать. Да и за много лет не наблюдал глюков в этой части, а довольно часто приходится использовать на всякие кнопки. Посмотрите еще раз на всю программу, в литературе рекомендуется использовать значение M156.1 сразу же после присваивания ему 1. Может какое ОВ прерывания срабатывает в это время?

[ASUTP_PLC]

В проекте задействованы OB1, OB32 и OB35. OB32 вызывается каждые 1000 ms. OB35 100 ms.

Этот код работает в блоке OB35. В одном нетворке стоит вызов функции с этим кодом
UC FCXX
и сразу в следующей строке вызывается за ним еще другая функция UC FCZZ.

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

[CHANt]

А сбрасываемые счетчики в каком ОВ вызываются?

[ASUTP_PLC]

Сбрасываемые счетчики вызываются в OB32.
Там же был кстати как раз участок кода в самом конце. Он сбрасывал меркербит сброса в самом конце OB32.

Выкинул этот код, потому что проверял по отчетности, была ситуация когда сумматоры не все сбрасывались.
Сумматоров почти несколько тысяч. (две тысячи точно есть). Не знаю как контроллер там "ВСЁ" успевает, но успевает как-то :).

[CHANt]

Ну вот и первый "глюк" - сколько раз ОВ35 отработает, причем прервав работу ОВ32, пока ОВ32 отработает и снова вызовется?
А фронт сигнала M156.1 "живет" только один скан ОВ35. Я бы перенес все (и Ваш "импульс" и счетчики) в ОВ1 и не мучился.

[ASUTP_PLC]

Импульс у меня формируется в OB1. Поставил еще триггер. Посмотрю позже. Как сработает. /склонился к такой мини-отладке/. Все таки мы тут не гуманитарии, все просто надо проверить практикой.