Такая проблема:
написана процедура на ВБА, исполнение которой занимает около 5-8 секунд, ее запуск из RSView32 провоцирует зависание ВБА, в процедуре идут вычисления с чтением/записью тагов. Процедура может выполнится несколько раз или пол раза . Проблема выскакивает, как я заметил, только на современных компьютерах с процессорами Pentium4 на шине 800 МГц, незавсимо от ОС (2000 sp4 и WinXP sp1) и версии RSView'a (6.2, 6.3, 7.0)
Кто-нить знает как решить этот вопрос?
Похожая проблема – только плюс к перечисленным вами операционкам мы для проверки устанавливали на 800-сот мегагерцовую платформу WinNT 4.0 и тоже наблюдаются нередкие «зависания» RSView при исполнении VBA. Нередкие – потому что несколько дней всё может работать нормально. То что система «подвисла» обнаруживается только при останове проекта, поскольку внешне дисплей оператора функционирует - все цифровые и аналоговые теги обновляются как обычно, но вот выйти из RSView – проблема: долго закрывается project manager, операционная система не отвечает на команды, остаётся только «жёсткая» перезагрузка. Причём если эксплуатировать систему без VBA - всё работает или остаётся ставить WinNT 4.0 + RSView на проверенные Pentium II или III .
Ну что-ж, проверил патчи в работе, один из них я ставил ранее.
Результат - все осталось по-прежнему.
Для себя нашел выход уже более года- это автоматичаеская перезагрузка при сбоях в работе ВБА, разок-другой в недельку случается. И минимум использования ВБА в проекте. Пока никаких других рабочих вариантов не придумал.
Просьба не терять тему и не скрывать от общественности противоядие, если вдруг ктонить найдет конечно.
P.S. Я всетаки склоняюсь к варианту с "железными" корнями этих проблем, хотя виновато конечно ПО, которое просто не со всеми железками нормально работает. Приведу свои аргументы: есть несколько компьютеров с мат платами Asus P4-P800 с процессорами Селерон 2 ГГц - все замечательно. Пришло новое оборудование, в том числе 2 компа с мат. платами Asus следующего поколения и процессорами P4 3ГГц. С обоими абсолютно одинаковая ситуация - ВБА глючит (на разных ОС и РС-Вьювах)... Пришел еще один комп, подобной конфигурации - WindowsXP вообще отказался ставится, после пробований, активного думания и перепрошивки нового биоса все встало и ВБА не глючит...
Вообще интересная ситуация. Меня вот посетили такие мысли: VBA - это интерпретатор, а не компилятор. Т.е. он должен по идее работать через WinAPI. Таким образом железо не должно иметь такого влияния на работу VBA.
С другой стороны по работе часто сталкивался, что языки программирования зачастую весьма чувствительны к региональным настройкам windows: формат даты, символ разделения целой /дробной части и т.п. Отсюда возникает два вопроса: какие региональные настройки Вы использвали и какие функции вызывали по тексту программы? А текст программы увидеть можно? Можете выложить на форум фрагмент "глючного" кода? Мы тогда тоже эксперимент на нашем железе поставим.
написана процедура на ВБА, исполнение которой занимает около 5-8 секунд, ее запуск из RSView32 провоцирует зависание ВБА,
В общем, дела обстоят так, производитель считает следующее:
1. Поскольку процесс VBA имеет наивысший приоритет, такие процедуры длиной 5-8 секунд просто-напросто блокируют ядро RSView32, перекрывая ему кислород, и ядро за это время умирает. Такие длинные процедуры просто так "в лоб", без учёта особенностей ядра реального времени, писать нельзя. Нужно давать ядру процессор и давать дышать.
Например, в длинном цикле нужно обязательно иметь, скажем, вместо
Код:
For i=0 To 10000
testText = testText & "Hallo (vb)Welt"
(ещё какой-то код)
Next
Что-то вроде
Код:
For i=0 To 10000
testText = testText & "Hallo (vb)Welt"
(ещё какой-то код)
DoEvents
Next
Или пишите вместо одной длинной процедуры кучу коротких. В общем. не забывайте, дамы и господа, что это не просто аппликация VBA под Windows, а аппликация, работающая в многозадачной среде реального времени.
2. Железо - с ним вот что: вспомните, старые игры, прекрасно работающие на старых компьютерах, на новых работать отказываются. Здесь возможна та же проблематика. RSView32 - довольно старый продукт, он имеет свой срок жизни, который уже находится не в стадии развития и расцвета.
Проблемы с установкой WindowsXP на новый компьютер мне, честно говоря, не кажутся связанными каким-то образом с Rockwell
For i=0 To 10000
testText = testText & "Hallo (vb)Welt"
(ещё какой-то код)
DoEvents
Next
Писал код с DoEvents еще раньше, эффекта нет. Как вы можете понять из предидущих постов, эта ошибка накапливается и может вылезти в любой процедуре VBA в любой момент времени, хоть сразу хоть через неделю, важно только то, что в ней идет работа с тэгами как на чтение, так и на запись. Код писать не буду, его накидать можно за минуту. Возьмите несколько сотен тагов и попробуйте помурыжить чтением/записью FLOAT значений. Например,в текущем проекте я качаю значения с SQL сервера и кидаю в примерно 400 тегов. Это действо должно происходить изредка, только когда оператору нужно посмтреть архивы. В другом проекте эти дела происходят во время расчета и записи в тэг начальной даты тренда. Дата тренда устанавливается ActiveX календарем, и наоборот, при перемещении тренда устанавливается дата в календарь.
oldDad писал(а):
Цитата:
1. Поскольку процесс VBA имеет наивысший приоритет, такие процедуры длиной 5-8 секунд просто-напросто блокируют ядро RSView32, перекрывая ему кислород, и ядро за это время умирает.
Не совсем согласен, RSView продолжает свою работу в совершенно нормальном режиме, проект не останвливается, но VBA уже не выполняется. Причем можно подумать что такое может возникать когда одна процедура еще не выполнилась, а проект пытается запустить еще одну одновременно, но такого не происходило, существенный перерыв между выполнениям процедур точно есть.
Насчет железа: провел вчера эксперимент - перепрошил свежий биос на компе, на котором были глюки с ВБА, на этот раз не помогло, все по прежнему. Но всеравно замечу, что такие ошибки возникают только на современных компах c P4...
Мы, конечно, ещё посоветуемся со специалистами Rockwell, но вчера мне сказали, что такое негативное явление им неизвестно. Нужно разбираться с программистами. Для этого было предложено написать им официальный запрос.
Было нечто подобное на одной из машин разработчиков. Решилось, как ни странно, простым отключением HyperThreading в BIOS.
P.S. Господин oldDad, неприятно видеть то, что мои вопросы на форуме игнорируются. Как разработчику, мне информация на форуме очень помогает. А так как официальный форум Rockwell закрыли, то больше консультироваться то и не с кем
Поговорил с Rockwell / Москва.
Ситуация выглядит так: для того, чтобы это явление было исследовано и было предложено какое-то решение, Rockwell просит официальное письмо с подробным описанием случая. Тогда будет официалньый повод обратиться к разработчикам-программистам с просьбой предложить решение.
Уважаемый Eraser, я написал Вам на форуме личное сообщение.
Было нечто подобное на одной из машин разработчиков. Решилось, как ни странно, простым отключением HyperThreading в BIOS.
Попробовал на той самой машине, у которой недавно прошивал БИОС, вроди стабильно стало работать, но окончательный результат не раньше чем через пару-тройку рабочих дней, т.е примерно в след. вторник.
Цитата:
Поговорил с Rockwell / Москва.
Ситуация выглядит так: для того, чтобы это явление было исследовано и было предложено какое-то решение, Rockwell просит официальное письмо с подробным описанием случая. Тогда будет официалньый повод обратиться к разработчикам-программистам с просьбой предложить решение.
Исходя из вышесказанного, письмо к Роквел пока должно подождать и нужно ли его будет писать вообще, если решение проблемы будет найдено. При необходимости сообшите кому, куда, от чьего имени, что написать и в какой форме.
Могу сказать что решение найдено, однозначно! Отключаем гипертрейдинг и нет глюков такого рода. Остается ждать когда будет реализована нормальная работа RSView32 на Intel или АМД форева
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.134 секунды