0
Исправлен

Версия 4.7.3.50 Ошибки и вопросы (в картинках)

Кондратенко Анатолий Викторови 4 недели назад в Общие вопросы обновлен СИМП Лайт (тех.поддержка) 6 дней назад 16

Добрый день!

1-я ошибка.

Для получения столь неприглядной картины всего лишь надо установить курсор мыши в область "Лицензия SimpLight"

2-я ошибка

Приобрели лицензию на использование SIMP OPC сервера.
После введения ключа и активации лицензии от надписи в заголовке окна "SIMP OPC сервер (Тегов: 11) - ДЕМОНСТРАЦИОННАЯ ВЕРСИЯ" осталась надпись "SIMP OPC сервер (Тегов: 11)".
Полагаю, что надписи "Тегов: 11" не должно быть после активации лицензии. Или я не прав?

И один вопрос.

Не могли бы Вы дать консультацию по полю "Агрегатор" в источнике данных Редактора отчета.
Попытки задействовать это поле (максимальное значение, среднее значение, ...) приводят к тому, что от отчета остается одна строка (что и ожидается) , но в качестве значения (в этой оставшейся строке) выступает ноль.
Попытки найти пояснения использования "Агрегатора" в документации на FastReport не увенчались успехом.
Буду благодарен за любой ответ (хотя бы просто пришлите ссылку - где почитать)


И последний вопрос

Я уже обращался по поводу отрицательного опыта использования режима записи "По изменению"


есть ли какие подвижки? в расследовании этого явления?
напоминаю: зона 1 - установлен режим "по изменению", зона 2 - установлен режим "по таймеру"

С уважением, Кондратенко Анатолий
Новочеркасск










На рассмотрении
День добрый.
Для получения столь неприглядной картины всего лишь надо установить курсор мыши в область "Лицензия SimpLight"

Да, ошибка имеет место быть, исправим. Спасибо

2-я ошибка
Приобрели лицензию на использование SIMP OPC сервера.
После введения ключа и активации лицензии от надписи в заголовке окна "SIMP OPC сервер (Тегов: 11) - ДЕМОНСТРАЦИОННАЯ ВЕРСИЯ" осталась надпись "SIMP OPC сервер (Тегов: 11)".
Полагаю, что надписи "Тегов: 11" не должно быть после активации лицензии. Или я не прав?

Заголовок отображает кол-во каналов в конфигурации. Возможно не обновилась надпись в заголовке, проверим.

И один вопрос.
Не могли бы Вы дать консультацию по полю "Агрегатор" в источнике данных Редактора отчета.
Попытки задействовать это поле (максимальное значение, среднее значение, ...) приводят к тому, что от отчета остается одна строка (что и ожидается) , но в качестве значения (в этой оставшейся строке) выступает ноль.
Попытки найти пояснения использования "Агрегатора" в документации на FastReport не увенчались успехом.
Буду благодарен за любой ответ (хотя бы просто пришлите ссылку - где почитать


Как работает агрегатор в отчетах - Есть диапазон - (Начало диапазона - Конец диапазона), далее при составлении отчета этот диапазон дробится на интервалы (указанные в настройках), т.е к примеру указали диапазон сутки, интервал указали 1 час, генератор отчётов считает из БД данные за 1 час и к этому интервалу применит выбранный агрегатор - к примеру первое значение, т.е. из считанных данных за 1 час будет взято для отчета первое значение этой выборки. И т.д. пока не будет достигнут конец диапазона.


Какие входные данные (начало, конец диапазона, и интервал использовали для построения отчета?)


И последний вопрос
Я уже обращался по поводу отрицательного опыта использования режима записи "По изменению"

есть ли какие подвижки? в расследовании этого явления?
напоминаю: зона 1 - установлен режим "по изменению", зона 2 - установлен режим "по таймеру"

Смоделировать ситуацию в лабораторных условиях не получается, в одном из постов где Вы ранее описывали эту проблему я Вам отвечал:

Анатолий Викторович, сможете предоставить обезличенные данные по "больному" каналу, в виде экспорта этого канала в csv за интервал с 13 до 16 часов?

Анатолий Викторович, уточните Вы отправляли файл на почту? Просмотрел сейчас всю почту за 17 сент. не нашёл письма от Вас.

17 сентября было оправлено ТРИ письма: в 15:26, в 15:46, 16:19

в ответ на тот адрес с которого приходят письма - "noreply@simp.userecho.com"

Анатолий Викторович, продублируйте письма на наш основной почтовый ящик simp@simplight.ru.

Адрес noreply@simp.userecho.com не используется для получения писем, это адрес для автоматически генерируемых системой userecho.com писем с уведомлениями.

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

а теперь устанавливаем режим "По изменению"

День добрый, Анатолий Викторович.

Алгоритмы записи по событию дорабатываются. Сможете прислать на simp@simplight.ru CSV файлы с данными представленными на графиках, для режима по таймеру и по событию, данные с реальных объектов позволяют рассмотреть и учесть все возможные варианты для алгоритмов обработки данных.

Ещё уточните - при стратегии записи по изменению, "мертвая зона" нулевая, или указано какое-то значение? 

Добрый день!

Ответ: значение параметра "мертвая зона" = 1

Вопрос о режиме сохранения в базе "В пределах шкалы":
Посмотрел я на этот параметр и сказал "это хорошо".

Решил использовать эту возможность (казалось бы польза очевидна), но не всё то .... 
Столкнулся с такой коллизией:
1) есть простейший параметр установки температура

