Опишите пожалуйста в подробностях назначение следующих потоков монитора: 2 - прием по сети IP 3 - отсылка по сети IP 7 - MODBUS TCP/IP 11 - быстрые каналы
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
2 - прием данных при сетевом обмене 3 - отсылка данных при сетевом обмене 7 - обмен данными по Modbus TCP/IP 11 - при задании периода пересчета канал можно указать быстрый. Каналы для которых указана данная "единица измерения" обрабатываются в этом потоке.
Posted by Grigorovskih (Участник № / Member № 1915) on :
А почему быстрый? Он же ведь на 11 месте! Пробовали мы у каналов output устанавливать цикл пересчёта как быстрый, тогда они вообще перестали работать. Это ошибка или что то ещё надо установить для того чтоб эти каналы пересчитывались в этом потоке. Может Recalculation flag надо использовать?
Posted by Grigorovskih (Участник № / Member № 1915) on :
Да ещё. 1. В хелпе не понятно как всётаки можно настроить приорететы потоков, т.е. там даны только названия типов и всё, а описания нет. И как интерперетировать Default, в порядке ранга по цифрам из списка приведённого в хелпе? Но highest в списке под 12 номером... Дайте краткие разъяснения если не трудно. 2. И "@Calculate_Cycle" действительно показывает время в мс затрачиваемое монитором на операции основного потока? Мы когда отлаживали проект использовали эту переменную и ещё переменную @Calc_Loop, так, последняя действительно показывает в мс время цикла монитора а первая колеблется от 0 до нескольких единиц не более 10. И если, к примеру, время цикла монитора составляло около 100 мс, на графику (поток 17) уходило порядка 50 мс то на этом фоне "@Calculate_Cycle" равный 0-3мс иногда до 7мс выглядит не правдоподобно!
Posted by Grigorovskih (Участник № / Member № 1915) on :
Добавлю несколько слов по п.2. "...отлаживали проект..." - так вот когда мы отлаживали проект заметили, что есть критическое время цикла монитора для WIndows которое, как пример, для нашего случая составило 63 мс. Проверяли так, установили время 50 мс и реальное время цикла всё таки увеличилось и составило 63 мс, но, когда начали его увеличивать, до 100, 200, 500, 800 мс увы обнаружили тот факт, что реальное время всё же превышает на несколько (до 10) мс установленное. При чём когда цикл был 50 мс время на графику (переменная "@Graphics_Loop) "проскакивало" в пределах 31-47 мс, т.е. весь цикл, а время для первого потока "@Calculate_Cycle" 0-1 мс (тоже странно!), а когда цикл увеличили до 100 мс графика уменьшилась до 0-16 и время цикла колебалось 91-97, но периодически возрастало до 109-110 мс, причём это возрастание на 10 мс наблюдалось и при 500! Чем это объяснить?! В проекте оставили только порядка 30 каналов обмена по Ethernet c узлом embeddedRTM по ним ни одной недостоверности, всё остальное отключили и в такой ситуации плюс ко всему соответственно вылетают сообщения (в новом релизе 6.05.1) о превышении цикла! Господа, что нам с этим делать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
quote:Отправитель / Originally posted by Grigorovskih: А почему быстрый? Он же ведь на 11 месте! Пробовали мы у каналов output устанавливать цикл пересчёта как быстрый, тогда они вообще перестали работать. Это ошибка или что то ещё надо установить для того чтоб эти каналы пересчитывались в этом потоке. Может Recalculation flag надо использовать?
11 - это просто номер, никакого значения он не имеет.
Руководство пользователя, раздел "Период и фаза пересчета канала"
(9) быстрый – пересчет в потоке быстрые каналы (см. Потоки монитора ), равнозначен периоду в циклах. Период быстрый может быть задан для следующих каналов: ... каналов типа OUTPUT (не более четырех) обмена по RS (M-Link, MODBUS, t11 и т.п.).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
quote:Отправитель / Originally posted by Grigorovskih: Да ещё. 1. В хелпе не понятно как всётаки можно настроить приорететы потоков, т.е. там даны только названия типов и всё, а описания нет. И как интерперетировать Default, в порядке ранга по цифрам из списка приведённого в хелпе? Но highest в списке под 12 номером... Дайте краткие разъяснения если не трудно. 2. И "@Calculate_Cycle" действительно показывает время в мс затрачиваемое монитором на операции основного потока? Мы когда отлаживали проект использовали эту переменную и ещё переменную @Calc_Loop, так, последняя действительно показывает в мс время цикла монитора а первая колеблется от 0 до нескольких единиц не более 10. И если, к примеру, время цикла монитора составляло около 100 мс, на графику (поток 17) уходило порядка 50 мс то на этом фоне "@Calculate_Cycle" равный 0-3мс иногда до 7мс выглядит не правдоподобно!
1. Руководство пользователя, раздел "Задание параметров узла"
Вкладка ’Дополнительно’ редактора узла
В разделе "Приоритеты потоков" данной вкладки приоритеты потоков монитора, заданные по умолчанию, могут быть изменены (см. Потоки монитора ). Помните, что "Некорректная установка приоритетов потоков может привести к неработоспособности системы".
2. Выглядит очень даже правдоподобно.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Хелп мы читали, Вы цитируете всё от туда, а по сути? По факту каналы не пересчитываются если ставим цикл пересчёта как "быстрый" для двух каналов OUTPUT. Проверьте пожалуйста с реальной связю с "источники/приёмники". Но главное ответьте на два последних вопроса, по поводу времён цикла монитора, почему наблюдается такая картина?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
quote:Отправитель / Originally posted by Grigorovskih: Добавлю несколько слов по п.2. "...отлаживали проект..." - так вот когда мы отлаживали проект заметили, что есть критическое время цикла монитора для WIndows которое, как пример, для нашего случая составило 63 мс. Проверяли так, установили время 50 мс и реальное время цикла всё таки увеличилось и составило 63 мс, но, когда начали его увеличивать, до 100, 200, 500, 800 мс увы обнаружили тот факт, что реальное время всё же превышает на несколько (до 10) мс установленное. При чём когда цикл был 50 мс время на графику (переменная "@Graphics_Loop) "проскакивало" в пределах 31-47 мс, т.е. весь цикл, а время для первого потока "@Calculate_Cycle" 0-1 мс (тоже странно!), а когда цикл увеличили до 100 мс графика уменьшилась до 0-16 и время цикла колебалось 91-97, но периодически возрастало до 109-110 мс, причём это возрастание на 10 мс наблюдалось и при 500! Чем это объяснить?! В проекте оставили только порядка 30 каналов обмена по Ethernet c узлом embeddedRTM по ним ни одной недостоверности, всё остальное отключили и в такой ситуации плюс ко всему соответственно вылетают сообщения (в новом релизе 6.05.1) о превышении цикла! Господа, что нам с этим делать?
Диагностическая переменная @Calc_Loop показывает реальное время цикла монитора, оно не может быть меньше заданного. А системная переменная @Calculate_Cycle показывает реальное время обработки только основного потока.
Posted by Grigorovskih (Участник № / Member № 1915) on :
"Диагностическая переменная @Calc_Loop показывает реальное время цикла монитора, оно не может быть меньше заданного." Если так, то зачем Вы сделали в релизе 6.05.1 выдачу сообщения системой о превышении цикла монитора? Вы ответьте пожалуйста на поставленные вопросы, хелп у нас есть то что Вы пишите мы видели и там!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
quote: Хелп мы читали, Вы цитируете всё от туда, а по сути? По факту каналы не пересчитываются если ставим цикл пересчёта как "быстрый" для двух каналов OUTPUT. Проверьте пожалуйста с реальной связю с "источники/приёмники". Но главное ответьте на два последних вопроса, по поводу времён цикла монитора, почему наблюдается такая картина?
Мы цитируем хэлп потому, что все работает так как там описано. Если есть ошибки, тогда мы говорим, что это ошибка. Проверяли на Modbus, каналы типа Output с периодом пересчета быстрый работают нормально.
quote:"Диагностическая переменная @Calc_Loop показывает реальное время цикла монитора, оно не может быть меньше заданного." Если так, то зачем Вы сделали в релизе 6.05.1 выдачу сообщения системой о превышении цикла монитора?
Если проект работает нормально, то реальное время цикла монитора должно быть равно заданному. Предупреждения появляются, если идет превышение заданного времени, следовательно проект перегружен.
Posted by PMA (Участник № / Member № 1387) on :
Добрый день ! Уважаемая группа поддержки, хотелось бы всё таки узнать, какой приоритет скрывается под синонимом Default, для всех потоков, к которым есть доступ.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Default - это значение установленное по умолчанию в Trace Mode 6, для разных потоков оно разное. Это не какой-то стандартный приоритет. Когда Вы ставите Default, то соглашаетесь с нашими настройками приоритетов.
Posted by PMA (Участник № / Member № 1387) on :
Я каr раз и хочу узнать, какие приоритеты потоков у вас стоят по Default.
Posted by PMA (Участник № / Member № 1387) on :
Таблицу приоритетов потоков по умолчанию, представьте пожалуйста.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы не рекомендуем менять настройки приоритета потоков и представить Вам таблицу не можем
