This is topic Проблема с Local Statistic in forum SIAD/SQL. Архивирование в TRACE MODE / SIAD/SQL. Data Logging in TRACE MODE at Форум TRACE MODE: техническая поддержка.
Задача стоит следующая: вычислить интеграл из архивных данных за периоды с 10:00 до 10:20, с 10:20 до 10:40 и с 10:40 до 11:00.
Версия TraceMode IDE 6.06.
Создали числовой канал (Real) в который программно записываем значения (данные канала заносятся в SIAD1).
Создали канал Call (тип вызова -LocalStatistic, интервал выборки - Offset) для каждого интервала времени.
Создали программу, в которой с помощью канала Time вычисляем величину Offset для каждого интервала (число секунд с 1970), а также задаем Delta равную 1200.
Передаем Offset и Delta в каждый канал Call.LocalStatistic. Во входное значение каналов Call.LocalStatistic пишем 1 каждые 10с, для каждого интервала смещение 10с (1й каждые 10с, 2й каждые 20с...; нет одновременного обращения к архиву).
Проблема в следующем: каналы Call.LocalStatistic выбирают данные из архива, выполняют статистику, но, диапазоны выборки не те, что мы запрашиваем (судим по 31 и 32 аргументу), T_From вместо 10:00 >>> 10:19, а T_TO вместо 10:20 >>> последнее значение в архиве(текущее время).
И, следовательно значение интеграла все время растет, а не расчитывается за нужный нам промежуток времени.
Подскажите пожалуйста, почему так происходит?
[ 14.07.2011, 09:59: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Механизм с использованием Offset и Delta устарел. И мы не рекомендуем его использовать в новых проектах.
Используйте
Параметр=32
Канал CALL.LocalStatistic извлекает архивные данные по заданному каналу в диапазоне (T_FROM, T_TO), разбивает диапазон на заданное число интервалов и по каждому интервалу вычисляет те же статистические параметры, что и при Параметр=0-31.
Конфигурация CALL.LocalStatistic:
канал, чьи архивные значения должны быть обработаны, должен быть привязан к CALL.LocalStatistic;
значение канала CALL.LocalStatistic задает число интервалов. Если задан единственный интервал, статистические параметры записываются в аргументы CALL.LocalStatistic;
начиная с arg2, к аргументам CALL.LocalStatistic привязываются каналы CALL.ChGroupReq или CALL.TVC, в аргументы которых записываются интервальные статистики.
Таким образом Вам понадобится только один канал CALL.LocalStatistic с выборкой за час и разбитый на 3 интервала.
Posted by Soyuz (Участник № / Member № 2028) on :
объясните пожалуйста: как нужно сконфигурировать CALL.ChGroupReq или CALL.TVC, какие аргументы создавать и сколько?
Вы писали: "значение канала CALL.LocalStatistic задает число интервалов". Какое значение, реальное?
Когда используешь CALL.LocalStatistic с Параметр=32, что должно быть выставлено в "Интервал выборки"?
Для отработки CALL.ChGroupReq или CALL.TVC нужно что-то писать во входное значение этих каналов?
Спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Создавать те же аргументы, что и в Call.LocalStatistic, только без учета задания даты и времени
2) В Вашем случае надо подать 3 во входное значение канала.
3) Без разницы. Но лучше оставить по умолчанию.
4) Нет. Они получат данные автоматически.
Posted by Soyuz (Участник № / Member № 2028) on :
Можете прислать тестовый проект в котором будет наглядно видно как реализовать Call.LocalStatistic с Параметром = 32?
[ 23.06.2010, 16:13: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
отправлено. Внимание! Разработка примеров проектов по завякам пользователей не входит в обязанности службы технической поддержки и выполнятеся на добровольной основе. Спасибо за понимание!
Posted by Svasl (Участник № / Member № 4229) on :
А можнотоже тестовый пример на эл. адрес, указанный в профиле.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
отправлено
Posted by Soyuz (Участник № / Member № 2028) on :
Получили тестовый проект, но к сожалению он не помог
разобраться как заполучить статистику за несколько
интервалов времени.
Вы в письме написали: "В приложении пример. К сожалению, в справке есть неточности. А именно Разбиение (T_FROM, T_TO) на интервалы Значение младшего полубайта атрибута Параметр канала-инициатора выборки задает величину интервалов, на которые разбивается диапазон (T_FROM, T_TO) (соответственно, число интервалов равно результату деления диапазона на интервал): 0 - нет разбиения на интервалы; 1 - 60с; 2 - 1ч; 3 - 5мин.; 4 - 15мин.; 5 - 20мин.; 6 - 30мин.; 7 - 2ч; 8 - 4ч; 9 - 6ч; 10 - 8ч; 11 - 12ч; 12 - 24ч; 13 - 1 неделя (недели отсчитываются с начала года); 14 - 1 декада (декады отсчитываются с начала месяца); 15 - 1 месяц (число дней в месяцах соответствует календарным значениям). А не так как написано. ..."
Скажите, что всетаки писать в атрибут -"Параметр"
канала Call.LocalStatistic? Число интервалов, на
которое нужно разделить временной интервал(T_FROM, T_TO), или код,
который Вы указали в письме(... 3 - 5мин.; 4 -
15мин.; 5 - 20мин.; ...)?
Распишите пожалуйста, как пользоваться тестовым
проектом, что и куда писать чтобы получить
статистику по каналу как было нами указано выше. Posted by Svasl (Участник № / Member № 4229) on :
Присоединяюсь к вышенаписанному посту. Хотелось бы именно комментариев по вашему примеру. Call3-Call7 - в чем приниципиальная разница? В вызове LocalStatistic (Call1 )Параметр 37. Что это означает? Да и в шаблоне экрана тренд привязан к реальному значению. Это точно пример обсуждаемой проблемы? Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Как работает?
Посылаете 1 в канал Call#1 и смотрите результаты в других кналах Call.
2) Параметр = 37 означает, 32 + 5. Т.е. Вы работает по новому Механизму. 1 в старшем байте. 5 в младшем байте означает разделение на интервалы по 20 мин.
3) Каналы Call с 3 по 7 получают соответствующие данные по интервалам в свои аргументы.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Добавлю, что 1 в ARG_001 канала Call#1 означает 1 – T_TO = <начало текущего часа>; а 2 в ARG_000 - T_FROM = <T_TO – 1 час>;
Прочитать об этом можно в разделе "Временной интервал выборки"
Posted by Soyuz (Участник № / Member № 2028) on :
Уважаемая тех. поддержка, Вы вообще пробовали запускать тестовый проект?
Потому что, запустив проект мы обнаружили, что процедура получения статистических данных архивных значений за несколько интервалов времени отличается от указаной Вами.
Если мы ошибаемся, то пожалуйста поправьте нас.
1) Интуитивно определенная процедура получения статистики по нескольким интервалама времени следующая:
в канале Call.LocalStatistic создаются 32 аргумента (ARG_00 ... ARG_31);
ARG_00 - T_From (число секунд с 1970); ARG_01 - T_To (число секунд с 1970);
К тем аргументам, которые отвечают за свою статистику ( среднее, интеграл ...) привязываем канал Call.ChGroupReq у которого также создаем аргументы того типа что и статистическое значение.
В аргументы канала Call.ChGroupReq записывается результат статистики за каждый интервал времени (ARG_00 - первого интервала, ARG_01 - второго интервала, и т.д.)
Далее, для того чтобы получить статистику за определенные интервалы (допустим T_From = 29.06.2010 14:00:00 T_To = 29.06.2010 15:00:00, и необходимо получить статистику за каждые 20 минут) нужно, во входное значение канала Call.LocalStatistic записать 3 (60 мин /20 мин). И в аргументах ARG_00, ARG_01, ARG_02 каналах Call.ChGroupReq записывается результат статистики за свой промежуток времени.
2) А теперь у нас появился один интересный вопрос, а именно: почему, когда мы мы выполняем запрос статистики за промежуток времени, который находится в будующем, мы вместо того чтобы получить 0 (или признак недостоверности как пример) получаем значение отличное от 0 (результат статистики - среднее за будующий промежуток времени - это реальное значение канала в момента запроса).
Как теперь определить, что пролученное значение статистики - это несуществующие данные в архиве, а не результат статистики за данный интревал?
3) И еще одна небольшая проблемка, профайлер "валится" когда пытаешься запросить статистику с 9:00:00(T_From) до 10:00:00(T_To), T_From писали в ARG_00 и T_To в ARG_01 канала Call.LocalStatistic.
Другие значения T_From и T_To в пределеах целых часов не вызывали "падения" профайлера.
Профайлер был запущен в 9:00.
Почему так получается? Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) все правильно 2) Канал LocalST берет срезы на начало и конец выборки. Т.к. эти срезы достоверны и соответствуют текущему значению, то Вы наблюдаете данные в канале.
Зачем брать несуществующий интервал?
3) Ситуация не воспроизводится.
Posted by Soyuz (Участник № / Member № 2028) on :
Нам сначала пришлось проверить Ваш метод получения статистики, манипулируя атрибутом "Параметр = " канала Call.LocalStatistic и подавая в его вход 1.
Убдедившись, что по указанному Вами методу мы не можем получить статистику за нужные нам интервалы, нам пришлось самим разбираться в тестовом проекте (спасибо за проект).
2) Объясните пожалуйста, как попределить, что интервал выборки является достоверным?
Мы запустили профайлер в 9:00, запрашиваем данные с 5:00 до 6:00 (в это время профайлер не работал, данных в архиве нет), но вместо того, чтобы выдать нулевой результат статистики, мы получаем реальное значение канала.
Есть реальная задача, а именно получать статистику по каналу каждый день в определенный промежуток времени (с 00:00:00 до 08:00:00), данную статистику нужно отображать на экране.
Предположим, что сегодня уже 9:00, а с 00:00:00 до 08:00:00 оборудование находилось в нерабочем состоянии, оператор видит вместо нулевой статистики за данный период, реальное значение канала.
Оператор в недоумении, текущее значение статистики превосходит его ожидания. Начинается суматоха ...
Как быть в таком случае???
3) мы можем выслать Вам проект и файл SIAD архива.
[ 08.07.2011, 19:14: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) В посте от 24-06-2010 15:23 было четко все расписано как работает тестовый проект. Если Вы считаете, что нужно было расписать подробнее, то просим прощения.
2) Есть две переменные
Arg_019 – диапазон, реально обнаруженный в архиве на основании заданного (T_FROM, T_TO);
Arg_008 – суммарное время достоверности значения канала;
Согласитесь, что делать выборку за будущие время нонсенс.
Если монитор у Вас был выключен какое-то время, то 1) в настройках узла нужно установить галочку "Запись в архивы среза по всем каналам" 2) После включения в архив запишутся значения о недостоверности на время отключения.
Таким образом те две переменные, которые описаны выше, будут Вам индицировать достоверность значения.
Если оборудование находилось в нерабочем состоянии, то признак недостоверности тоже должен быть.
3) Конечно, присылайте. hotline3@adastra.ru
Posted by Soyuz (Участник № / Member № 2028) on :
1) Если вы считаете, что пост от 24-06-2010 15:23 и пост от 30-06-2010 13:44 одинаковы, тогда вопросов больше нет.
2) Как быть с защитой от дурака?
3) Проект выслали 06-07-2010. Вы нашли причину, почему МРВ "валится"?
[ 08.07.2011, 19:15: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Вы дали инструкцию к каналу LocalStatistics, а мы давали к проекту.
2) Что Вы понимаете под корректной выборкой?
В тех примерах, которые Вы привели, выборка была корректна. Признак недостоверности ставить нельзя.
Как Вы предлагаете автоматически определять а) не было записей за этот период (прошедший) или б) Вы сделали выборку за будущее время или в) монитор был выключен или г) монитор был включен, а связь с прибором отсутствовала?
Мы должны это угадать?
0 - это тоже значение, а не адекватный ответ. Например, расход за какой-либо отрезок может быть равен 0, а Вы подумаете ошибка.
Анализировать достаточно просто, при этом Вы сами можете устанавливать критерии.
3) Не воспроизводится. Пробовали на 2 и 3 июля. И разные времена, учитывая, что может влиять разница во времени.
Posted by Soyuz (Участник № / Member № 2028) on :
1) Тестовый проект и должен был содержать пример как работать с LocalStatistics, чтобы получить статистику по каналу, вот основная задача тестового проекта.
2) Под корректной выборкой, подразумеваем такую выборку из базы данных, результат которой - однозначен.
Если в запрашиваемом диапазоне есть данные, то выдавать статистику именно по этим данным.
А если нет ни единой записи, то выдавать либо 0 (что есть адекватной реакцией) либо признак отсутствия данных.
Получается, что Трейс Мод в случае отсутствия данных в БД выдает в виде результата статистики реальное значение архивируемого канала.
Как нужно интерпретировать такой результат статистики? Это даже не 0, который насторожит. А значение, которое возможно близко к ожидаемому.
Вы считаете что в тех примерах которые мы привели, выборка и последующая статисстическая обработка были корректными?
Как так может быть, что в БД нет данных за этот период, а Трейс Мод выдает нам результат статистики - реальное значение канала, это корректно?
а,б,в,г - значения которые хранятся в БД должны иметь метку времени и значение, соответствующее этому моменту времени.
В том то и дело, что программное обеспечение, которое участвует в управлении технологическим процессом должно не угадывать, а давать однозначный ответ.
А то потом получается, что пользователь начинает угадывать, является ли результат статистики истинным или это реальное значения канала в момент запроса к БД.
Если анализировать просто, распишите пожалуйста как это сделать.
3) Извините, по ошибке отправили не тот архив. Выслали на hotline3@adastra.ru проект и архив.
Нужно сделать запрос (T_From) 30-06-2010 09:00:00 по (T_To) 30-06-2010 10:00:00, при этом с разбиением на три интервала (послать 3 во вход Call.LocalStatistic).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) и 3) Вот тут ошибочка произошла. Я не знаю, где мы в итоге друг друга не до поняли, но работает все по механизму указанному нами. Т.е. в параметр 32 + интервал, во входное значение 1.
Проект мы запускали, все работает. Релиз 6.06.3.
2) Давайте еще раз и по порядку.
за время с 8 до 9 часов значение канала не изменилось ни разу и было равно 20. Допустим это показатель расхода. Т.е. записей в архиве не было за этот период.
Какое значение Вам показывать в качестве максимального 0 или 20?
Естественно, Trace Mode берет срезы на начало и конец выборки и работает с ними.
Если у Вас за этот период были недостоверности, то надо анализировать Arg_019 и Arg_008.
Например, сравнением их с периодом выборки, и если, скажем, недостоверность более 30%, признавать это значение неверным или негодным для дальнейшего использования.
Выборки из архива за будущее время даже не будем обсуждать. Обычно такие выборки делаются программно и за заранее известные интервалы (прошедший час, сутки, смена и т.д.) и это ошибка проектировщика (а не Trace Mode), если выборка произошла за будущее время.
Posted by Soyuz (Участник № / Member № 2028) on :
1) 3) Не понятно, в чем Вы считаете произошла ошибочка?
Дело в том, что мы пробовали получить статистику по Вашему механизму, и у нас не получилось заполучить статистику так как нам нужно.
Вот что мы делали:
Запустили присланый Вами проект;
Проверили, что атрибут [34] "Параметр" канала Call#1 равен 37 ( 32 + 5, разделить диапазона выборки на интервалы по 20 минут и выдать статистику);
Во входное значение канала Call#1 послали 1;
К аргументам канала Call#1 привязаны каналы Call.ChGroupReq, смотрим аргументы канала Call.ChGroupReq который привязан к интегралу, но вместо того,чтобы получить значение инеграла за каждые 20 минут часа, получаем только одно значение интеграла;
Изменяли значение атрибута "Параметр", никакого влияния на количество интервалов не заметили, как было одно значение интеграла так и осталось.
Возвращаемся опять назад, что мы делаем не так?
Вы запускали наш последний проект, который мы Вам выслали? Пробовали получать статистику за 30 июня с 9 до 10 и посылать 3 во входное значение?
2) Нам стало понятно, Будем тогда сами надстраивать проверку корректности запроса.
[ 08.07.2011, 19:17: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
На всякий случай выслали Вам патч. Проект работает. На Вашем примере не падает.
Posted by Soyuz (Участник № / Member № 2028) on :
Разобрались. По видимому пролема были из-за того, что каким-то образом не правильно обновился TraceMode IDE 6.06.2 до 6.06.3. А из-за того, что не видно какая версия IDE, то отсюда и такие непонятки. Статистика извлекается по тому механизму, который Вы указали.
Спасибо.
Posted by titje (Участник № / Member № 4326) on :
Здравствуйте! Вышлите пожалуйста тестовый проект по этой теме.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отправлено. Внимание! Разработка примеров проектов по завякам пользователей не входит в обязанности службы технической поддержки и выполнятеся на добровольной основе. Спасибо за понимание!
Posted by SATER (Участник № / Member № 1414) on :
Здравствуйте. Вышлите, пожалуйста, тестовый проект и мне
а то у меня результаты появляются, но реальности не соответствуют. мне нужно среднее за один заданный час использую LocalStatistic, Parameter=32, на вход подаю 1 - при чем всегда надо часто подавать единицу, потому что канал CALL не реагирует и не выдает никаких результатов; пришлось дописывать программу, которая подает запрос пока нужный мне Arg_11 не изменится
я правильно понял что Arg_11 должен быть равен Arg_005 / ( Arg_012 / Период_опроса_привязанного_канала ) ? вот пример моих результатов: период = 5 сек Arg_005 = 79190 Arg_006 = 79190 Arg_011 = 238 Arg_012 = 790.79
делал экспорт архива и подсчитывал среднее в MS Excel - среднее вышло приблизительно равным значению, высчитаному по формуле Arg_005 / ( Arg_012 / Период ) -- 501.2
перепроверьте, пожалуйста, подсчет среднего. и обратите внимание на его целочисленность. меня настораживает, еще ниразу не получал дробное число или число, больше, чем 256 ________________________________ провел эксперимент. сделал выборку за час (c 12:00 до 13:00): Arg_003 = 6040 Arg_004 = 6590 Arg_005 = Arg_006 = 4553340 Arg_011 = 171 Arg_012 = 3599.6 Arg_020 = 0 Arg_027 = 27.12.2010 12:00:00 Arg_028 = 27.12.2010 13:00:00
теперь экспортирую архив в html. там нашел 721 значение с 12:00 до 13:00 их сумма = 4553390 среднее = 6315.381415
6315 = 1 1000 1010 1011 1010 1011 = 171
у всех числовых аргументов тип real, у даты - date_and_time ________________________________ еще заметил, что если к Arg_011 привязать канал типа Float, то среднее значение будет усечено до 1 байта. а если ничего не привязывать и на экран выводить значение Arg_011 путем привязки аргумента экрана к аргументу канала типа CALL, то среднее значение не будет усечено
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Здравствуйте. Подавать регулярно на вход канала 1 неправильно. Чтобы выяснить причину того, что канал "не реагирует" посмотрите значение атрибута 92,I2 канала. В него записывается код ошибки. Ваша формула не верна. Запись происходит при изменении значения канала значения, а не по времени. Вышлите Ваш проект на hotline3@adastra.ru.
Posted by SATER (Участник № / Member № 1414) on :
Из справки: "Атрибут 92, I2 индицирует число архивных записей, помещенных в канал." Разве это код ошибки? Подаю 1 на вход канала CALL, при этом атрибут 92 равен нулю. Подаю еще раз - молчит. Подаю единицу очередью одну за другой - появился результат, І2 = 732 - оно и понятно, 732 * 5сек = 1 час
Формула моя верна для тех случаев, когда значение канала постоянно меняется. У меня он привязан к секундам текущего времени - постоянно изменяется
Только что препроверил все на тестовом проекте - там все работает, но в архиве есть дублирование А в моем рабочем проекте Arg_011 обрезается.. проект выслал
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
По поводу 92 атрибута Вы правы. Код ошибки нужно смотреть в атрибуте 7,P. Надо заметить, что для корректной работы метода нельзя работать с данными за текущий час.
Posted by SATER (Участник № / Member № 1414) on :
Исправил ошибку: В проекте канал типа Float, в который записывается среднее значение, еще привязан к аргументу одной программы - этот аргумент с типом OUT и типом данных USINT. Так вот, среднее перестало усекаться, когда USINT поменял на REAL По-моему, в предыдущих версиях ТМ такого эффекта не было.
Выходит, тип аргумента влияет на тип канала в целом, а не только на тип числа, которое записывается в канал через аргумент?
Между прочим, даже если в теле программы этот аргумент не вспоминается вообще, но его тип OUT, тогда тип канала Float меняется. Если тип аргумента IN - не меняется
Posted by SATER (Участник № / Member № 1414) on :
Понял, почему не реагировал CALL.LocalStatistic: я подавал 1 на вход канала через программу на языке FBD - а там если не подается одно значение (например, 1), то подается другое (например, 0), тоесть программа преждевременно останавливала обработку канала. Отключение блока не поможет, буду переписывать на языке ST
Еще есть такая задача: В начале часа мне нужно достать среднее значение за предыдущий час по 7ми параметрам, которые архивируются в один СПАД. Для этого взял 7 каналов CALL.LocalStatistic. Когда все каналы обработаны, одним запросом посылаю все средние значения во внешнюю СУБД.
Так вот, можно ли обработать все 7 каналов одновременно или же нужно по очереди?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Каналы CALL.LocalStatistic нужно обрабатывать по очереди. И лучше всего это сделать при помощи rаналf CALL.AsyncCollection.
Но если Вам необходимо именно "достать среднее значение за предыдущий час по 7ми параметрам,", то можно обойтись и без архивных выборок: надо использовать 1 канал CALL.RT_Statistics.
Posted by SATER (Участник № / Member № 1414) on :
К сожалению, лучше всего тот вариант, в котором максимум делаешь сам, можешь следить за ходом выполнения, отлаживать.
CALL.AsyncCollection - хорошая идея, но не работает, а почему - не понятно. Подаю единицу на вход, она держится 180с и CALL стает недостоверным. Но если после 1 на CALL.AsyncCollection, еще подам единицу на CALL.LocalStatistic (это первый аргумент канала CALL.AC), то CALL.AC увидит, что CALL.LS запущен и после его обработки, попробует запустить следующий аргумент, но следующий CALL.LS тоже не реагирует. и т.д.
То же самое с CALL.RT_Statistics - как подал 1, так и держится. И не понятно, что при этом происходит, куда уходит 1
Так что буду програмно контролировать обработку CALL.LS
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Почтой отправлены примеры по обоим механизмам.
Posted by Сергей К. (Участник № / Member № 3297) on :
Posted by Сергей К. (Участник № / Member № 3297) on :
Здравствуйте! Вышлите пожалуйста тестовый проект по этой теме.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отправлено.
Posted by Сергей К. (Участник № / Member № 3297) on :
Можете прислать тестовый проект в котором будет наглядно видно как реализовать Call.LocalStatistic с Параметром = 32?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отправлено.
Posted by Сергей К. (Участник № / Member № 3297) on :
Спасибо! Очень помогло.
Posted by tsssm (Участник № / Member № 3564) on :
quote:Отправитель / Originally posted by AdAstra Technical Support: Почтой отправлены примеры по обоим механизмам.
Posted by SATER (Участник № / Member № 1414) on :
quote:Почтой отправлены примеры по обоим механизмам.
Вы сказали, что AsyncCollection_LocalStatistic.prj - фрагмент из реального пользовательского проекта. Может, это слишком урезаный фрагмент? Мне кажется, что Защелку каждого канала Call.LocalStatistic нужно самостоятельно обнулять - в "фрагменте" этого нету Первый раз Call.AsyncCollection нормально обработает все Call.LS, потому что их Защелки равны нулю, но после обработки Защелки остаются в единицах. При повторном запуске Call.AC он бегом обойдет все свои аргументы не дожидаясь конца фактической обработки каждого из них.
Или же просто сменить тип каждого Call.LS с Input (как в примере) на Ouput.
Я верно истолковал?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Еще раз проверил работу AsyncCollection в присланном Вам проекте AsyncCollection_LocalStatistic.prj. И в отсутствие архивов, и с реальными архивами пользователя. Все работает правильно. Ничего в проекте переделывать не надо. Он хотя и усечен, но только за счет функций, не имеющих отношения к AsyncCollection_LocalStatistic.
Почему Вас беспокоит атрибут "Защелка каждого канала Call.LocalStatistic"? Согласно документации "этот атрибут используется в каналах FLOAT и HEX16".
Posted by SATER (Участник № / Member № 1414) on :
Из справки. Раздел "Канал CALL.AsyncCollection" Если Параметр=0: - если некоторый целочисленный аргумент argN INPUT не привязан, его значение передается каналу CALL, привязанному к следующему за argN аргументу OUTPUT. Это необходимо, например, при каскадном запуске CALL.LocalStatistic. При этом проверяется b14 (бит 0 атрибута 46 [Защелка]);
В Вашем примере как раз этот случай. Когда Вы проверяли CALL.AsyncCollection, обращали внимание на Реальные значения каналов CALL.LS ? При первом запуске CALL.AC значения CALL.LS.R по очереди стают равными 1, после чего скидываются в нули. А при повторном запуске CALL.AC каналы CALL.LS обрабатываются по 2-3 шт. за раз - видно по их реальных значениях. Но, если перед повторным запуском CALL.AC поскидывать Защелки CALL.LS, то обработка происходит по очереди.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Видимо, разница в "наблюдениях" объясняется тем, что в нашем эксперименте использовался очень мощный ПК и время на выборку оказалось достаточно коротким. В Вашем случае надо привязку OUT-аргументов канала CALL.AsyncCollection осуществлять к атрибутам 120 (ACK) каналов Call.LocalStatistic.
Posted by An_tonick (Участник № / Member № 4942) on :
Здравствуйте! Вышлите пожалуйста тестовый проект по этой теме.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отправлено.
Posted by ddkel (Участник № / Member № 4120) on :
Добрый день! Как раз подобрался к теме статистической обработки, очень бы помог Ваш пример с CALL.LocalStatistic и CALL.AsyncCollection, вышлите, пожайлуста, тестовый проект.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Добрый день. Можно и мне выслать этот пример. Очень нужен. Спасибо.
Posted by Nikem (Участник № / Member № 5109) on :
Добрый день. Можно и мне отправить этот пример. Так и не смог разобраться со срезами. Спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
![[Улыбка / Smile]](smile.gif)