Для PAV:

1) "Но декларируемая цена в 400$ за единицу исполнительного модуля (кл. - мониторинг и супервиз. управл. для palmtop, handheld PC) несерьезна"

Цены на МикроМРВ для Windows CE, естественно, пока не объявлялись, но они будут конкурентноспособными. $400 - это не цена МикроМРВ, а цена графической консоли, поэтому она выше.

2)"И конечно же, обязательно - продолжать поддержку DOS!"

Мы планируем поддерживать DOS, Windows CE, LINUX, QNX (если последняя к тому времени не умрет).

2) "главная претензия к существующему микроМРВ - быстродействие...Нас устраивает 1 мс такт, но у Вас он реально недостижим! Небольшой проект (24 канала), совсем без алгоритмических ухищрений (только логика), сейчас на Pentium-600(!) НЕ УСПЕВАЕТ ПЕСЧИТЫВАТЬСЯ ЗА 1 мс!!!"

Тут есть небольшое недопонимание - 1 мс это базовый цикл ТРЕЙС МОУД, т.е. минимальное время ряда базовых операций: цикла канала, записи архива, шага тренда и т.д. Не надо путать эту величину с циклом пересчета всей базы.

Быстродействие Микро МРВ ТРЕЙС МОУД соответствует потребностям рынка промышленной автоматизации. Например, по нормам РАО ЕЭС быстродействие в контуре защит и блокировок энергоблока должно быть меньше 100 мс и Микро МРВ с этим прекрасно справляется. Системы, о которых говорите Вы - это наверно станки, роботы, двигатели и т.д. Для нас эти применения не являются основными и Микро МРВ 5 на них не рассчитывался. Главное - мы не чувствуем платежеспособного спроса из этого сектора!

Расскажит подробнее о Ваших задачах - может быть мы ошибаемся и Микро МРВ 6 следует ориентировать также и на сетор спецприменений.

3)"хочется настоящего ОБЪЕКТНОГО инструментария..."

Мы планируем более строго применять принципы объектного построения программы в версии 6.

4)"Очень нужна возможность закрывать паролем отдельные ОБЪЕКТЫ узла (делая недоступными каналы, FBD, IL). Кстати, это легко реализуется в объектной модели и никик - в процедурной"

Интересная мысль! Учтем! Хотя объектный подход тут ни при чем!

5) "Было бы очень полезным иметь возможность запуска проекта, состоящего из нескольких однотипных узлов на одной станции (контрроллере)"

Не понял. Зачем?

6) "В ТМ5 нет такого типа узла, как "графическая консоль" и РПД позволяет создать только одну графическую базу для одной базы каналов"

В ТRACE МODE 6 предусматривается возможность создавать разные графические клиенты для одного сервера матобработки и NetLink Light будет узлом проекта.

С другой стороны, многие серьезные приложения, где от "экстенсивного" стиля никуда не деться (БД, CAD, офисные программы, SCADA) содержат внутри себя мощный скриптовый язык, позволяющий при желании пользователя полностью заменить пусть визуальную, но все таки однообразную ручную работу по проектированию и конфигурированию.

Что, на мой взгляд, существенно “украсило” бы ТМ, особенно к крупных проектах::

- скриптовый язык как в базе каналов так и в РПД, достаточно мощный для того, чтобы не только манипулировать (создавать, изменять, удалять) объекты в RunTime, но и
выполнять более глобальную задачу - дать возможность заменить ручные операции по созданию и конфигурированию системы. Надеюсь, Вы почувствовали разницу между предлагаемым автопостроением. Например, в большом проекте нужно по определенному правилу изменить периоды пересчета каналов – написал соответствующий скрипт, а не в ручную лазил по тысячам каналов. Или нужно с небольшими изменениями растиражировать некий объект. Если процесс его создания можно представить в виде скрипта, то будет очень просто его клонировать, внося в скрипт небольшие поправки, вместо того чтобы копировать 1:1, а потом вручную вносить изменения. Впрочем идея внутреннего языка не нова и серьезные приложения имеют его почти в обязательном порядке.

quote:

---

Например, мне нужно создать 1000 совершенно одинаковых трендов. Сейчас я вынужден руками создавать 1000 экранов, на каждый экран поместить форму, привязать ее к каналам и т.д.....

---

quote:

---

Любой программист, программируй он на полноценном языке программирования ...

---

--------------------------------------------------------------------------------

