Форум TRACE MODE: техническая поддержка: Adastra, что ты нам готовишь нового?

This is topic Adastra, что ты нам готовишь нового? in forum TRACE MODE 6 (предложения / suggestions) at Форум TRACE MODE: техническая поддержка.

To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/20/t/000003.html

Posted by Tag (Участник № / Member № 34) on :

Уважаемая Адастра! Раз уж Вы завели такой сабж, то неплохо бы было сперва от Вас услышать (увидеть) подробное описание нововведений в Trace Mode 6. На то есть по крайней мере 2 причины:
1) Пользователи Трейс Моуда не хотят ждать некий загадочный "сюрприз", чтобы потом "приятно удивиться". Уже сейчас хочется быть уверенным, что Trace Mode 6 будет отличаться в выгодную сторону и знать, чем именно он будет отличаться.
2) Какой смысл нам (пользователям) тратить время на изложение своих предложений, если Вы, может быть и так их уже реализовали, просто мы об этом еще не знаем.
P.S. То, что мы слышали о Trace Mode 6 от г-на Айзина на конференции явно недостаточно.

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Уважаемый Tag,

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

Высказывайтесь!

Posted by Павел (Участник № / Member № 48) on :

Так как представление TM6 намечается к концу 2002г., есть время организовать ее Б-тестирование. Тестерами могли бы выступить заинтересованные официальные пользователи ранних версий. Условия и методика тестирования могут быть ваши, или также возможны варианты.

Posted by Lev Anzimirov (Участник № / Member № 25) on :

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

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

а) на операторских станциях;
б) в контроллерах?

Posted by Павел (Участник № / Member № 48) on :

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

Posted by Lev Anzimirov (Участник № / Member № 25) on :

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

Posted by Tag (Участник № / Member № 34) on :

Раз Адастра не хочет делиться информацией, то придется исходить из давно известного принципа: <пользователь не знает, чего он хочет, пока не увидит законченый продукт>, а именно из обсуждения недостатков ТМ5, в надежде на то, что они будут устранены в ТМ6.
Начнем, пожалуй, с того, что лежит на поверхности - пользовательский интерфейс. SCADA, в моем понимании, должна быть образцом юзабилити, а ТМ5, имхо, уверенно лидирует в номинации "самый неудобный интерфейс".
Лев Владиславович, а Вы были в курсе, когда писали статью "Технологии Трейс Моуд для круномасштабных АСУТП", что на создание только ПУСТОГО объекта в базе каналов тратится до ТРЕХ МИНУТ!!! времени, потому что он создается в непредсказуемом месте рабочего пространства и поэтому приходится сначала долго искатьи его а затем еще дольше перетаскивать в нужное место, выполняя нехитрую комбинацию действий <прокрутил полосу прокрутки - переместил объект-прокрутил полосу прокрутки - переместил объект>?. И еще Лев Владиславович, я конечно ничего не смыслю в SCADAх мирового уровня, но объясните мне, пожалуйста, чтобы я смог объяснить своим бедным подчиненным, почему выделив несколько форм отбражения "динамический текст" нельзя отредактировать формат вывода или цвета аварийных гранциц и еще целый ряд часто используемых свойств, но зато можно настроить такое "нужное" свойство шрифта как подчеркивание? Почему они должны целиться в границу элемента чтобы его выделить или переместить? Поддержка рекомендует: "Для выбора объекта на редактирование можно использовать список элементов текущего открытого окна. Это намного быстрее, чем стараться попасть по краю элемента". А еще, быстрее, когда сделано по нормальному, как во всех других графических редакторах - взял за любое место и переместил.
Поверьте, Вашим пользователям очень грустно рыться в списке из нескольких сотен строк, пытаясь угадать, какая из строчек соответствует нужной форме отображения. Почему список у любой из форм отбражения "свободные формы" имет всего 4 строки и его нельзя растянуть, почему нельзя растянуть окно "каналы объекта" и приходится просматривать длинный список в узкую щелочку из нескольких строк? Насчет недостатков правки каналов я уже высказывался ранее в разделе "РБК".
Вы уж простите, но буквально ото всюду веет какой-то небрежностью и безалаберностью. НакрутИте Вы, наконец, хвосты своим программистам и дизайнерам и отправьте их на стажировку к какому-нибудь системному интегратору, чтобы своими руками разработали крупный проект и осознали, что они такое лепят.

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

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

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

Успехов,
читайте соображения об общей идеологии ТМ позже.

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Уважаемый Tag,

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

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

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

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

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

С уважением!

