SIEMENS, DF&PD

Предыдущее посещение: Вс июл 03, 2016 23:37 Текущее время: Вс июл 03, 2016 23:37

Часовой пояс: UTC + 3 часа




 [ Сообщений: 55 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Точность подсчета времени цикла
СообщениеДобавлено: Ср авг 01, 2012 18:31 
Не в сети
Начинающий писатель

Зарегистрирован: Пт дек 18, 2009 15:04
Сообщения: 72
DDD
Используйте SFC64 и не теряйтесь в догадках.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 02, 2012 7:23 
Не в сети
Известный Писатель

Зарегистрирован: Вт июл 06, 2010 11:44
Сообщения: 315
Откуда: Газ-Система-Сервис Пермь
j.hlebnikov писал(а):
Непонятно где вы увидели ошибки.

Ошибки в значении PREV_CYCLE любом случае будут, хотя бы на округлении до 1мс.
Вообще, я не видел, чтобы у сименса где-то было написано, что сумма PREV_CYCLE в OB1 будет равна времени работы. А так же, прямых указаний на то, входит или нет в PREV_CYCLE время затрачиваемое на работу операционной системы (обновление образов процесса, коммуникации и прочее).
j.hlebnikov писал(а):
Ну понятно, это ваши теоретические рассуждения, доказательств я пока не увидел.

В общем-то можно сделать тестовый проект следующего вида.
Имитировать постоянное значение аналогового сигнала с небольшой синусоидальной составляющей и подать его для интегрирования трем разным функциям:
1) на Time_TCK в OB1
2) на PREV_CYCLE в OB1
3) на PREV_CYCLE в OB35 (например 100мс)
4) на счетчике вызовов OB35 (умножая на период)

Рассчитать точное значение интеграла - элементарно, и с ним сравнить расчетные значения по каждому варианту.
Если кому-то интересно, то сделаю такой проектик.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 02, 2012 7:46 
Не в сети
Ведущий специалист

Зарегистрирован: Вт янв 11, 2005 9:27
Сообщения: 5022
Откуда: SIEMENS I IA AS Москва
Естественно во время цикла входит все! И, наверное, к большому удивлению некоторых форумчан описание этого факта есть в документиации Сименса!
Например, тут http://support.automation.siemens.com/W ... n/12996906 глава 6.2
А по поводу разници во времени - Ветер59 прав. Округление параметра PREV_CYCLE происходит и, скорее всего, не в большую сторону. Вот отсюда и набегает разница во времени.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 02, 2012 7:47 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
Вообще это
BETEP59 писал(а):
В общем-то можно сделать тестовый проект следующего вида.
Имитировать постоянное значение аналогового сигнала.
интересно, но кажется надо определиться - что хотим получить в результате?
Может проще обратиться к документации? Документ "Программирование", глава 4 "Основы проектирования и структуры программы" там есть пункт 4.2.3.1, в котором много интересного :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 02, 2012 13:01 
Не в сети
Написал больше чем Вы читали

Зарегистрирован: Ср июл 07, 2010 0:27
Сообщения: 1230
Откуда: ООО Фирма "КГПА"
BETEP59 писал(а):
Ошибки в значении PREV_CYCLE любом случае будут, хотя бы на округлении до 1мс.
Не соглашусь с этим.
Если время цикла идет меньше 1мс - контрол копит его и когда оно превысит 1мс выдает 1, потом снова копит и выдает 0.

BETEP59 писал(а):
Если кому-то интересно, то сделаю такой проектик.
Мне интересно, хоть не совсем понял суть, пробелы в математике.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт авг 02, 2012 17:37 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
Чтобы замерить время программы достаточно два раза вызвать SFC 64 "TIME_TCK" : До события и после события. Вычтя из времени_после время_до, получите время обработки события с учетом накладных расходов операционной системы, обработки прерываний и т.п. И естественно оно будет плавать. Соответственно никто не мешает таким же образом и время цикла. Разрешающая способность - 1миллисекунда. Ну а в чистом виде, без накладных расходов это время разве кому-то нужно. Кроме того, другие программные навороты будут вносить погрешность за счет добавления сложноучитываемых накладных расходов.

Можно поставить прецизионный генератор и измеритель периода. Можно использовать FM458 - у него цикл 100мкс. Но, по моему, это уже из пушки по воробьям.

теоретически есть еще один способ, основанный на использовании таблиц времени выполнения инструкции. Обычно для этого используется прерывание по слежению. Но как такое реализовать в ПЛК, я смутно представляю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 04, 2012 9:04 
Не в сети
Написал больше чем Вы читали