К сказанному выше добавлю, что любой экран или группа экранов может быть сохранена в файл и затем растиражирована. Вставленный в экран тренд можно объявить объектом. В базе каналов следует создать загружаемые объекты, содержащие списки выводимых на каждый тренд каналов. После этого легко перепривязать тренд на каналы требуемого объекта базы каналов.Чтобы не создавать 1000 экранов можно сделать 10 групп по 100 экранов и поступать, как указано выше. Для людей, не знающих VBS/VBA это более простой выход, чем учить новый язык программирования! Мы и в будущем планируем ориентировать наши разработки в первую очередь на инженеров по АСУ и КИП. Однако, в TRACE MODE 6 будет предусмотрена возможность РАВНОПРАВНОЙ (т.е. без потери качества) разработки АСУ ТП программистом (кстати, Вам какой язык кажется более привлекательным?).

А по-поводу экранных скриптов, как я уже писал, вопрос решен - они будут.

Меня удивляет нежелание взглянуть в корень...

1. Если настраивать ФО "Перепривязка" - объем тупой ручной работы уменьшится очень незначительно - нужно настроить 1000 перепривязок к тому же дополнительно настраивать посылку нужного значения в канал, управляющий перепривязкой.

2. Сильно сомневаюсь, что все 1000 трендов будут буферизоваться - будет буферизоваться 1 текущий, а при перепривязке на другой он окажется пустым

3. Я уже неоднократно писал о том, что формами, подобными ФО "Перепривязка" нельзя пользоваться в многопользовательских проектах: реализация Вашего предложения приведет к тому, что все пользователи вынуждены будут смотреть только один тренд. Если один пользователь захочет перепривязться на другой тренд, то эту перепривязку будут наблюдать все пользователи, поскольку управление идет по значению канала!

<Вы не учитываете одного: не все разработчики АСУТП - программисты, знающие полноценные языки программирования. Таких пользователей, по нашим примерным оценкам (ориентируясь на пользователей ТМ) - около 80% ! Поэтому в ТМ существуют различные механизмы, которые позволяют решить подобные задачи без использования языков программирования>

Тем самым Вы 20% программистам, которые, кстати, делают 80% проектов, связываете руки. Уже давно в серьезных продуктах утвердился такой подход - одно и то же действие можно выполнить двумя путями: визуально, щелкая мышью (для начинающих, непрограммистов и небольших задач) и с помощью скриптов (для продвинутых пользователей-программистов и крупных задач). И каждый пользователь выбирает то, что ему больше подходит. Так что возможность программирования вовсе не противоречит возможности простой визуальной разработки для 80% пользователей.

По поводу обращения от 18.10.01.

Вопрос о необходимости введения языка скриптов для графической базы можно уже, кажется, закрыть. Ответ уже дан - такой язык будет.

О "рутинности 1000 перепривязок". Для любого варианта создание списка каких-либо объектов, для которых необходимо создавать идентичные ФО, это операция необходимая, хотя и рутинная. По крайней мере, один раз его создать нужно. Далее все операции могут быть осуществлены автоматически.

О "буферизации" 1000 трендов.
1000 трендов * 5 каналов * 1000 точек * 8 байт = 40 МБ. Реализовать это можно (принципиальных ограничений нет), но не слишком ли много? М.б., лучше использовать имеющиеся архивы, в которых уже все "буферизировано"?.

В последний раз речь велась о внутреннем языке как для базы каналов, так и РПД, позволяющем выполнять задачи разработки и редактирования проекта, а вовсе не скриптах в графичесокй консоли. Ответа пока не прозвучало, кроме "в TRACE MODE 6 будет предусмотрена возможность РАВНОПРАВНОЙ (т.е. без потери качества) разработки АСУ ТП программистом". Свое отношение к общеполитическим лозунгам я уже высказывал. Чем будет обеспечена такая возможность - целостной картины пока так и не сложилось.

<<<<О "рутинности 1000 перепривязок". Для любого варианта создание списка каких-либо объектов, для которых необходимо создавать идентичные ФО, это операция необходимая, хотя и рутинная. По крайней мере, один раз его создать нужно. Далее все операции могут быть осуществлены автоматически.

О "буферизации" 1000 трендов.
1000 трендов * 5 каналов * 1000 точек * 8 байт = 40 МБ. Реализовать это можно (принципиальных ограничений нет), но не слишком ли много? М.б., лучше использовать имеющиеся архивы, в которых уже все "буферизировано"?.

О "невозможности использования перепривязок для независимо работающих графических консолей".
Для каждой консоли легко модифицировать графическую базу таким образом, что управление перепривязками для каждой консоли будет осуществляться через свой канал>>>>>>>

Господа! Посмотрите пожалуйста тему топика. Она называется "ТМ6 предложения/Adastra, что ты нам готовишь НОВОГО". Поэтому не нужно здесь растолковывать, как решать поднятые мною проблемы средствами ТМ5. Я их уже давно решил примерно теми же способами, что вы предлагаете и возможности ТМ5 знаю прекрасно. Но мне не нравится делать многие вещи так, как их приходится делать в ТМ5. Поэтому как активно практикующий разработкчик пытаюсь "бороться" с вами.