Posted by qwartz (Участник № / Member № 73) on :

Может быть есть смысл сделать этот форум только для зарегистрированных пользователей, а для незарегистрированных оставить только общие вопросы?
Зачем бесплатно делиться своими идеями.
За Державу обидно.

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Спасибо, qwartz!

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

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

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

Пишите!

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

С уважением!

Posted by Tag (Участник № / Member № 34) on :

День добрый!
> Нужна ли вам многоплатформность TRACE MODE 6?
> Какие ОС Вы планируете использовать на ПК?
Хотелось бы рассмотреть этот вопрос несколько шире, нежели это делает г-н Айзин в своем докладе. Там выделяется 2 уровня АСУТП – уровень контроллеров и уровень операторских станций. Я бы добавил еще один уровень между ними – уровень серверов матобработки, если придерживаться терминологии Трейс Моуд, тем более это уже заложено в архитектуре ТМ5. Уже сейчас в проектах, где позволяет бюджет, мы стараемся разнести на разные машины математику и графику – сервер матобработки запускаем на одной, а АРМы операторов (графические консоли) на других машинах, как из соображений надежности, так и производительности и безопасности, поскольку графика очень ресурсоемка и там где тыкает руками человек, надежность резко падает. Преобладание Windows как раз не наблюдается в секторе серверных платформ, поэтому была бы замечательна возможность запуска сервера матобработки также и под Unix (Linux). Правда сейчас в основе взаимодействия сервера матобработки и графических клиентов лежит Windows-технология DCOM, но почему бы не добавить еще возможность взаимодействия по какому-нибудь кросс-платформенному механизму (например, в технологии MIDAS от Borland для построения многозвенных систем можно выбрать любой механизм взаимодействия между сервером приложений и клиентами из множества [CORBA, XML, HTTP, чистый TCP/IP]).
Раз уж разговор зашел об архитектуре, то хочется упомянуть такой очень существенный недостаток клиент-серверной архитектуры ТМ5 – вся математика, в том числе и логика работы пользовательского интерфейса заложена в сервере матобработки, а графические консоли математики вообще не имеют. Это приводит к очень серьезным проблемам при разработке крупных многопользовательских систем. Представьте, нужно сделать так, чтобы в зависимости от некоторых услових при нажатии на кнопку происходил переход на тот или иной экран. Казалось бы нет проблем, используй форму отображения, позволяющую управлять переходами между экранами по значению заданного канала, посылай кнопкой значение на вход этого канал, сделай FBD-программу, которая анализировала необходимые условия и формировала нужное управляющее значение для этой формы отображения. Все это приемлемо до тех пор, пока система однопользовательская. А теперь представьте, что к серверу матобработки подключились 2 Супервизора в режиме реального времени. Один нажимает на кнопку перехода, но оба клиента вынуждены наблюдать этот переход, поскольку управление осуществляется с одного сервера. Если пользователь перевел Супервизор в режим работы с архивами, то кнопка вообще перестанет работать, поскольку обмен данными РВ с сервером матобработки разорван.
Вывод напрашивается следующий. Необходимо “утяжелить” графические клиенты, встроив в них возможность программирования работы графики, а из сервера матобработки эту часть убрать. Получим более стройную архитектуру и простоту создания многопользовательских систем. Кроме того, работа пользовательского интерфейса является событийно-управляемой и довольно плохо укладывается в концепцию циклического пересчета базы каналов. Также для современной SCADA явно мало всего двух типов переменных – число с плавающей точкой и целое. Для программирования графики хочется иметь полноценный язык программирования (пример для подражания – встроенный VBA в GraphWorX32 Genesis32).
Я прекрасно знаю доводы в пользу Вашего подхода, но что с того, что 2000 индикаторов обновляются 2 раза в секунду? Зачем это нужно, если достигнуто за счет ограниченности в возможностях программирования? Человек просто не в состоянии наблюдать одновременно за таким количеством индикаторов да еще с такой частотой. Не следует бояться тяжелой графики, поскольку в крупной и грамотно спроектированной системе сервер реального времени и графические рабочие места пользователей всегда разнесены и ресурсоемкость клиентов не влияет на производительность сервера.

> Планируете ли вы использовать Интернет-технологии в АСУ ТП?
Да, но в основном на уровне супервизоров, для коллективного доступа к отчетам и БД.
Успехов!

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Уважаемый Tag,

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

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

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

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

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

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

С уважением!

Posted by Tag (Участник № / Member № 34) on :

День добрый!

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

Posted by Tag (Участник № / Member № 34) on :

