Добрый день, Подскажите, как в TraceMode определить реальное время цикла выполнения программы. Установлено 0.055 c, но реально работает несколько медленнее
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В окне "Компоненты" (см."Профайлер с поддержкой графических экранов") указаны заданный и реальный циклы пересчета базы каналов и счетчик превышений заданного цикла. Есть соответствующие системные и диагностические переменные (см."Каналы и системные переменные/Системные переменные"). Цикл 0.055 с для реального хорошо нагруженного проекта может оказаться недостаточным. И прежде всего это скажется на динамике графического интерфейса.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Здравствуйте. Помогите решить проблему слишком медленного обмена данными с Omron по Ethernet. Когда каналов не больше десяти, то все в порядке, но когда я создал их чуть больше ста, смена значения длится до 25 секунд. приоритеты потоков все Default, Период 10, Разрешение 0,055, периоды пересчета всех каналов 1 цикл CALC. загрузка процессора 50%. Кабель Ethernet проверенный. CLC (550)
Posted by Андрей В. (Участник № / Member № 2749) on :
Прежде всего увеличте период обмена для вашего проекта , у меня количество каналов за 150 при этом период установлен 30. Дальше проверте обмен пакетами между ПЛК и ТМ6 с помощью внешней программы и системных переменных ТМ , увидите как всё работает с середины.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Период обмена увеличивал до 30, толку никакого. Сетевая пропускная способность ПЛК с ТМ6 1-2%. Причем, запуская профайлер первые значения он сразу обновляет. Ваш тестовый пример с контроллером Omron имеет 650 каналов и работает у меня на периоде 10 без проблем.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Добрый день. Очень вас прошу, помогите разобраться с очень долгим обменом с контроллером (20 секунд на 100 каналов). Это ж ни в какие рамки не лезет, можно я вам проект скину на ваш ящик, посмотрите.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверьте по всем ли каналам у Вас достоверность. Так как в случае даже одной ошибки, скорость обмена сильно замедляется.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Проверил, у 7 каналов была недостоверность (номер устройства забыл выставить), исправил, время обмена сократилось, но все-равно составляет 4-5 секунды, поэтому проблема остается.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
К сожалению, у нас устройства нет, и более детально мы проверить ничего не можем. Попробуйте все-таки проверить каким-нибудь анализатором трафика (снифером) запросы и ответы. Возможно, эта проверка даст дополнительную информацию о задержках.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Да дело то тут не в устройстве, ваш тестовый пример (Ompon_Ethernet) работает как надо, хотя там 650 каналов, обновляются по 3 раза в секунду. Системный монитор показывает почти одинаковое количество переданных/полученных пакетов в тестовом примере и в моем проекте (16-18 пакетов/сек). А что означает цифра 5 в строке CLC=5(500)?
Posted by Валерий Багин (Участник № / Member № 3467) on :
Нашел 2 причины больших задержек. 1. Оказалось на обмен по IP у меня влияет количество подгрупп в группе Omron_Ip_Group. Для примера я просто создал одну Omron_Ip_Group и в ней 2 подгруппы с 500 источниками и задержки сразу исчезли. Но только если адреса идут по порядку.
2. Главная причина: ввод адресов не по порядку, или с инкрементом больше 2-х. В связи с этим просьба поддержке проверить действительное наличие этого недостатка в ТМ6 или как можно исправить ситуацию.
Такая же ситуация и со связью Host Link.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В некоторых драйверах есть такое понятие как групповой запрос. Т.е. Trace Mode получает значения нескольких параметров одним запросом.
Групповой запрос формируется при двух условиях:
1) Адреса в контроллере должны идти подряд
2) ID каналов должны возрастать
Естественно это "убыстряет" процесс обмена.
Posted by Валерий Багин (Участник № / Member № 3467) on :
А больше ничего нельзя сделать для ускорения процесса, чем как кучу ячеек на контроллере перемещать.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Увеличить скорость обмена, уменьшить таймауты. Это все, что можем предложить. Но вряд ли это применимо к данной ситуации.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Уважаемая поддержка, ТМ6 - SCADA система очень красивая и конкурентноспособная, но скорость обмена с контроллерами портит не только всю картину, но и сводит на нет все скоростные характеристики Ethernet и контроллеров, почему запросы на чтение/запись такие медленные, в элементарном проекте со всего 15 каналами обмен происходит уже не менее секунды, а что уж говорить про 1000-4000 каналов - один раз в 2 минуты? Неужели чтобы воспользоваться всеми преимуществами ТМ6, в контроллере необходимо поменять все адреса, чтобы они шли по порядку? Ужас... А потом еще тестировать уйму времени, вдруг конфликты какие. Должен же быть выход по проще.
Всего 15 запросов в секунду в век высоких технологий, смешно...
Я думаю данный продукт будет еще больше востребован, если вы хотя бы частично лишите ТМ6 этого огромного недостатка в ближайших релизах (хотя бы полсекунды на сотню каналов, чтоб не все адреса менять).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Чаще всего это зависит от способа формирования групповых запросов в протоколе контроллера. В частности, у контроллеров OMRON групповой запрос предполагает задание начального адреса переменной и количества переменных, что и означает, что эти переменные должны быть адресованы последовательно. Так что в данном случае другого варианта быть не может.
Posted by Валерий Багин (Участник № / Member № 3467) on :
Да про групповые запросы я понял, но они ооочень медленные (получается один запрос одну или группу ячеек за 70 мсек) и узким местом является ТМ6, так как SCADA от OMRON "Supervisor" позволяет чтение/запись до 300-400 ячеек, выбранных случайным образом, при минимальном времени полсекунды с этого же контроллера.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Возможно, что SCADA от OMRON "Supervisor" считывает групповыми запросами существенно большее количество переменных, чем Вы заказываете, но предъявляет Вам только те, которые Вы просите. Если Вам не жалко лишних каналов в Trace Mode, можно создать искусственные групповые запросы, в которых будут присутствовать и данные, которые Вы не будете использовать. При этом опросы большой группой будут происходить быстрее, чем несколькими малыми.
У нас проработан вариант организации группового запроса без увеличения количества каналов - использование канала CALL_ChGroupReq, привязанного к источнику с минимальным адресом. Объем группового запроса будет определяться количеством аргументов канала CALL_ChGroupReq, тип данных которых соответствует формату запрашиваемых переменных. Но в связи с отсутствием у нас контроллеров OWRON проверить и адаптировать этот механизм к соответствующему драйверу не представляется возможным.
Другой информации у нас нет.
Posted by Валерий Багин (Участник № / Member № 3467) on :
А можно по подробней про CALL_ChGroupReq: к аргументам привязывать каналы со случайными адресами и скорость не замедлится? А на текущие тренды как это будет выводится, или только на архивный?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
К аргументам можно привязывать каналы (атрибуты ВХОД) с произвольными ID. И уже эти каналы подключать к трендам, направлять на архивирование и пр.
Posted by Валерий Багин (Участник № / Member № 3467) on :
К аргументам CALL_ChGroupReq привязал входные значения каналов, а реальные подключал к экранам и тд., скорости не прибавилось, или надо аргументы CALL_ChGroupReq привязывать к экранам?
Posted by Валерий Багин (Участник № / Member № 3467) on :
Как мне вывести двойное слово на экран? С Каналом Double Float не получается...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. Ваша цитата: "Оказалось на обмен по IP у меня влияет количество подгрупп в группе Omron_Ip_Group. Для примера я просто создал одну Omron_Ip_Group и в ней 2 подгруппы с 500 источниками и задержки сразу исчезли. Но только если адреса идут по порядку." Я полагаю, что если Вы буете получать данные с помощью аналогичных групповых запросов CALL_ChGroupReq такого объема, но ненужные переменные из этих запросов не будете использовать, вы должны получить тот же эффект.
Можно привязывать к экранам и аргументы CALL_ChGroupReq, но это существенно не повляет на реактивность.
2. Двойное слово выводится на экран через аргумент с типом данных UDINT. А взять число можно из канала HEX32.
Posted by Валерий Багин (Участник № / Member № 3467) on :
quote:Отправитель / Originally posted by AdAstra Technical Support: 2. Двойное слово выводится на экран через аргумент с типом данных UDINT. А взять число можно из канала HEX32.
Пробовал и НЕХ32 и Double Float и тип данных UDINT и LREAL, результат одинарное слово...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Присылайте проект для анализа.
Posted by Валерий Багин (Участник № / Member № 3467) on :
проект отправлен.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Поставьте Формат Generic и %X.
Posted by Demus1 (Участник № / Member № 3844) on :
Здравствуйте. Есть ли рекомендации по выбору время цикла в настройках узла? Больше/меньше реального должно быть? Насколько?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вы сами должны определить необходимую реактивность МРВ по мониторингу и управлению, исходя из динамики процесса. По реактивности МРВ надо пытаться encfyfdkbdfnm цикл в настройках узла. Видимо, желательно иметь цикл не больше половины времени реакции. При этом надо учитывать, что асинхронные потоки обмена информацией с устройствами могут дополнительно снизить реактивность. При медленных каналах связи реактивность МРВ может целиком определяться именно каналами связи. Уменьшение цикла МРВ в этом случае не поможет.
Топик закрывается.
Posted by BUJH (Участник № / Member № 6737) on :
Здравствуйте! У меня опрос по RS-485 на 9600 происходит за 23 секунды. При этом половина каналов при работе МРВ указывают на недостоверность, тем не менее, значения этих переменных все же обновляются, один раз при старте, далее неизменны. Какие этому могут быть причины?
Posted by Nico (Участник № / Member № 5342) on :
недостовернось каналов связана с неправильным обменом по RS если устройство не отвечает то TM ждет ответа - > отсюда и большое время опроса
Posted by BUJH (Участник № / Member № 6737) on :
Не могу понять почему в ТМ не работает, если использовать в качестве Источники\приемники ОРС сервер, то обмен нормально происходит, все устройства отвечают, почему так?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Тема поста не соответствует теме топика. Откройте, пожалуйста, новый топик и изложите проблему более ясно: уточните структуру информационного обмена - как от устройств данные поступают в Trace Mode 6.
