Ситуация следующая. Разрабатываю проект в профессиональной ТМ 6.10.2 на Windows 8. По мере усложнения проекта все менее устойчиво он стал сохраняться для МРВ: Windows требовала закрытия или отладки приложения. В один прекрасный момент, после какой-то плевой операции, проект окончательно перестал сохраняться для МРВ на Windows 8 и Windows 10 (последняя просто выгружает ИС). Cбой возникает на каком-то определенном месте при компиляции узла RTM. При этом Windows XP и Windows 7 позволяют успешно сохранять проект для МРВ. Примечательно, что после неудачной попытки сохранения для МРВ в Windows 8 в дальнейшем ИС перестает уже просто сохранять даже простейшие проекты (возникает фатальная ошибка): приходится перезагружать ОС.
Вообще, работая в свое время с базовой версией, обнаружил, что добавление в проект и настройка шаблонов связи с СУБД решительно снижает устойчивость системы. Именно после конфигурации одного из шаблонов связи с СУБД проект может перестать адекватно работать или запускаться в профайлере, сохраняться для МРВ. Причем до этого шаблон может полностью функционировать, достодолжно взаимодействуя с БД. Совпадение? -- нет, ведь именно клик по одному из шаблонов связи с СУБД в ИС обнаруживает, где собака порылась: появляется окно ошибки. Удаление "испорченного" шаблона не всегда позволяет восстановить работоспособность проекта: иногда, как я понимаю, проект просто критически повреждается и никакие танцы с бубном не приводят к его излечению. Так я загубил несколько проектов в базовой версии ИС, благо пробных. И всегда проблема была в шаблонах связи с СУБД, причем всякий раз функционально абсолютно различных.
Наша версия на весь этот счет, это то, что ТМ при сохранении для МРВ во время компиляции шаблонов связи с СУБД пытается вершить какие-то "мутки" (по-другому не назовешь) с этой самой СУБД, что и приводит к плачевным результатам. Сейчас приходится работать на одной машине под Win 8, а потом сохранять проект на другой под Win XP не чаще одного раза в день. Представьте, насколько это неудобно. Надеюсь на вашу помощь.
PS. СУБД, где проект перестал сохраняться для МРВ -- MS SQL Server 2014, а там, где в базовой версии проекты критически повреждались -- MS SQL Server 2008, если это чем-то поможет. На Win 7, где проект все-таки сохраняется БД настроена точно таким же образом, как и на Win 8.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Описанная Вами проблема может возникать при использовании в имени каналов символов «№» и тире «—». Использование этих символов в программах, иных шаблонах, именах каналов, атрибутах каналов, комментариях в ОС Windows 8.1 и 10 приводит к падению инструментальной среды и может приводить к некорректной работе исполнительных модулей. Рекомендуем отказаться от использования этих символов, заменив на «N» и дефис «-». Связано это с внесенными Microsoft изменениями в ОС, начиная с 8.1. К сожалению, в текущей версии TRACE MODE исправить это не представляется возможным.
Posted by Alexander_ (Участник № / Member № 7778) on :
Простите, забыл сказать, что фишка про "№" мне известна и данная причина не может быть источником проблемы. Так, при употреблении символа номера ИС просто вылетает через несколько секунд или при попытке сохранения. Про тире не знал, но его в проекте быть не может, т.к. весь текст набран в ТМ.
Скажите, пожалуйста, возможна ли другая причина подобного поведения?
А что со второй частью вопроса? Ошибками, возникающими в проекте (на Windows XP) через некоторое время после настройки шаблона связи с СУБД? Не могут ли это быть звенья одной цепи?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1. В процессе компиляции проекта ("Сохранения для МРВ") IDE не совершает никаких процедур с БД.
2. По работе в реальном времени. 2.1. Все каналы вызова SQL-шаблонов переведите в поток IDLE (задайте в настройках периода обработки каналов "Единица измерения"="цикл IDLE") (см. документацию). 2.2. Подключите трассировщик ODBC-обмена, по его протоколу убедитесь в отсутствии ошибок обмена. 2.3. Задайте в файле конфигурации узла *.cnf отладочный ключ DEBUGON=F0044400 Прогоните узел в реальном времени при включенном трассировщике ODBC-обмена до нарушения функционирования МРВ. В профайлерном протоколе будет диагностическая информация по потокам и SQL-обмену.
3. Присылайте на адрес техподдержки - файл проекта, - папку проекта после неудачной компиляции (под W'10), - папку проекта после корректной компиляции (под W'XP) и прогона с указанным отладочным ключом по п.2.3 и протокол трассировщика.
Posted by Alexander_ (Участник № / Member № 7778) on :
Здравствуйте. Начал выполнять подготовку файлов для отправки на экспертизу и внезапно компиляция проекта прошла успешно. Далее выяснилось, что поводом для неудачных компиляций разрабатываемого проекта под Win 8.1, 10 служит наличие в момент компиляции в любом из USB-портов ПК флеш-накопителя. Тестировалось по-крайней мере четыре флеш-карты и всегда при этом происходил срыв компиляции. Теперь компилируем без флешек и по многу раз всё проходит гладко. Лишь изредка TM IDE вылетает словно сама собой, и иногда RTM - в момент запуска проекта.
В связи с вновь выявленными обстоятельствами хотел бы еще раз осведомиться, имеет ли место проблема или подобная работа ТМ является штатной. Если проблема есть, то в чем может быть причина? На предмет символа номера и тире проект исследовался неоднократно - их там доподлинно не существует. Спасибо.
P.S. Проблема с шаблонами связи с СУБД действительно была, но зафиксирована лишь на базовой версии под Win XP в экспериментальных проектах и пока не горит. В том проекте, где сбоит сохранение для МРВ, все шаблоны, благо, ведут себя относительно хорошо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы пытались воспроизвести подобную ситуацию на своих ПК, но никакой связи с наличием флэш-накопителя и процедурой компиляции проекта не обнаружили. От пользователей таких сообщений мы также не получали.
Желательно получить (на адрес техподдержки hotline@adastra.ru) дополнительную информацию, по которой мы могли бы воспроизвести ситуацию: - проект *.prj и папки проекта в вариантах успешной и неудачной процедуры компиляции с скриншотами сообщения, сопровождающего "срыв компиляции", - характеристики и структуру ОС с правами пользователя и локализацией размещения IDE и проекта, - физическую структуру USB-портов и средств подключения к ним HASP-ключей и другого оборудования.
Без воспроизведения описанной ситуации на наших стендах провести убедительный анализ и выработать эффективные рекомендации не представляется возможным.
Posted by Alexander_ (Участник № / Member № 7778) on :
И снова здравствуйте! Спешу сообщить, как мне кажется, важное замечание по проблеме вылета при сохранении для МРВ.
До некоторой поры стиль работы сохранялся таким, как описано в первом абзаце предыдущего сообщения. Однако в последние недели объем скомпилированных проектов за счет новой графики немного возрос (в пару раз) и этого оказалось достаточно, чтобы в один момент ситуация начала повторяться вновь, причем теперь уже не надо было никаких флешек: проект просто не сохранялся для МРВ, а при работе в ИС регулярно вылетал. Начал ломать голову и обнаружил, что проблема возникает тогда и только тогда, когда HASP-ключ инструментальной системы подключается к одному из передних портов USB. Там стоят две панели: одна 2xUSB с микрофонным и линейным входом, другая - USB 2.0 с еще какой-то дичью (не припомню, какой именно). Видимо, это касается и ключа для МРВ.
Сейчас все ключи ставлю только в задние порты. Боле подобных замечаний не обнаружил.
Прошу дать комментарии, ибо стоит вопрос о необходимости включения соответствующего пункта в руководство пользователя к разработанному SCADA-проекту. Обращаю внимание, что в очередной раз подтверждена зависимость частоты возникновения проблемы от объема проекта (существенно нелинейная).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ключ HASP не участвует в процессе компиляции. Без него инструментальная система просто не запустится или перестанет работать, если его вытащить в процессе работы.
Описание очень напоминает аппаратные проблемы с ПК. Изменение конфигурации устройств, влияющее на работу ПК напоминает проблему с питанием. проверьте корректно ли работает БП, подается ли нужное напряжение на компоненты ПК. Могут быть проблемы с памятью, жестким диском, проверьте, не вздуты ли конденсаторы на платах. Запустите среду на другом, заведомо исправном ПК.