Зарегистрирован: Ср июл 07, 2010 0:27
Сообщения: 1230
Откуда: ООО Фирма "КГПА"
Провел эксперимент по отсчету времени, сравнивал с часами компьютера, на реальном 315.
1. накапливал время прошлого цикла ОВ1, почти за 3 часа набежала ошибка в 35 секунд,
2. накапливал время прошлого цикла ОВ35 (30мс), за те же 3 часа набежала ошибка в 2 секунды,
3. в одном проекте накапливал циклы ОВ1 и ОВ35, там же делал разницу по sfc64, за 3 часа все методы дали ошибку примерно в 35 секунд.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 04, 2012 9:48 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
что и в принципе логично - генератор то один и тот же. Если посмотреть на описание ОВ3х, то они позиционируются как прерывания от деления частоты основного генератора.

Единствено, что с моей точки зрения, работа по SFC дает возможность мерять любые (в пределах разрядности) интервалы времени, в том числе некратные времени цикла, и поэтому более универсально.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Сб авг 04, 2012 12:09 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
Пришли к тому, с чего начинали
ВЕТЕР59 писал(а):
PREV_CYCLE тут вообще не годится. Если просуммировать все его значения за фактические 20 минут, то расчетные 20 минут никак не получатся.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 05, 2012 15:12 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
вообще-то эта методическая аддитивная погрешность, и она очевидна. Нужно брать как интервал для замера необходимый отрезок, а не суммировать кучу мелких отрезков, в каждый из которых входит своя погрешность.полная аналогия с линейкой: если вы будете откладывать один отрезок 10см вы получите совсем длиную длину, если отложите 10 отрезков по 1см, потому что в каждой отрезке по 1см будет сидет еще погрешность его замера


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 05, 2012 15:27 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
gre_m писал(а):
..один отрезок 10см вы получите совсем длиную длину, если отложите 10 отрезков по 1см, потому что в каждой..
Уже начали цитировать друг друга, кажется ВЕТЕР59 писал о том же
Цитата:
Вообще, это же очевидная вещь - при суммировании частей ошибки также суммируются:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 05, 2012 16:31 
Не в сети
Написал больше чем Вы читали

Зарегистрирован: Ср июл 07, 2010 0:27
Сообщения: 1230
Откуда: ООО Фирма "КГПА"
Не вижу смысла продолжать этот диспут, топикстартеру это уже не интересно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс авг 05, 2012 19:50 
Не в сети
Это точно не человек

Зарегистрирован: Вт май 03, 2005 17:11
Сообщения: 3547
j.hlebnikov писал(а):
Не вижу смысла продолжать этот диспут, топикстартеру это уже не интересно.


Надо ли понимать это что Вы и топикстартер одно и то же лицо? :-).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 06, 2012 17:45 
Не в сети
Известный Писатель

Зарегистрирован: Вт июл 06, 2010 11:44
Сообщения: 315
Откуда: Газ-Система-Сервис Пермь
BETEP59 писал(а):
В общем-то можно сделать тестовый проект следующего вида.
Имитировать постоянное значение аналогового сигнала с небольшой синусоидальной составляющей и подать его для интегрирования трем разным функциям …


Сделал тестовый проект: https://docs.google.com/folder/d/0BzHYjljW5tYiZkhsbkt6bHlMSjQ/edit

Описание.
Два исследуемых подхода:
а) FB102 IntgrCycl_FB - интегратор на циклах (исходник IntgrCycl.SCL)
б) FB104 IntgrTick_FB - интегратор на системных тиках (исходник IntgrTick.SCL)

Интегрируемый сигнал формируется в блоке
FB101 Weigh_FB
Сигнал моделируется в виде постоянного значения с синусоидальной составляющей
(реализовано в FB200 M_SIN исходник Lib.scl). Параметры моделирования задаются в блоке данных DB101 Wigh – либо через исходник CFG_Weigh.SCL (исходная конфигурация), либо из ВАТ.

Текущее значение сигнала Weigh.Value подается на интеграторы:
в OB1:
- Интегратор на циклах IntgrCycl_FB.IntgrCycl_OB1()
- Интегратор на системных тиках (метод прямоугольников и трапеций)
IntgrTick_FB.IntgrTick_OB1(mode=0)
IntgrTick_FB.IntgrTick_OB1T(mode=1)
в OB35
- Интегратор на циклах IntgrCycl_FB.IntgrCycl_OB35()

