Hmi визуализация

[Milchuk]

Спасибо за ответ.
Использую ОВЕН ПЛК 150 У.М. CoDeSys 2.3.8.1

Зачем? Здесь никакие файлы стираться и не должны, просто затираются старые записи по кольцу.

Я пробовал вести один файл и устанавливал удаление данных после 1 часа. Безрезультатно - за 3 часа наблюдений файл пропорционально рос в размере.
Пробовал заводить новый файл по достижении определённого числа записей - файл заводится, но старые данные не стираются.
По вопросу с маркером период обновления данных трэнда был выбран примерно равным одному пикселю горизонтального масштаба, а отставание равнялось 20-30 сэмплам. ( Хотя почему бы маркеру не индицировать и апроксимированную величину?)
По вопросу с линией выходил из положения - в случае, если она горизонтальная, заменял прямоугольником. Постараюсь воспроизвести.

[Игорь Петров]

Использую ОВЕН ПЛК 150 У.М. CoDeSys 2.3.8.1
Я пробовал вести один файл и устанавливал удаление данных после 1 часа. Безрезультатно - за 3 часа наблюдений файл пропорционально рос в размере...

OK, спасибо за информацию. Проверим.

Хотя почему бы маркеру не индицировать и апроксимированную величину?

Как, подумайте? Маркер – это переменная в памяти ПЛК (именно это и требовалось при реализации этой фишки), интерполяция происходит уже наверху в ПК. В памяти ПЛК есть только замеры.
Прямо с графика можно снять значение в HMI. Оно будет точным, если его сразу тут моментально и отображать (так сделано в трассировке). Если же его переслать в ПЛК, затем вернуть в компьютер, то за это время маркер уедет.
Чтобы было и точно и доступно в ПЛК, нужно интерполяцию делать внутри ПЛК. См. выше описание стратегии развития визуализации в CoDeSys V3.
В V2.3 точности считывания значения по маркеру можно добиться при медленной (относительно частоты семплирования) скорости нарастания тренда.
Никакой ошибки тут нет, возможно не достаточно подробно описано в документации, обязательно добавлю в след. редакции.

[Milchuk]

Может я туплю...!?
Насколько я понимаю, данные о положении маркера рождаются в HMI и передаются в контроллер, где из массива данных, по-вашему, выбирается ближайшая точка, её значение передаётся переменной маркера. Так почему в этом месте не взять две ближайшие точки и не подсчитать, скажем, линейно аппроксимированное значение?
Но, в общем то не критично. Повторюсь, меня больше удивило несоответствие значений с картинкой графика, и это не объясняется попаданием маркера между точками сэмплирования.

[Игорь Петров]

...почему в этом месте не взять две ближайшие точки и не подсчитать, скажем, линейно аппроксимированное значение?

Где гарантия, что оно будет ближе к реальности? Между замерами вполне мог быть выброс. Сейчас маркер честно сообщает значение, которое контроллер некогда намерил. Его можно использовать в программе, оно совпадет с неким значением, которое реально использовалось в нашей программе. Сейчас маркер позволяет организовать обратную связь отображения с контроллером. Формируя выдуманное значение, мы лишаемся этой возможности.

Дискретная природа периодических отсчетов предполагает, что для адекватного отображения значение наблюдаемой переменной не должно существенно изменяться между замерами (что описывает теорема Котельникова). В противном случае кривая вообще не будет соответствовать действительности. Этот факт + движение графика и конечная скорость обмена данными (ПЛК-ПК) определят точность самого отображения и естественно данных маркера. Это нужно четко понимать и правильно использовать. Никакой аппроксимацией из линейки не сделать микрометр.

Для изучения быстрых процессов с считыванием значений маркеров непосредственно с графиков в CoDeSys есть инструмент Sumpling Trace, позволяющий снимать значения переменных в каждом рабочем цикле. При необходимости, здесь можно задать триггерное событие, по которому данные будут сфотографированы с нужной пред и после историей. Т.е. мы можем использовать данный инструмент как 'черный ящик' встроенный в ПЛК.