... не дождался

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

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

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

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

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

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

Успехов!

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Уважаемый Tag,

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

Успехов!

Posted by Lev Anzimirov (Участник № / Member № 25) on :

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

К вопросу о МЭК и VBA. В стандарт МЭК входят 5 языков, один из которых - Структурированный текст - является процедурным, т.е. похож на Бейсик. Однако, при его применении не надо использовать интерпретатор Бейсика. Поэтому мы избегаем исполнения управляющих комманд (ведь Вы этого хотите в клиентах) неконтролируемой нами программой, которая никогда не предназначалась для задач реального времени и, соответственно, ее пагубного влияния на производительность, компактность и стабильность готового продукта. Согласитесь, что 90% функций Visual Basic не нужны для задач управления интерфейсом...

Posted by Tag (Участник № / Member № 34) on :

<Dll интерпретируется нашим движком, а Visual Basic - это черный ящик.>
Сказано очень эффектно, но, имхо, некорректно

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

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

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

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

Администратор, закройте пжлста тему

Posted by Lev Anzimirov (Участник № / Member № 25) on :

Извините, если мои слова прозвучали резковато. Я этого не хотел. Ваши основные идеи по-поводу экранных скриптов и даже Visual Basic мы считаем справедливыми и уже работаем над их воплощением. Детали ТМ6 я обсуждать не могу, как и Вы я их не знаю -ТМ6 существует пока в виде проекта и набора прототипов. Поэтому мои заявления декларативны. Но декларация о повышении дружественности GUI, хоть и может показаться Вам пустой, для разработчиков - это конкретное руководство к действию, которое на глазах обрастает томами инструкций и спецификаций.

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

Жду Ваших компетентных мнений! С уважением!

Posted by PAV (Участник № / Member № 45) on :

quote:
Отправитель / Originally posted by Tag:
День добрый!
Пользователь хочет нажимая на ОДНУ_И_ТУ_ЖЕ кнопку переходить на разные экраны в зависимости от ситуации.
В целом проблема в управлении экранами, изложенная Вами, существует и поддерживается нами, НО! Одно и то же действие оператора должно вызывать один и тот же отклик системы и никак иначе. Нажатие на одну кнопку не должно приводить к различным в зависимости от ситуации действиям.

Posted by PAV (Участник № / Member № 45) on :

Хочу поучавствовать в дискуссии, к сожалению с небольшим опозданием. Очень волнует судьба 6 версии.
Вообще говоря, нас, как машиностроителей, судьба графических компонентов ТМ волнует в самую непервую очередь.
К вопросу о платформах. Нам нужно DOS, Windows NT, 2000, CE. Последняя - особенно. Но декларируемая цена в 400$ за единицу исполнительного модуля (кл. - мониторинг и супервиз. управл. для palmtop, handheld PC) несерьезна, так как уже сейчас равна стоимости тех самых palmtop, handheld PC, на которых она работает. Более того, нам нужна версия МикроМРВ для СЕ по цене микроМРВ для DOS (касается исполнительных модулей)
И конечно же, обязательно - продолжать поддержку DOS! Держите марку SCADA-системы нового поколения, обращайте больше внимания на поддержку SoftLogic части! Системному интегратору, мягко говоря, не хочется иметь дело с софтовым винигретом для железа нижнего уровня и собственно SCADA-софтом. Единый инструмент, позволяющий делать проект автоматизации - насущная проблема.

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

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

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

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

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

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

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

PS. А вообще вы (AdAstra) молодцы, "Правильным путем идете, товарищи!"

Posted by Tag (Участник № / Member № 34) on :

PAV wrote:
<НО! Одно и то же действие оператора должно вызывать один и тот же отклик системы и никак иначе. Нажатие на одну кнопку не должно приводить к различным в зависимости от ситуации действиям.>

То PAV:

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

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

To Adastra:

Есть еще вот какое пожелание, касающееся граф. клиентов. Извиняюсь, что оно опять преподносится как недостаток ТМ5, но суть такова:
В ТМ5 нет такого типа узла, как "графическая консоль" и РПД позволяет создать только одну графическую базу для одной базы каналов, тогда как к МРВ вполне можно подключить несколько разных клиентов. Сейчас это приходится делать искусственно: создать одну графическую базу, скопировать ее в другой каталог, создать вторую граф. базу, скопировать ее в другой каталог и т.д... Хотелось бы в ТМ6 создавать разных графических клиентов для одного сервера матобработки более естественным путем.

Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us

UBB.classic™ 6.7.2