2) всегда там была шкала 0 - 200 градусов, и на мнемосхеме всегда отражалась реальная температура (даже когда установка выключена)
3) чтобы отсечь запись в базу "лишних" значений (когда установка простаивает) при использовании политики "В пределах шкалы" пришлось изменит диапазон шкалы на 35 - 200 градусов, иначе режим "В пределах шкалы" бесполезен ( в данном конкретном случае )

4) и вот получается, что на мнемосхеме искажается реальная информация

Посмотрел я на дело рук своих и сказал "это плохо"

Вывод: режим записи "В пределах шкалы"пока годится только для фильтрации "помех"
Пожелание: возможно ли дополнить список режимов сохранения в базу? (требуется режим записи при превышении указанного значения)

День добрый.

Отправил Ваше предложение на рассмотрение. Спасибо.

Добрый день!

Благодарность: вы волшебники! ... теперь (в версии 4.7.3.70) график уставки рисуется хорошо даже в режиме "По изменению". Молодцы!

Вопросительное брюзжание:
1) в новой версии (4.7.3.70) появился новый пункт "Сохранение только при хорошем качестве". Появились вопросы. Нажимаю "Справка". Попадаю на английскую версию справки. Почему? Может просто я не часто туда обращался и не отследил новые веяния. Ну и кстати, в справке по этому поводу никаких пояснений нет.



2) из всего табуна вопросов по этому поводу сформулирую только один: кому? зачем? почему? может понадобиться сохранять данные "при плохом качестве сигнала"?

Исправлен

День добрый.

Благодарность: вы волшебники! ... теперь (в версии 4.7.3.70) график уставки рисуется хорошо даже в режиме "По изменению". Молодцы!

Спасибо).

Вопросительное брюзжание:
1) в новой версии (4.7.3.70) появился новый пункт "Сохранение только при хорошем качестве". Появились вопросы. Нажимаю "Справка". Попадаю на английскую версию справки. Почему? Может просто я не часто туда обращался и не отследил новые веяния. Ну и кстати, в справке по этому поводу никаких пояснений нет.

Справка в доработке. Английская версия справки в русской версии, наша недоработка поправим. Спасибо.

2) из всего табуна вопросов по этому поводу сформулирую только один: кому? зачем? почему? может понадобиться сохранять данные "при плохом качестве сигнала"?

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

еще немного поворчу:

1) " ... Ранее ... данные сохранялись только при
"хорошем" качестве сигнала  ..." - прям успокоили (без иронии, вполне серьезно), а то ужаснулся: неужели же раньше писался всякий шум наряду с хорошим сигналом

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

3) "... в последних версиях, в БД сохраняются как сами данные так и признак качества этих данных ..." - значит мне не показалось, что данные "задваиваются" в базе данных, оказывается стал записываться и признак качества

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

5) "... после многочисленных просьб наших пользователе, сделали режим совместимый с моделью записи прошлых версий ..." - вот тут горячо поддержу ваших пользователей, настолько горячо, что осмелюсь предложить этот режим сделать постоянным (тем более, что он и был им до "смены движка"). То есть пункт "Сохранение только при хорошем качестве":
  а) либо сделать постоянно "выбранным", а не "опциональным"
  б) либо переименовать в "Сохранение при любом качестве" и сделать опциональным
Таким образом будут соблюдены права большинства (ИМХО) ваших пользователей, которым "до лампочки", что там творится в канале. И продвинутые пользователи, которым будет важно проанализировать качество получаемого сигнала не останутся без внимания (смогут включить "Сохранение при любом качестве")

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

5) "... после многочисленных просьб наших пользователе, сделали режим совместимый с моделью записи прошлых версий ..." - вот тут горячо поддержу ваших пользователей, настолько горячо, что осмелюсь предложить этот режим сделать постоянным (тем более, что он и был им до "смены движка"). То есть пункт "Сохранение только при хорошем качестве":
а) либо сделать постоянно "выбранным", а не "опциональным"
б) либо переименовать в "Сохранение при любом качестве" и сделать опциональным
Таким образом будут соблюдены права большинства (ИМХО) ваших пользователей, которым "до лампочки", что там творится в канале. И продвинутые пользователи, которым будет важно проанализировать качество получаемого сигнала не останутся без внимания (смогут включить "Сохранение при любом качестве")

Ок. Подумаем.

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

Замечание справедливое. Работаем в этом направлении. Спасибо.

И снова, здравствуйте!
Мне вот просто интересно, зачем SIMP OPC назначили ровно такую же иконку, что и "Конфигуратору каналов"?

День добрый.

Да, иконка на ОРС такая же. В будущем сменим.

Сервис поддержки клиентов работает на платформе UserEcho