Зарегистрирован: May 14, 2005 Сообщения: 290 Рейтинг: +9/-0 Откуда: г.Самара
Добавлено: Ср 04 Мар, 2009 10:47:55 Заголовок сообщения:
Цитата:
, и реально попытались проверить мою проблему
Это что значит "попытался"? Я Вам что, пацан, который "пытается" ... (вырезано цензурой)?
Цитата:
, а просто утверждать … ну, это не убедительно.
С каких это пор на сайте мои утверждения являются голословными?
Проблемы как не было, так и нет.
Цитата:
, для моей задачи ВАЖНО не перегружать проект!
Разве я что-то говорил о перезагрузке проекта? С 1 по 6 пункты в Runtime.
Цитата:
, как все таки этих КОШЕК готовить?
Из-за кризиса у меня столько свободного времени, что девать его некуда.
Поэтому открою тайну, скрытую за 7 печатями:
Код:
DIM КОШКИ as VBAforRSView32
Sub РецептПриготовленияКОШЕК()
1. Занять рабочее место.
2. Включить компьютер.
3. Загрузить RSView32 Works и достать КОШЕК.
4. Готовить КОШЕК.
5. Каждый час делать перерыв (перекур, чаепитие, пивопотребление - на Ваш вкус).
6. Повторять, начиная с пункта 4 до тех пор, пока КОШКИ не будут приготовлены.
7. Проверить КОШЕК на вкус.
8. Досолить КОШЕК.
9. Каждый час делать перерыв (перекур, чаепитие, пивопотребление - на Ваш вкус).
10. Повторять, начиная с пункта 7 до тех пор, пока КОШКИ не будут вкусные.
11. Выключить компьютер.
12. Освободить рабочее место.
End Sub
Зарегистрирован: Feb 18, 2009 Сообщения: 9 Рейтинг: +0/-0
Добавлено: Ср 04 Мар, 2009 11:36:16 Заголовок сообщения:
DIMIOKS - Я Вам тоже не пацан, и прошу Вас не дерзить и не превращать форум в балаган, поскольку не можете дать грамотно ответ, я всего лишь просил простой конструктивный ответ, на мой простой вопрос: “Что я делаю не так?”, а рецепты про КОШЕК оставьте при себе, вижу, что Вы к ним не равнодушны
PS:
Кстати, выдергивать фразы из контекста, и интерпретировать их в силу своего развития, большого ума не надо, таких "знатоков" я уже встречал…
Зарегистрирован: May 14, 2005 Сообщения: 290 Рейтинг: +9/-0 Откуда: г.Самара
Добавлено: Ср 04 Мар, 2009 15:46:25 Заголовок сообщения:
Уважаемый Scaut, если Вы мои выражения сочли за дерзость, то я просто завидую Вам, т.к. Вы, как видно, еще не встречались напрямую с подобными вещами.
Насчет балагана: балаган - это заявления о недееспособности инструментов RSView32. Все остальное - следствие Ваших безосновательных утверждений.
Насчет конструктива: Вам уже достаточно многое объяснили, я в том числе дал последовательность действий (команд), которые приводят к решению задачи. Как видно, не по зубам орешек. Рискну еще более упростить пример:
Код:
Sub CreatTagDig()
Dim NewTag As Tag
Dim sName As String
sName = "aaa"
Set NewTag = gTagDb.CreateTag(sName, roTagTypeDigital)
Sub ChTagTrue()
gTagDb.GetTag("aaa").Value = 1
End Sub
Sub ChTagFalse()
gTagDb.GetTag("aaa").Value = 0
End Sub
Sub ChDescriptAAA()
gTagDb.GetTag("aaa").Description = "AAA"
gTagDb.GetTag("aaa").WriteConfiguration
End Sub
Sub ChDescriptBBB()
gTagDb.GetTag("aaa").Description = "BBB"
gTagDb.GetTag("aaa").WriteConfiguration
End Sub
Все операции с тегом написаны на VBA. Перегрузка проекта не требуется. Все динамически изменяемые дескрипторы также будут отображены в AlarmLogViewer.
Думаю, все уже сказано, пора завершать эту тему.
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Ср 04 Мар, 2009 18:25:06 Заголовок сообщения:
Уважаемый DIMIOKS,
я тоже, как и Вы, думаю, что данная тема исчерпана. Пример кода совершенно корректен и понятен.
Уважаемый Scout,
я думаю, что Вам даны исчерпывающие объяснения и приведёт алгоритм и код, которые доказывают, что всё работает. Вы можете проверить этот код сами.
Если у Вас не работает Ваш собственный код - ищите, пожалуйста, причину у себя, в своей системе. RSView32 тут IMHO совершенно ни при чём.
Зарегистрирован: Feb 18, 2009 Сообщения: 9 Рейтинг: +0/-0
Добавлено: Чт 05 Мар, 2009 5:01:45 Заголовок сообщения:
Уважаемый DIMIOKS, я рад, что Ваши сообщения, становятся более содержательными и конструктивными.
Хочу сразу еще раз поправиться (поскольку на форуме от Ср 04 Мар, 2009 10:46:49 я уже исправлялся), что в сообщении от Вт 03 Мар, 2009 10:43:57 я опечатался, и теперь вместо AlarmLogViewer следует читать AlarmSummary, приношу извинения.
Итак, вы приводите замечательный исходный код, но давайте, применим к Вашей методике, вместо AlarmLogViewer, другой замечательный инструмент RSView32 - Alarm Summary: к примеру, создадим новый экран, сделаем этот экран стартовым в проекте, поместим на него ActiveX AlarmSummary, а также создадим несколько кнопок и привяжем к их событиям процедуры Вашего VBA исходника. ВСЕ ЭТИ ДЕЙСТВИЯ ВАЖНЫ ДЛЯ ПОНИМАНИЯ ПРОБЛЕМЫ. После этого запустим проект, нажимая кнопки, исполним Ваш исходный код, и посмотрим, что будет появляться в журнале алармов - AlarmSummary? … на сегодняшний момент мне не удалось в AlarmSummary получить адекватное Description тега, поэтому данная проблема для МЕНЯ до сих пор НЕ РЕШЕНА. Это обстоятельство вынудило меня написать свой ActiveX компонент, который, на мой взгляд, работает более корректно, нежели AlarmSummary.
Теперь, вернемся к фактам, по моему глубокому убеждению, факты – это не простые утверждения на форуме, я готов (по первому запросу) выслать любому заинтересованному, как свою версию тестового проекта от Ср 04 Мар, 2009 10:46:49, так и новую версию проекта с исходным кодом DIMIOKS (которая была дополнена, ЧТО ВАЖНО ДЛЯ ПОНИМАНИЯ ПРОБЛЕМЫ, стартовым экраном и кнопками, как описано чуть выше), которая также полностью подтверждает мои утверждения сделанные ранее.
В свою очередь, буду очень признателен, если на мой e-mail вышлют тестовый проект, где НА ЭКРАНЕ ПРИ ЗАПУЩЕННОМ ПРОЕКТЕ в компоненте RSView32 ActiveX AlarmSummary можно будет видеть, как меняется Description тега с помощью процедур VBA.
Зарегистрирован: May 14, 2005 Сообщения: 290 Рейтинг: +9/-0 Откуда: г.Самара
Добавлено: Сб 07 Мар, 2009 12:01:59 Заголовок сообщения:
Я не понимаю вот этого переливания из пустого в порожнее. AlarmSummary работает, так-же, как работает и AlarmLogViewer.
Проблема в понимании механизмов реализации методов, например возьмем AlarmSummary.
Я не гарантирую полное понимание всей "кухни", но на основе своего опыта могу сказать следующее:
Информацию о Description AlarmSummary берет в момент первого события Alarm конкретного тега, либо при запуске, когда в памяти висят неквитированные сигналы. В дальнейшей работе AlarmSummary оперирует именно этим значением, вплоть до перезагрузки объекта. Разработчикам, как видно, в страшном сне не могло приснится, что Description необходимо менять в динамике!
Проверка простая:
1. Создаем тэг с Description "Description1". (Alarmed в Startup установлен, дисплей один - стартовый). Как вариант тэг с Description "Description1" уже существует.
2. Меняем Description на "ААА".
3. Меняем Value тэга: получаем событие InAlarm.
4. Смотрим на объект AlarmSummary на стартовой странице. Description как "ААА". При дальнейших изменениях Description на AlarmSummary изменений Description не будет!
Если Вы используете AlarmSummary в виде объекта, да еще на стартовой странице, то запуск AlarmSummary произойдет сразу после инициализации окна и поведение AlarmSummary будет так, как описано выше, вплоть до момента закрытия окна.
Но!!! Если Вы запускаете AlarmSummary не как объект дисплея, а как отдельный редактор, то при каждом вызове у Вас будет именно текущее значение Description тэга. Абсолютно так-же все будет происходить, если AlarmSummary сделать в виде объекта, но на другом окне (закрытие окна как Abort Me).
И если в Вашей задаче необходимо динамически изменять Description тэга, при этом AlarmSummary должен быть обязательно в виде объекта на главном окне, то не задумываясь я бы тупо закрывал окно и тут - же запускал его вновь (вот здесь, скорее всего, без VBA не обойтись). Рассматривать варианты перезапуска AlarmSummary как визуального компонента без закрытия окна не хочу, если такие варианты и существуют.
И я не вижу, чтобы здесь "что-то не работало". Как я понимаю, вся проблема в том, что разработчики не посоветовались с Вами и не учли Ваши желания. Поэтому компонент AlarmSummary работает так, как это задумали разработчики.
Цитата:
Это обстоятельство вынудило меня написать свой ActiveX компонент
Вот с этого и надо было начинать, а не валить все на непредусмотрительных разработчиков. Когда мне нужна была связка с БД Access я, просмотрев документацию по RSView32, накатал свой пакет программ. И причина, почему я не делал это на VBA - это моё незнание этого языка, а не "кривой VBA".
Зарегистрирован: Jan 21, 2009 Сообщения: 39 Рейтинг: +3/-0
Добавлено: Вс 08 Мар, 2009 15:41:08 Заголовок сообщения:
Мне кажется здесь две проблемы.
1. Мы имеем дело с программистом который хочет переделать все что угодно, лишбы переделать ибо оно работает не так как нужно по его мнению. Лишний раз убедился нельзя в эту сферу пускать программистов нашей страны. Делал проекты до 3500 переменных на RSView32 и не разу не пользовался VBA, кроме простейшего отправить рапорт на печать.
2. С такими встречался на других форумах(по другим компаниям), написать что у вас плохо все сделано, этакая антиреклама.
3. Если необходимо то лучше написать программу в Лоджике. И просто и понятно.
Проще надо делать
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Вс 08 Мар, 2009 21:33:55 Заголовок сообщения:
В паре своих проектов я довольно интенсивно использовал VBA.
В одном, лет 10 назад, тогда ещё не было хороших средств репортинга, я писал в VBA скрипты, забирающие информацию из тэгов и DLG-моделей, а потом скрипты вписывали данные в шаблон рапорта в Excel.
В другой раз я писал на VBA управление рецептурами резиновых смесей для шинного завода Michelin. Там у клиента были очень специальные требования, которые можно было выполнить только с помощью скриптов VBA.
Ещё один раз коллега писал скрипты на VBA для KRUPP Polysius, когда они строили цементный завод в Узбекистане.
Вот и все три случая активного использования VBA за более, чем 10 лет изготовления проектов на RSView32. Больше случаев не припомню.
Как бы там ни было, коллеги, подход "раз этот продукт дорогой, то он должен работать так, как я хочу, потому что я думаю, что он так и должен работать" мне непонятен.
Зарегистрирован: Jan 21, 2009 Сообщения: 39 Рейтинг: +3/-0
Добавлено: Пн 09 Мар, 2009 9:13:12 Заголовок сообщения:
oldDad писал(а):
В паре своих проектов я довольно интенсивно использовал VBA.
В одном, лет 10 назад, тогда ещё не было хороших средств репортинга, я писал в VBA скрипты, забирающие информацию из тэгов и DLG-моделей, а потом скрипты вписывали данные в шаблон рапорта в Excel.
В другой раз я писал на VBA управление рецептурами резиновых смесей для шинного завода Michelin. Там у клиента были очень специальные требования, которые можно было выполнить только с помощью скриптов VBA.
Ещё один раз коллега писал скрипты на VBA для KRUPP Polysius, когда они строили цементный завод в Узбекистане.
Вот и все три случая активного использования VBA за более, чем 10 лет изготовления проектов на RSView32. Больше случаев не припомню.
Как бы там ни было, коллеги, подход "раз этот продукт дорогой, то он должен работать так, как я хочу, потому что я думаю, что он так и должен работать" мне непонятен.
Ну насчет дорогой, не дороже других. А SE и существенно дешевле.
А если сравнивать с отечественными + трудоемкость, то дешевле. Зато программистам есть где развернуться.
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пн 09 Мар, 2009 13:27:22 Заголовок сообщения:
Ну, я и не утверждал, что дорогой
Это утверждал уважаемый коллега scout.
Мне всегда интересно спрашивать у инженеров или программистов, которые утверждают, что данный продукт "дорогой": "По сравнению с чем он дорогой?"
Интересно также, когда технические специалисты или программисты, которые, как правило, не выполняют коммерческие функции, не являются лицами, ответственными за закупку, не располагают соответствующим бюджетом и поэтому не принимают решения о покупке, мыслят не в терминах "более функциональный - менее функциональный" (как это следовало бы ожидать от технического специалиста), а коммерческими категориями - "дорогой - недорогой".
Зарегистрирован: Dec 10, 2006 Сообщения: 20 Рейтинг: +0/-1
Добавлено: Вт 10 Мар, 2009 13:58:49 Заголовок сообщения:
scout писал(а):
… на сегодняшний момент мне не удалось в AlarmSummary получить адекватное Description тега, поэтому данная проблема для МЕНЯ до сих пор НЕ РЕШЕНА. Это обстоятельство вынудило меня написать свой ActiveX компонент, который, на мой взгляд, работает более корректно, нежели AlarmSummary.
Добрый день. Поставленная Вами задача меня заинтересовала. Очень бы хотел взглянуть на Вашу разработку.
ИМХО: В RSView32 есть пролемные места из-за которых приходится прибегать к другим средствам, например VBA причем не встроенный в скаду, Delphi...
Зарегистрирован: Dec 10, 2006 Сообщения: 20 Рейтинг: +0/-1
Добавлено: Вт 10 Мар, 2009 14:04:36 Заголовок сообщения:
DIMIOKS писал(а):
. Как я понимаю, вся проблема в том, что разработчики не посоветовались с Вами и не учли Ваши желания.
Соответственно вопрос? Что изменилось в RSView после версии 6.40 ? Объективно????
Наши Друзья Из Роквелла так и не добавили некоторые моменты в скаду о которых мы сними беседовали в разговоре Что такое хорошо? И что такое плохо?. )))
Зарегистрирован: Dec 10, 2006 Сообщения: 20 Рейтинг: +0/-1
Добавлено: Вт 10 Мар, 2009 14:14:54 Заголовок сообщения:
vsv1953 писал(а):
Мне кажется здесь две проблемы.
1. Мы имеем дело с программистом который хочет переделать все что угодно, лишбы переделать ибо оно работает не так как нужно по его мнению.
Грубо... Очень грубо.
vsv1953 писал(а):
Лишний раз убедился нельзя в эту сферу пускать программистов нашей страны.
Собственно Вы сами то "Чьих то будете" (с)???
vsv1953 писал(а):
Делал проекты до 3500 переменных на RSView32 и не разу не пользовался VBA, кроме простейшего отправить рапорт на печать.
3500 ?? - Это показатель чего? Сложности проекта? К примеру Наши и поболее будут.
vsv1953 писал(а):
2. С такими встречался на других форумах(по другим компаниям), написать что у вас плохо все сделано, этакая антиреклама.
Человек обратился с проблемой не имея ввиду что RSView32 ниже плинтуса... Как специалист, решил пойти дальше... И что в этом плохого??
Зарегистрирован: Jan 21, 2009 Сообщения: 39 Рейтинг: +3/-0
Добавлено: Ср 11 Мар, 2009 6:47:18 Заголовок сообщения:
SpellBinder писал(а):
vsv1953 писал(а):
Мне кажется здесь две проблемы.
1. Мы имеем дело с программистом который хочет переделать все что угодно, лишбы переделать ибо оно работает не так как нужно по его мнению.
Грубо... Очень грубо.
vsv1953 писал(а):
Лишний раз убедился нельзя в эту сферу пускать программистов нашей страны.
Собственно Вы сами то "Чьих то будете" (с)???
vsv1953 писал(а):
Делал проекты до 3500 переменных на RSView32 и не разу не пользовался VBA, кроме простейшего отправить рапорт на печать.
3500 ?? - Это показатель чего? Сложности проекта? К примеру Наши и поболее будут.
vsv1953 писал(а):
2. С такими встречался на других форумах(по другим компаниям), написать что у вас плохо все сделано, этакая антиреклама.
Человек обратился с проблемой не имея ввиду что RSView32 ниже плинтуса... Как специалист, решил пойти дальше... И что в этом плохого??
1. К сожалению очень часть встечаюсь с этой проблемой. Наши програмисты всегда хотят все улучшить. Ничего вроде плохого, но делу мешает. Есть СКАДА в которых нужно конфигурировать используя существующий инструмент, а есть коленные СКАДА где надо буквально писать программу.
2. Я буду из наших и занимаюсь автоматикой 33 года и АСУТП с 83г. При современных системах квалифицированный киповец сделает всегда лучше чем программист. По той простой причине, что будет просто делать а не стремиться улучшать. НЕТ систем без недостатков
3. 3500 это показатель того что все делалось без ухищрений. Все сложности как обычно в контроллере.
Зарегистрирован: Feb 18, 2009 Сообщения: 9 Рейтинг: +0/-0
Добавлено: Ср 11 Мар, 2009 10:49:01 Заголовок сообщения:
Уважаемые знатоки RSView32, прошу Вас снова вернуться к ФАКТАМ, поскольку полагаю, что все Вы закончили школу, где нас всех учили читать умные книжки
Итак, откроем букварь №1: “Получение результатов с помощью RSView32 Scripting”, где черным по белому сказано, что Tag – это объект, который имеет свойства & методы, например: Value, MinimumValue, MaximumValue, Description и т.п.
Для тех, кто не владеет технологиями, букварь №2: “Использование COM/DCOM в Delphi” (http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1108), где объяснено популярно, что: …
В Windows 3.1 и более ранних версиях основным средством обмена данных между программами была технология DDE - Dynamic Data Exchange (ДИНАМИЧЕСКИЙ обмен данными). На этой технологии основывалась технология OLE - Object Linking and Embedding (связывание и внедрение объектов). …
Начиная с 1993-его года в Windows NT 3.51 появилась технология OLE 2 - дальнейшее развитие OLE. OLE 2 дополнительно содержит в себе технологии ActiveX, Automation (первоначально называвшаяся OLE Automation) и другие расширения, далеко выходящие за рамки связывания и внедрения объектов, поэтому фирма Microsoft с выходом OLE 2 объявила, что слово "OLE" больше не является аббревиатурой, это просто термин, не имеющий расшифровки. Технология DDE была недостаточной для поддержки OLE 2, поэтому специально под неё была создана новая технология взаимодействия между программами - COM (Component Object Model, модель компонентных объектов). COM оказалась очень удачной технологией, поэтому, начиная с Windows 95, DDE была объявлена устаревшей, а основной технологией обмена данными в системе стала технология COM.
Итак, ГДЕ “Спрятался” ДИНАМИЧЕСКИЙ ОБМЕН В RSView32???
У объекта RSView32.Tag динамически меняются свойства тега, НО некоторые из них, к примеру такие, как MinimumValue, MaximumValue, Description “живут своей жизнью”, т.е. полностью не адекватны в родных визуальных компонентах RSView32. Мои простенькие примеры наглядно это демонстрируют …
Так, где здесь здравый смысл? ... когда RSView32 Tag Monitor (как заявлено самим производителем, спец.инструмент для оперативного наблюдением за тегом), показывает нам одно значение Description = "??? NEW TEST ???", а в журнал тревог (который можно просмотреть с помощью др. спец.инструмента RSView32 Alarm Summary), пишутся совершенно другие данные ТОГОЖЕ САМОГО ТЕГА, в нашем случае Description = “TEST”. ЭТО ведь АБСУРТ какой-то!
Часовой пояс: GMT + 1 На страницу Пред.1, 2, 3След.
Страница 2 из 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
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.140 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