Далее в OB1 вызывается модуль управления тестом FB100 Test_FB
Здесь:
1) Реализован ручной и автоматический (при изменении уставки сигнала) сброс. Признак сброса Test.Rst фиксируется на 1сек и используется для сброса интеграторов и анализа результата (ошибок)
Тест начинается при установки бита Test.Start (из ВАТы).
2) Рассчитываются фактическая длительность (период) теста и расчетное значение интеграла (среднее значение на длительность).
3) Полученное расчетное значение сравнивается со значением полученным каждым способом интегрирования. При этом вычисляются
Eabs: REAL; //абсолютная ошибка, ед
Erel: REAL; //относительная ошибка, %
Emax: REAL; //максимальная ошибка, ед
Emin: REAL; //минимальная ошибка, ед
Вычисление ошибок реализовано в виде FB105 Check_FB (исходник Check.SCL)
Вычисление ошибок осуществляется по окончании полного периода моделируемого сигнала (признак Weigh.FullPeriod).

Управление и наблюдение осуществляется из VAT_TEST.
- устанавливаем Test.Start = 1 (или меняем уставку моделируемого сигнала) и смотрим на результаты.
Результаты.
У меня была возможность проверить только на PLCSIM.
Изображение
Ошибки составляют тысячные доли процента (Erel). Так что в PLCSIM получается неплохо при любом методе и дальше тестировать PLCSIM нет смысла :), нужно реальное железо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 06, 2012 17:54 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
По ссылке два проекта, что из них что.

Но вообще тест, не таким изощрённым способом, правда, уже был сделан, результат тоже был предоставлен.

Железо будет завтра под рукой - 315-2PN/DP - протестирую.

Да и Ваше же утверждение
Цитата:
Если просуммировать все его значения за фактические 20 минут, то расчетные 20 минут никак не получатся.
во всяком случае у меня, уже сомнений не вызывает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 07, 2012 6:20 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
ВЕТЕР59, выложите плиз архивы куда-нить на файлообменник. У меня с гугла не хочет сохранять.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 07, 2012 7:56 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
Изображение
Вот такие результаты получены на реальном CPU315-2PN/DP 2EH13-0AB0 v2.6.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 07, 2012 12:27 
Не в сети
Известный Писатель

Зарегистрирован: Вт июл 06, 2010 11:44
Сообщения: 315
Откуда: Газ-Система-Сервис Пермь
Cerberus писал(а):
Вот такие результаты получены на реальном CPU315-2PN/DP 2EH13-0AB0 v2.6.

Что-то не то с результатами.
Почему-то все интеграторы сбросили счет и отсчитали 3 секунды.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 07, 2012 13:46 
Не в сети
Возможно это нечеловек

Зарегистрирован: Пн окт 30, 2006 16:27
Сообщения: 2265
Откуда: Украина, Днепродзержинск
Хм, проект из архива загрузил в контроллер. Правда были ещё и блоки помимо этого (кой-чего до этого проверял).
Если интересно, то могу заново поставить на проверку.
Перед этим ПЛК сделаю рестарт. Свои блоки уберу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 07, 2012 17:55 
Не в сети
Известный Писатель

Зарегистрирован: Вт июл 06, 2010 11:44
Сообщения: 315
Откуда: Газ-Система-Сервис Пермь
Удивительные результаты получились при тестировании на железе.
CPU414-3 PN/DP, зашит только тест и хардваре.
Изображение

Изображение

Изображение
Итого - интегрирование на циклах OB1 никуда не годится.
Цикл OB1 в данном случае составлял 1-2мс (по данным module information), так что накопления проводились с шагом 1.5мс и ошибкой 1 мс. Т.е. сплошная ошибка - что и видно.
Несмотря на короткую длительность OB1 - интегрирование на тиках более менее отработало. Но при этом ошибка этих интеграторов возрастала крайне нелинейно. До 9-й минуты она росла (и точность интеграторов был заметно хуже чем у OB35), а на 10-й минуте стала резко убывать и даже выравнялась с OB35 (что и запечетлено на картинке), затем стала опять возрастать. Что за чудеса?
OB35 в данном хардваре работал с периодом 5 мс, и по-идее при округлении CYCLE_TIME = 5ms с точностью 1мс мог бы хапать ошибки порядка 20%, однако этого не происходило - значит прерывания обрабатываются более чем точно.
Кроме того, можно предположить, что циклические прерывания реализованы на аппаратных таймерах с автоматической перезагрузкой, т.е. ошибки в периоде каждого прерывания не накапливаются, а идет "сквозной" счет. В нашем случае это означает, что интегрирование на циклах в циклическом прерывании практически идентично интегрированию на тиках.
Итак, для прояснения картины нужно сделать тест с ограничением минимальной длительности OB1. Например, задав в HW minimum scan cycle time = 50 ms. Сейчас сделаю.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
 [ Сообщений: 55 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения

Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group