Господа, при установке новой версии ТМ6.05.1 (базовой) и запуске проекта на выполнение получаю периодически (период 10") всплывающее окно предупреждения с текстом "Calc loops is big" и кнопкой ОК. Об чем это говорит, если не секрет, и как с ним бороться!? С уважением, M@V.
Posted by M@V (Участник № / Member № 1800) on :
Время реакции интерфейса и системы ощутимо упало (железо платформы осталось то-же). Возможно, есть Ваши рекомендации по применению определенных видеокарт (но мне кажется, что проблема не в этом)? У меня интегрированный адаптер Intel(R) Q965/Q963 Express Chipset Family, на нем без проблем шел ТМ6.05. С уважением, M@V.
Posted by M@V (Участник № / Member № 1800) on :
Усек, "Calc loops is big" вываливается в случае нарушения связи ODBC источника с ядром базы данных(БД была не запущена). Но причем здесь "Calc loops is big"??? Правда ТМ6.05 аккуратно об нарушении связи умалчивал - это Ваша задумка? С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В релизе 6.05.1 существенно расширена встроенная система диагностики. Отдельные компоненты интерфейса связи с БД имеют режим online. Отсутствие соответствующих ответов диагностируется по таймауту, что и приводит к увеличению реального цикла пересчета базы каналов по сравнению с заданным. Принудительная выдача сообщений о нарушениях дает Вам направление для корректировки проекта или модификации его отладочной версии. "Время реакции интерфейса и системы ощутимо упало ..." - возможно, "время увеличилось"? Если бы действительно "упало", Вы бы радовались. Пришлите, пожалуйста, для анализа проект с комментариями, как Вы оцениваете время реакции.
Posted by M@V (Участник № / Member № 1800) on :
Да, Вы правы, время реакции увеличивается и именно тогда, когда нарушается связь с внешней БД. А по сему четыре вопроса: 1. Я в проекте, в случае нарушения связи с БД, должен прекратить обращение к оной с помощью средств проекта, дабы периодически не получать сообщение? 2. Если да, то где мне выловить это нарушение и потом что делать: а)отключить посылку номера запроса в вызывающий канал? б) выключить канал? в) отключить от источника или еще что? 3. Могу ли я управлять тайм-аутом интерфейса связи с БД? 3. И при чем здесь "Calc loops is big" ведь это сообщение - сплошное заблуждение??? С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Появление неоправданных задержек в процедурах реального времени может существенно увеличить цикл обработки базы каналов, что приведет к существенному снижению реактивности системы и, вполне возможно, к перегрузке процессора со всеми вытекающими последствиями. Поэтому надо исключать критические ситуации не для того, "чтобы не получать сообщение", а для того чтобы обеспечить необходимые динамические характеристики системы. Прервать поток SQL-запросов можно любым доступным способом. Диагностировать качество выполнения запросов можно по значению канала (сбрасывается по завершении запроса) и по атрибутам 87 и 92 (см."Выполнение SQL-запросов в реальном времени"). Таймаутом интерфейса с БД управлять нельзя. Сообщение "Calc loops is big" отражает обобщенный практический эффект. Это действительно говорит об увеличении реального цикла обработки базы каналов по сравнению с заданным в проекте.
Posted by M@V (Участник № / Member № 1800) on :
Выдержка из HELP: "Если SQL-запрос по каким-либо причинам выполнить невозможно, то по истечении 600 секунд с момента инициализации запроса каналу CALL устанавливается признак аппаратной недостоверности." Уточните, действительно ли 600 секунд, ведь до определения сбоя коннекта, ТМ6.5.01 успеет оператору выбросить шестдесят окон "Calc loops is big", это напоминает некорректно написанную программу в СИ++ BUILDER при нарушении защиты памяти. Согласитесь, в русском интерфейсе "Превышен цикл пересчета системы" звучит более понятно!! Я не представляю если бы это творилось при нарушении связи любого канала системы! Для птички "Отладочный режим работы" я с таким вариантом согласен. С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы введем ключ запуска МРВ, который отменяет выдачу сообщений. Однако это не снимает проблемы фактического превышения цикла. Надо работать над проектом для устранения этой коллизии.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемый модератор, извините за назойливость, но Вы полностью не ответили на мои вопросы, а у меня возникли новые: 1. Я так понимаю, что ключ будет касаться НЕ отладочного монитора, а в отладочном я буду получать сообщения "Calc loops is big" в течении 600 секунд до возможности принятия решения о перекоммутации канала связи с БД? С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ключ будет касаться всех МРВ - отладочного и не отладочного. Кроме того алгоритм выдачи сообщений будет изменен - сообщения будут выдаваться по нелинейному интегральному критерию. После выдачи двух сообщений (первое - после 10 последовательных, без перерыва, превышений, второе - после непрерывных превышений в течение 1 минуты) будет вводиться ожидание длительной паузы отсутствия превышений. Новые сообщения будут формироваться по тому же алгоритму.
Posted by M@V (Участник № / Member № 1800) on :
День добрый господа, я так понял, что решение о перекоммутации канала связи с БД необходимо будет принимать по НЕ сбросу в 0 канала запроса к БД? С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Или по атрибутам 87 и 92.
Posted by M@V (Участник № / Member № 1800) on :
Согласно Вашего posted 02-11-2007 10:04 это будет заплатка или скорректированный релиз ТМ6.05.1 или новый релиз. И когда это ожидать? С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это будет патч (пакет файлов для замены). Срок пока не определен. Видимо, в этом месяце.
Posted by Алекс К (Участник № / Member № 1337) on :
В связи с с корекцмей проекта версии 6.05 в версии 6.05.1 и естественно появления Ovestress cpu, возможен ли возврат проекта в версию 6.05? 1. Корректна ли работа проекта ред. в версии 6.05.1 на DOC МРВ+ 6.05? 2. Или его обяз. надо пересохранить для МРВ в версии 6.05?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Графическая база проекта релиза 6.05.1 не будет считана в релизе 6.05. Сообщение о перегрузках появилось не из-за перехода в релиз 6.05.1. В релизе 6.05.1 введена достаточно полная диагностика. По ее результатам надо принимать меры по разгрузке проекта, а не возвращаться в предыдущий релиз.
Posted by Алекс К (Участник № / Member № 1337) on :
Может быть она и достаточно полная для Вас, но без нормального описания не дает никакой помощи разработчику.(А ведь SCADA вообще теоритически расчитана на технолога - хотел бы япосмотреть как он по этому диагн. окну разгружает проект). Есть сроки разработки -и они не бесконечные. Поэтому и приходится возвращаться в предыдущий релиз. Неужели так долго выпустить этот патч?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы принимаем меры для ускорения выпуска патча.
Posted by Vjam (Участник № / Member № 2261) on :
Работал в 6.05. поставил 6.05.1 и все графические объекты пропали. Возможно ли их восстановить? или возвращаться в 6.05? Нехочется рисовать по новой
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Попробуйте запустить демо-проекты, которые находятся в папке DEMO.
Posted by Vjam (Участник № / Member № 2261) on :
имеется в виду в проектах которые были созданы под 6.05. Может как-то их надо конвертировать?
Posted by Vjam (Участник № / Member № 2261) on :
Переустановил и все заработало
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
Здравствуйте, уважаемая техподдержа. Подскажите каким образом можно проверить работу ТМ6 базовой версии с контроллером через GSM канал? В узле RTM1 в настройках модема устанавливаю номер телефона и строку инициализации, но не нашел каким образом настроить номер телефона на удаленном контроллере. Заранее благодарен.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Настройка номера телефона проводится в исполнительном модуле МикроМРВ, но МикроМРВ базового формата не существует. Поэтому проверить работу Тrace Мode 6 базовой версии с контроллером через GSM канал не получится.
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
Спасибо. Каким образом тогда лучше поступить, чтобы все таки проверить сможет ли контроллер общаться по GSM. или есть только один выход: покупать МРВ+GSM?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В Trace Mode пока реализована передача по GSM только для контроллеров WinCon. Для проверки не обязательно покупать МРВ+GSM, можно проверить и с помощью профайлера ИС профессиональной версии и МикроМРВ
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
Вы написали "В Trace Mode пока реализована передача по GSM только для контроллеров WinCon". Это значит что другие контроллеры в МРВ+GSM я не смогу связать или я не правильно Вас понял ?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да, другие контроллеры получать данные по GSM не будут.
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
Спасибо. Подскажите тогда возможна ли работа следующей системы: на данный момент TM 6 получает сигналы от частотного преобразователя Control techniques с помощью OPC сервера по проводам. Возможно ли замена проводов на GSM модемы, чтобы система продолжила работу (в таком случае что для этого необходимо)? Заранее благодарен.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Протокол OPC в Trace Mode не передается по GSM.
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
то есть я так понял, что система будет не работоспособна?
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
...OPC сервер будет работать на том же компьютере что и ТМ 6
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Если Вы хотите связать контроллер с OPC сервером, то Trace Mode к этому отношения вообще не имеет.
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
OPC сервер соединяет на программном уровне прибор (контроллер) и scada систему (trace mode не исключение). opc сервер я использую в узле источники/приемники для tm6...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
У Вас есть два разных соединения: 1) контроллер - OPC сервер 2) OPC сервер - Trace Mode.
Так вот, в первом соединении Trace Mode не участвует и ничего о нем не знает.
А соединение №2 у Вас осуществляется по внутренним каналам, т.к. OPC сервер и Trace Mode установлены на одном компьютере.
Posted by Дмитрий Силованов (Участник № / Member № 2819) on :
Спасибо
Posted by M@V (Участник № / Member № 1800) on :
Я в замешательстве, у меня перестало выпадать сообщение "Calc loops is big" в случае нарушения коннекта с БД! Posted by M@V (Участник № / Member № 1800) on :
День добрый господа, может и Вам эта информация будет полезна: "Calc loops is big" появляется в случае прописывания хоста в строке подключения, даже локального - DRIVER={Firebird/InterBase(r) driver}; Dbname=localhost:D:\AFD\DBTRM.GDB и отсутствии запущеного ядра базы. Не появляется при такой строке подключения - DRIVER={Firebird/InterBase(r) driver}; Dbname=D:\AFD\DBTRM.GDB. С уважением, M@V. --------------------- Это еще раз доказывает, что SQL поток не такой уж независимый в ТМ6. Я не генерирую следующий запрос до тех пор, пока не увижу завершение предыдущего (сброс в 0 канала CALL).
Posted by M@V (Участник № / Member № 1800) on :
Скорее это связано с тем, что в работу включаются дополнительные тайм-ауты?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это видимо связано, кроме тайм-аутов, еще и с различием в операциях коннект-дисконнект.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые, я так и не понял, патч уже есть для ТМ6.05.1, или еще не готов??? С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Патч для Trace Mode 6.05.1 не выходил. Более подробно об этом можно узнать, написав на адрес adastra@adastra.ru
Posted by Андрей В. (Участник № / Member № 2749) on :
Доброго время суток уважаемые господа. Столкнулся я сегодня с небольшой проблемкой . Настраивал свой проект для обмена по локальной сети , присвоил некоторым каналам атрибут 60 (в сеть) как 1. После запуска проекта на исполнение вылазит интересна ошыбка " Copia s1" , зависает профайлер. Вернул все настройки в исходное состояние , запустил проект и наблюдал следующую ситуаццию : при посылки значения по одному каналу (контроллер А) , данные записывались и отображались уже в другом ( контроллер В). Как такое могло случиться , ведь привязки никто не менял , может ли атрибут 60 вызвать такие последствия.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пришлите свой проект на hotline3@adastra.ru.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Уважаемые господа! Топик представляет собой эклектику из разных тем. Соблюдайте, пожалуйста, тематическую определенность. Топик закрываю.
![[Недоумение / Confused]](confused.gif)