Доп. мысль: в языке SFC в CoDeSys есть атрибуты шага, особенно интересно: минимальное время активности. Тут можно указывать константы, переменные и даже элементы массивов. Например: делаем переменные (типа TIME), задаем в них нужные длительности. Далее в атрибутах шагов SFC, где задается мин. время активности прописываем эти переменные (переходы могут быть разрешены всегда – TRUE). Получаем программу с этапами, нужных длительностей, вообще без всякого программирования.
Технично?
Igor Petrov
Здраствуйте.
Уважаемый IP вам не кажется что эта особенность языка SFC противоречит идеологии ПЛК, в которой организация задержек не приемлема?
Да, технично. Хотя источником времени здесь служит все тот же системный счетчик, в неявном виде. На том же системном счетчике стоят периоды задач и т.д. Таймеры "питаются" также напрямую от Сис.Сч. Вообще говоря, играть можно на всем что тикает. Например, в SP RTE в качестве источника тактов времени можно использовать собственно сам цикл выполнения задачи (если он достаточно короткий), и вообще не прибегать ни к каким таймерам, задержанным условиям SFC и т.п. При этом, правда, наблюдается небольшой Jitter (дрожание длительности - на сильных компах почти не заметен), но в каждом конкретном случае можно решить - пренебрегать этим или нет. То была одна сторона дела - чисто техническая. С другой стороны - нужно воспользоваться результатами работы этих технических достижений. Пользовательские переменные и функции, которые естественно тактируются программным циклом, должны получать значения "устройств времени" должным образом. Иначе хитрозакрученные технические трюки могут оказаться "вещью в себе".
С уважением, SAN.
Первоначально опубликовано Nekit
Здраствуйте.
Уважаемый IP вам не кажется что эта особенность языка SFC противоречит идеологии ПЛК, в которой организация задержек не приемлема?
Отнюдь
Следует различать задержки выполнения цикла задачи и задержки изменения состояния алгоритма. Ведь задержка выполнения шага не приводит ни в коем случае к остановке цикла задачи, напротив цикл проходит дальше не выполняя ничего более шага на котором выполнение было задержано при текущем состоянии входных переменных, в данном случае время является такой переменной а программу можно рассматривать как простой конечный автомат состояние выходов которого строго зависит от состояния входных переменных и его внутреннего состояния, в которое он перешел в предшествующем цикле задачи. Следовательно время реакции нашего алгоритма на изменение входных переменных (в том числе времени) останется равным удвоенному времени цикла и остановка на шаге не приведет к остановке обработке имиджа процесса и прочим неприятностям которые могли бы возникнуть при действительной задержке цикла задачи
Первоначально опубликовано Dismay
Следует различать задержки выполнения цикла задачи и задержки изменения состояния...
Абсолютно верно!
Первоначально опубликовано SAN
]...использовать собственно сам цикл выполнения задачи...не прибегать ни к каким таймерам, задержанным условиям SFC и т.п....
Отсчитывать временные задержки на базе рабочего цикла возможно, но ИМХО делать это есть смысл для очень малых или некритичных к стабильности задержек. (Например, если используем коммутатор сигналов на 1 аналоговый входов и ему надо дать пару мс. после коммутации след. канала и т.п. ) Таймеры практичнее: интервал циклических задач можно менять как угодно, таймеры всегда будут работать правильно.
Igor Petrov
А вообще количество таймеров в программе ограничено или все определяется свободной памятью? В Шнайдере, на сколько я помню, оно всетаки ограничено.
Первоначально опубликовано Mixer
А вообще количество таймеров в программе ограничено или все определяется свободной памятью? В Шнайдере, на сколько я помню, оно всетаки ограничено.
Ограниченно количеством функц. блоков, что впрочем настраивается. Кстати, иногда специально избегаю стандартных TONов, TOFов, особенно если они вложены в другой функц.блок. Ведь что может получиться: вставил в такой блок пару таймеров, затем в основной программе - сотню блоков (обработка сигналов например), и вот получилось таймеров уже две сотни. Сравниваю в таких случаях системное время с заранее запомненной переменной типа TIME.
Первоначально опубликовано Mixer
А вообще количество таймеров в программе ограничено или все определяется свободной памятью?
Ко-во не ограничено. Самый первый, используемый в проекте, экземпляр любого ФБ кушает память кода, все следующие только память данных (суммарный объем всех переменных + 4 байта).
Igor Petrov
Первоначально опубликовано _IP_
Первоначально опубликовано Mixer
А вообще количество таймеров в программе ограничено или все определяется свободной памятью?
Ко-во не ограничено. Самый первый, используемый в проекте, экземпляр любого ФБ кушает память кода, все следующие только память данных (суммарный объем всех переменных + 4 байта).
Ну а количество функциональных блоков ведь ограничено...
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме