всему свое время... Общие положения о TM6 изложены в докладе В.Айзина http://www.adastra.ru/confr/confr7/Aisin.htm . Естественно, это не полный материал, но там довольно много принципиальных положений, которые хотелось бы обсудить. Вы должны понимать, что мы не будем публиковать проект новой версии системы пока не настанет час. Однако, хотелось бы услышать мнение ПОЛЬЗОВАТЕЛЕЙ о путях развития системы.

Кстати, какие операционные системы Вы планируете использовать в будущем:

Выделенную жирным цитату из упомянутой выше статьи совершенно справедливо можно дополнить следующим образом: "автоматизированные технологии Трейс Моуд позволяют сократить время, затрачиваемое на программирование каждого параметра ввода/ввывода в несколько (6) раз, но неважный интерфейс пользователя и отсутствие средств нормальной групповой и индидуальной правки как в РБК, так и в РПД сводят на нет этот выигрыш".

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

Резюме: Приоритетным направлением развития ТМ6 должен стать удобный пользовательский интерфейс и эффективные средства редактирования, поскольку именно из таких вот перичесленных мной выше мелочей складывется как общее время разработки, так и общее впечатление от использования продукта. Нет смысла увлекаться инновационными технологиями, когда более прозаичные вещи не доведены до ума.

спасибо за активное участие в обсуждении. Ошибки в проектировании интерфейса нам известны. Выводы сделаны. Интерфенйс TRACE MODE 6 будут разрабатывать ДРУГИЕ программисты. Мы проведем специальное психологическое тестирование НОВОГО продукта.

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

В статье, которую Вы все время вспоминаете, я описывал преимущества технологий автопостроения TRACE MODE перед технологиями конкурентов. Они действительно существуют. Однако, статью не следует понимать так, что в TRACE MODE нет недостатков перед другими SCADA. Есть! Некоторые из них описаны Вами. Есть и другие. Хорошо известные нам. Поверьте, если бы мы не стремились сделать наш продукт лучше, мы бы не сделали этого публичного формума. Вы думаете я не знаю, что наши конкуренты его активно читают? А у них есть открытые форумы в России? А почему?

Поэтому я прошу вносить предложения к развитию программы, а не сосредотачиваться на ошибках 5 летней давности!

P.S. Прототип TRACE MODE 6 будет представлен на высочайшее обсуждение на 8-й Конференции пользователей 20-22 февраля 2002. Это будет прекрасный повод вносить предложения по улучшению интерфейса БУДУЩЕГО продукта.

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

Хотелось бу услышать мение пользователей по таким вопросам:

- Нужна ли вам многоплатформность TRACE MODE 6?
- Какие ОС Вы планируете использовать на ПК?
- Какие ОС Вы планируете использовать в ПЛК?
- Планируете ли вы использовать Интернет-технологии в АСУ ТП?

Пишите!

Кстати, этот форум только для пользователей. Непользователи могут его только читать.

все-таки, Вы преувеличиваете! Описанная Вами ситуация с принудительным переходом между экранами на всех клиентах, подключенных к серверу не существует. При переходе с экрана на экран по кнопке команда выполняется только на той консоли, где она подана. Конечно, можно сделать так, как Вы пишите - но зачем?

Мы не задумывали Супервизор как управляющую консоль - его задача плейбек архивов, а функции работы в реальном времени - это неожиданный подарок. Поэтому, в реальном проекте стоит разнести управляющие и архивные консоли на отдельные машины или запускать их параллельно.

В одном Вы правы - надо развивать интеллектуальность клиентов. Это решение уже принято и мы в этом направлении мы уже работаем. Языки программирования графики TRACE MODE 6 будут расширены. Врядли это будет VBA - Вы правы, в том, что язык тяжелый, медленный, не для того созданный и имеющий, к тому же лицензионные ограничения. Тем более как совместить VBA и многоплатформность. Мы предложим более логичное и универсальное решение.

Кстати, обновление 4000 индикаторов за секунду - это реальное требование атомной промышленности (наблюдение за активной зоной реактора). Изменение цветовой картины глаз человека вполне улавливает.

Выражение "полноценный-неполноценный" язык врядли продуктивно. Полноценен только VBA?
Языки МЭК неполноценны? Какие типы переменных нужны Вам для работы? Только учтите, что ответ "все" повлечет за собой жирность кода, ресурсоемкость и медленность (что, кстати мы наблюдаем у конкурентов).

Спасибо за ответы на вопросы о многоплатформности и Интернете.

Lev Anzimirov wrote:
"все-таки, Вы преувеличиваете! Описанная Вами ситуация с принудительным переходом между экранами на всех клиентах, подключенных к серверу не существует. При переходе с экрана на экран по кнопке команда выполняется только на той консоли, где она подана. Конечно, можно сделать так, как Вы пишите - но зачем?"
Прочитайте, пожалуйста, мое сообщение еще раз. Там речь ведется не о стандартной функции управления "переходы по экранам". Пользователь хочет нажимая на ОДНУ_И_ТУ_ЖЕ кнопку переходить на разные экраны в зависимости от ситуации. Можно конечно сделать 20 кнопок на все случаи жизни, но зачем загромождать интерфейc, когда можно обойтись одной кнопкой? Так что описанная мной ситуация еще как существует. Или предложите свой способ реализации задачи без участия сервера матобработки. Уверен, что не сможете.
Ждем'с...

<Какие типы переменных нужны Вам для работы?>

