CODESYS V3.5. Визуализация

[Евгений Кислов]

Евгений, здравствуйте.
Решил попробовать библиотеку OwenVisuTools в проекте, интересуют ответы на пару вопросов:
1. По нулю оси Y рисуется какая-то тонкая линия (свои по 3pt сделал) оранжевого цвета. Возможно её как-то убрать, чтобы "глаз не мозолила" и путаницу не создавала?
2. Возможно как-то использовать свои AxisName, вместо тех, которые содержатся в списке текстов самой библиотеки, без её (библиотеки) редактирования? Пробовал в том числе в поле "ID списка текстов для названия" окна "Настройки осей и перьев" указывать свой список с индексом, нечего не меняется, надпись отсутствует. С AxisName.0, например, надпись (Ось 0) появляется.

Добрый день.
1. Покажите, пожалуйста, скриншотом, о чем речь.
2. Насколько я помню - нормальных способов для этого нет.

[Spawn]

1. Покажите, пожалуйста, скриншотом, о чем речь.

1.jpg
Вот...

[Евгений Кислов]

1.jpg
Вот...

Если снять галочку TE2 - эта линия исчезнет?

[Spawn]

Нет, снимаю все галочки, линия на месте...

[Евгений Кислов]

Нет, снимаю все галочки, линия на месте...

Если использовать исходную версию библиотеки, а не отредактированную вами - эта линия сохраняется?

Upd. - повторил у себя.
Чтобы убрать эту линию - надо перед запуском экземпляра ФБ тренда (пока xEnable в FALSE) отключить видимость неиспользуемых перьев.

В рамках примера с нашего сайта это можно сделать так:

IF NOT(xIsInitVisuSettings) THEN

   ...
   // отключите видимость только тех перьев, которые не планируете использовать
   stTrendVisuSettings.astCurves[3].xNoVis := TRUE;
   ...
   stTrendVisuSettings.astCurves[8].xNoVis := TRUE;

   ...

END_IF

[Spawn]

Если использовать исходную версию библиотеки, а не отредактированную вами - эта линия сохраняется?

Да, всё тоже самое. Могу приложить проект для Win V3.

[Евгений Кислов]

Да, всё тоже самое. Могу приложить проект для Win V3.

Я обновил свой пост выше - описал, как исправить упомянутое вами поведение.

[Spawn]

Я обновил свой пост выше - описал, как исправить упомянутое вами поведение.

Да, всё получилось. Спасибо.

[Spawn]

В общем, "пощупал" я на днях этот аналог встроенного в CDS компонента "Тренд" (OwenVisuTools), и что хочется сказать (написать), ребят (представители компании), вы пока не вылечите все болячки своего оборудования, которые кочуют из релиза в релиз, о перспективе линейки СПК, как таковой, не стоит и задумываться. Вроде и железо умощнили (на руках СПК210), вроде и дизайн проработали, вроде и практичности добавилось, но эти тренды...
Для себя, честно, пришел (давно, данный конкретный СПК, с которым сейчас приходится работать, заказывал не я, так, в качестве "оправдания") к выводу, что в проектах с HMI ТОЛЬКО СВЯЗКА ПЛК+СП, как минимум. Как бы мне не нравилась практическая сторона СПК, на его косяки сводят на нет все желание с ним связываться.
ОВЕН позиционирует свое оборудование, в первую очередь, как оборудование для решения задач ПРОМЫШЛЕННОЙ автоматизации ("а уже потом всё остальное"), которое должно отвечать определенным требованиям и функциональным возможностям, а не только требованиям о внесение того или иного оборудования в реестр СИ. Так вот, одна из таких функциональных возможностей - это тренды (ну коли у нас HMI устройство "в руках" и далеко не ИП320), которые что оригинал, что аналог, недопилены. Проблемы встроенного компонента описывать не буду, причастные о нем давно знают, опишу аналог:
1. Глубина архива(ов) *.bin. Изучая пример, в глаза сразу бросилось значение 7200 переменной udiSaveBinPeriod (udiSaveCsvPeriod), спустя некоторое время тестирования ШУ на столе, начало приходить осознание выбора данного значения автором OVT. Ребят, вы серьезно, 7200 записей, два часа посекундно? Да вас (меня в данном конкретном случае) конечный потребитель/пользователь/заказчик системы с ботинками сожрет, с такой глубиной трендов. Почему осознание данного значения пришло только спустя некоторое время? Потому что я вместо 7200 указал 604800. И вот спустя почти двое суток (что будет дальше, страшно вообразить), "передернув" питание СПК наблюдаем "веселье". Для начала опишу свою "кухню". Три ТА, по 4 датчика температуры на каждом (итого 12), и "довесок" с еще пяток, итого 17 штук (измеряемых параметров). Городить все/всё это в кучу не стал, во-первых, нужно разделение/разнесение датчиков по принадлежности, во-вторых, OVT не "разрешает" больше восьми значений на один fbTrend. Так вот, спустя почти двое суток и по ~10МБ (всего-то) накопленных данных в файлах архивов, программа СПК, после загрузки CODESYS, начинает "шевелиться" только по прошествии более 50 секунд... это пипец, больше сказать нечего. Т.е. 50 секунд визуализация "стоит", основная программа "стоит", я из-за этого даже стартовую визуализацию с задержкой оформить не могу. Опять же возвращаемся к вопросу целесообразности данного компонента, на этот раз аналога, если с такой его работой, проще использовать трассировки.
2. С изменением системного (СПК) времени тоже атас. Любые устройства с RTC, которые не синхронизируются с источником эталонного времени, имеют свойство, через определенные интервалы, показывать его (время) неправильно, соответственно, когда-то придется его изменить. Ну и что, скорректировал время/дату и с временными метками текущих и архивных данных начинается кавардак, причем текущие временные метки постепенно "лечатся", архивные нет. Что будет происходить с временными метками при постоянной автоматической синхронизации СПК, например, с сервером NTP, караул полный? Что в таком случае делать, при изменении системных времени/даты удалять файлы архивных данных, чтобы они начинали писаться с нуля без искажений? Я "как послушная маня" сделал органы редактирования времени/даты для пользователя, чтобы не бегать самому за тридевять земель с такой примитивной проблемой, пришлось "отмену запуска" делать. У встроенного компонента данные портятся при перезагрузке оного не вовремя, у OVT при редактировании системных времени/даты. Это ирония какая-то?
3. Просмотр архивных данных. Почему в OVT нельзя было сделать селектор временного интервала по примеру оригинального компонента, пускай не всего, но хотя бы 10мин/30мин/60мин? Почему нельзя было сделать возможность выбирать и просматривать архивные данные диапазоном (с соответствующими селекторами), листать по (даже) 50 минут назад двое-трое суток - это просто мученье. А если нужно неделю отмотать?
4. В РЭ СПК210 вы пишете, что рекомендуется использовать журналируемЫЕ файловЫЕ системЫ (во множественном числе) и тут же, что NTFS только для чтения. Тупой вопрос - какую же журналируемую файловую систему мне тогда выбрать? Наверное, Ext4 попробую, но это не точно, потому как форматирование SD-карты в конфигураторе (при загрузке) только в FAT32...рука-лицо... CODESYS "крутящийся" на Linux'е не умеет форматировать SD-карту в формат "родной" файловой системы?

Одно лечится, другое калечится. Честно, вот проще и быстрее было остаться на встроенном компоненте, "прикрутить" к шкафу бесперебойник с замком и года 2-3 к нему не подходить.

В общем не знаю... уже проект заканчивать нужно, а я с граблей слезть не могу. Это был, походу, крайний СПК, который я взял в руки.

1.jpg

И выдайте сборщикам динамометрические отвертки, все корпусные болты сорваны.

2.jpg

[МихаилГл]

А я против того, что всё то, что нужно реализовывать через скада и базы данных, пытаются втолкнуть в плк (спк). Зачем!?
Да, есть встроенная визуализация (для плк), но это не делает его полноценной системой для хранения исторических трендов и пр.