Нужен полный программный контроль над всеми свойствами форм отображения (ФО)+ возможность программировать обработку событий: одно/двухкратный щелчок правой/левой кнопкой по ФО, получение/потеря фокуса и т.д., чем больше, тем лучше. У Ваших конкурентов это все уже давно есть.
Вопрос был о типах переменных, поэтому давайте рассмотрим свойства простейшей ФО – динамический текст. У него имеются такие свойства:
- отображаемое значение
- цвет фона и авар. границ
- выравнивание
- шрифт (шрифт+цвет+размер+начертание)
- форматирование
- привязка к каналу
- флаги видимость, прозрачность, проверять
- всплывающая подсказка
- функции управления (по сути обработчики событий)
- длина, ширина, координаты расположения
Какие им соответствуют типы переменных переменных, перечислять, думаю не стоит. Оказывается большинство свойств с некоторой натяжкой можно представить в виде целого числа, кроме строковых свойств (отображаемое значение и всплывающая подсказка). Так что добавьте по крайней мере возможность работы со строками и необходимый набор функций типа IntegerToString, склейки строк и т.д. и возможность программного выполнения функций управления ФО.

<Полноценен только VBA?
Языки МЭК неполноценны?">

Мы вроде бы обсуждаем язык программирования для графических клиентов, я языки МЭК предназначены прежде всего для программирования ПЛК и призваны снять у потенциальных пользователей психологический барьер перехода от проектирования релейных и цифровых схем к программированию микропроцессорной техники. Или ТМ6 будет больше Softlogic чем SCADA?

Задача программирования контроллера мало похожа на задачу программирования интерфейса пользователя, а человек, программирующий интерфейс, как правило, гораздо более знаком с событийно-управляемым объектно-ориентированным программированием, нежели с искусством схемотехники. Поэтому языки МЭК для программирования интерфейсов “неполноценны”, а вернее просто не для этого предназначены, так же как и VBA не задумывался для программирования контроллеров. Хотя не вижу особых проблем на Бейсике запрограммировать контроллер, был бы компилятор под его ОС.

У меня вызывает некоторое непонимание Ваше предложение программировать графику языками МЭК. Поясните, пожалуйста, Вашу позицию.

Ваше сообщение я прочитал внимательно. В TRACE MODE есть кнопки, работающие в пределах консоли, а есть и те, которые отрабатываются сервером. Это не было ясно из Ваших предыдущих писем. Именно поэтому я написал о "преувеличении". Приведенная Вами задача решается описанным Вами же способом. Согласен, что это не самый элегантный путь, но вполне рабочий. Необходимость создания таких кнопок, как описали Вы встречается достаточно редко, но встречается - я с этим согласен. Проблема нам известна, решение об интеллектуализации клиентов уже принято и я об этом писал пару дней назад...

<..решение об интеллектуализации клиентов уже принято. Что его опять обсуждать?>
Просто имейте в виду, что мы, в отличии от Вас, располагаем практически нулевой информацией относительно ТМ6, поэтому то, что для Вас очевидно и обсуждению не подлежит, для нас таковым не является, даже когда речь идет о самых общих принципах.

<Я не хочу вдаваться в дискуссию об ОСРВ - об этом много сказано.>
Это не есть предмет дискуссии. Жаль, что Вы меня не слышите и сваливаете в одну кучу интерфейс и матобработку.

<Дадим! TRACE MODE 6 задумывается как чудо дружественности!>
Вашим пользователям не интересны общеполитические лозунги.
Трейс Моуд - самый лучший, а ТМ6 - вообще чудо. Настолько общие принципы обсуждать нет смысла.

<Когда, Вы агитируете за те или иные решения, помните, что на крупных объектах они вообще не будут работать!>
Да куда уж мне, умолкаю.

Смысл нашей темы - обсудить основные ПРИНЦИПЫ и ФУНКЦИИ будущей SCADA, которые могли бы помочь нашим пользователям в их будущей работе. Поэтому я не хочу закрывать тему, а предлагаю пользователей высказывать свои пожелания.

quote:

---

Отправитель / Originally posted by Tag:
День добрый!

Пользователь хочет нажимая на ОДНУ_И_ТУ_ЖЕ кнопку переходить на разные экраны в зависимости от ситуации.

В целом проблема в управлении экранами, изложенная Вами, существует и поддерживается нами, НО! Одно и то же действие оператора должно вызывать один и тот же отклик системы и никак иначе. Нажатие на одну кнопку не должно приводить к различным в зависимости от ситуации действиям.

---

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

Далее - хочется настоящего ОБЪЕКТНОГО инструментария. Измучили "процедурные" ограничения, связанные с кажущимся табличным построением базы данных (вероятно, это так и есть) - ограничено число переменных в программе, ограничено число блоков, надоело "всплытие" давно удаленных и забытых коментариев к переменным. Прелести поведения "вложенных" FBD-блоков при редактировании оных и вспоминать не хочется.
Перенос готовых решений из одних проектов в другие практически невозможен

Это только мое мнение, но если вы не перейдете к НАСТОЯЩЕМУ ОБЪЕКТНОМУ инструментарию, суть проблем ТМ не измениться.
Пожалуйста, проясните, что вы собираетесь делать в этом направлении, т.е. будет ли ТМ объектным.

Все, критиковать устал (сегодня ). Теперь пожелания.

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

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

На сегодня все! Спасибо.

То PAV:

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

Кроме того, проблема то гораздо шире, нежели приведенный мною пример. Есть целый ряд форм, управление которыми осуществляется по значению канала (упр. состоянием ФО, упр. перепривязкой ФО, упр. переходами, ссылка на экран). Посмотрите демо проект "АСУ товарного парка нефтепродуктов" и преставьте или попробуйте что получиться, если несколько пользователей, находясь на первом экране захотят одновременно посмотреть тренды для разных емкостей.
Искренне надеюсь, что в ТМ6 "интеллектуализация клиентов" нас не разочарует.

To Adastra: