- Общий
- Общие вопросы
-
Ошибки
Версия 4.7.3.50 Ошибки и вопросы (в картинках)
Добрый день!
1-я ошибка.
Для получения столь неприглядной картины всего лишь надо установить курсор мыши в область "Лицензия SimpLight"
2-я ошибка
Приобрели лицензию на использование SIMP OPC сервера.
После введения ключа и активации лицензии от надписи в заголовке окна "SIMP OPC сервер (Тегов: 11) - ДЕМОНСТРАЦИОННАЯ ВЕРСИЯ" осталась надпись "SIMP OPC сервер (Тегов: 11)".
Полагаю, что надписи "Тегов: 11" не должно быть после активации лицензии. Или я не прав?
И один вопрос.
Не могли бы Вы дать консультацию по полю "Агрегатор" в источнике данных Редактора отчета.
Попытки задействовать это поле (максимальное значение, среднее значение, ...) приводят к тому, что от отчета остается одна строка (что и ожидается) , но в качестве значения (в этой оставшейся строке) выступает ноль.
Попытки найти пояснения использования "Агрегатора" в документации на FastReport не увенчались успехом.
Буду благодарен за любой ответ (хотя бы просто пришлите ссылку - где почитать)
И последний вопрос
Я уже обращался по поводу отрицательного опыта использования режима записи "По изменению"
есть ли какие подвижки? в расследовании этого явления?
напоминаю: зона 1 - установлен режим "по изменению", зона 2 - установлен режим "по таймеру"
С уважением, Кондратенко Анатолий
Новочеркасск
Сервис поддержки клиентов работает на платформе UserEcho
Да, ошибка имеет место быть, исправим. Спасибо
Заголовок отображает кол-во каналов в конфигурации. Возможно не обновилась надпись в заголовке, проверим.
Как работает агрегатор в отчетах - Есть диапазон - (Начало диапазона - Конец диапазона), далее при составлении отчета этот диапазон дробится на интервалы (указанные в настройках), т.е к примеру указали диапазон сутки, интервал указали 1 час, генератор отчётов считает из БД данные за 1 час и к этому интервалу применит выбранный агрегатор - к примеру первое значение, т.е. из считанных данных за 1 час будет взято для отчета первое значение этой выборки. И т.д. пока не будет достигнут конец диапазона.
Какие входные данные (начало, конец диапазона, и интервал использовали для построения отчета?)
Смоделировать ситуацию в лабораторных условиях не получается, в одном из постов где Вы ранее описывали эту проблему я Вам отвечал:
файл csv был выслан 17 сен в 16:19
Анатолий Викторович, уточните Вы отправляли файл на почту? Просмотрел сейчас всю почту за 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) из всего табуна вопросов по этому поводу сформулирую только один: кому? зачем? почему? может понадобиться сохранять данные "при плохом качестве сигнала"?
День добрый.
Спасибо).
Справка в доработке. Английская версия справки в русской версии, наша недоработка поправим. Спасибо.
Поясню. Ранее при сохранении данных в БД сохранялись только сами данные, но не сохранялось качество сигнала, т.е. данные сохранялись только при "хорошем" качестве сигнала, что не вполне отображало всю полноту процесса. После замены движка БД в последних версиях, в БД сохраняются как сами данные так и признак качества этих данных. При нестабильной связи с устройством, данные записанные в БД будут отображать всю нестабильность линии, в связи с чем график построенный по этим данным будет достаточно "рваный", в связи с этим после многочисленных просьб наших пользователе, сделали режим совместимый с моделью записи прошлых версий, т.е. записывать в БД только при "хорошем" качестве сигнала.
еще немного поворчу:
1) " ... Ранее ... данные сохранялись только при
"хорошем" качестве сигнала ..." - прям успокоили (без иронии, вполне серьезно), а то ужаснулся: неужели же раньше писался всякий шум наряду с хорошим сигналом
2) "... что не вполне отображало всю полноту процесса ..." тут не буду спорить, поскольку не являюсь
специалистомлюбителем разбираться, что там происходит в каналах связи, а просто замечу от лица "простых" пользователей: "... вы думаете нам царям легко..." еще и разбираться в качестве сигнала. Для себя давно вывел правило ("...и опыт, сын ошибок трудных...") при составлении скриптов: "скрипт первым делом должен проверить качество сигнала - и при плохом качестве не должен работать!". И это правило ни разу меня не подвело.3) "... в последних версиях, в БД сохраняются как сами данные так и признак качества этих данных ..." - значит мне не показалось, что данные "задваиваются" в базе данных, оказывается стал записываться и признак качества
4) "... график построенный по этим данным будет достаточно "рваный"..." - вот это заметил и даже пытался анализировать, какой прибор стал "тормозить" и мешает получать сигналы вовремя от других приборов.
5) "... после многочисленных просьб наших пользователе, сделали режим совместимый с моделью записи прошлых версий ..." - вот тут горячо поддержу ваших пользователей, настолько горячо, что осмелюсь предложить этот режим сделать постоянным (тем более, что он и был им до "смены движка"). То есть пункт "Сохранение только при хорошем качестве":
а) либо сделать постоянно "выбранным", а не "опциональным"
б) либо переименовать в "Сохранение при любом качестве" и сделать опциональным
Таким образом будут соблюдены права большинства (ИМХО) ваших пользователей, которым "до лампочки", что там творится в канале. И продвинутые пользователи, которым будет важно проанализировать качество получаемого сигнала не останутся без внимания (смогут включить "Сохранение при любом качестве")
Ну и на
посошокпоследок, система Ваша замечательная, я всегда это говорил и говорю, но вот документация на Вашу систему ... (нет слов). Ну не будьте Вы столь скромными в этом аспекте. "Вы думаете нам царям легко", что бы еще и догадываться в том, почему оно вот тут... так...Ок. Подумаем.
Замечание справедливое. Работаем в этом направлении. Спасибо.
Добрый день!
Решил (на свою голову) по максимуму использовать возможности системы SimpLight и перевести часть приборов OWEN с протокола OWEN на MODBUS. В результате тут же наткнулся на ошибку, ну как ошибку - скорее очепятку:
Теперь вопросы:
1) где можно посмотреть логи работы MODBUS ?
2) в справке значительное место уделено некоему "Simulator MODBUS", только ни слова не сказано "шо це оно таке?", то есть что это за утилитка? кто автор? где ее можно взять?
3) настройка параметров работы по MODBUS
Смотрю я на эту красоту и понимаю, что ничего не понимаю: подхожу я под пункт "по умолчанию" или нет? Открываю справку SimpLight, вуаля, все эти загадочные названия просто перечисляются и всё, ни слова пояснения. Как тут не вспомнить старика Лема: "...СЕПУЛЬКИ — важный элемент цивилизации ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКАРИИ...".
Открываю инструкцию на ТРМ200:
Ясность не наступает. Так подходит параметр (тип float32) ТРМ200 под пункт "Default" или нет?
День добрый.
Вот ссылка http://www.plcsimulator.org/
Тип данных - Default - это Word, т.е. стандартный тип для modbus.
Порядок байт - Default - это BE.
Можно все гораздо проще, в СИМП есть перднастроенные шаблоны для приборов OWEN.
Вы использовали шаблон для настройки прибора?
Благодарю за оперативный ответ.
Попытка связаться с ТРМ202 (только такой есть под рукой свободный) по MODBUS не приводит ни к чему (хорошему, плохое оно само как-то получается):
в тесте каналов видим только Timeout
то есть прибор не хочет отвечать, идет только запрос
в чём может быть проблема?
1. Проверить сетевые настройки прибора.
2. Проверить какой протокол выбран на самом приборе
3. Проверить поддерживает ли прибор работу по модбасу
4. Проверить настройки узла, номера прибора, выбранный протокол и т.д.
Потребовался бубен, поскольку никакими материальными символами (в смысле словами) это не объясняется: прибор ни в какую не хотел отзываться, пока не перешли на протокол ОВЕН (убедились, что на этом протоколе ТРМ202 работает) и вновь вернулись на MODBUS-RTU - и всё заработало.
Кстати опять нашли Ваши "пасхальные яйца" в шаблонах приборов ОВЕН (вы сознательно, наверное, так шутите над своими пользователя): в приборе ТРМ202 прописан по умолчанию адрес 216. И это обнаружилось не сразу!
Замечательно
Ну тут никакой "пасхалки" нет, адрес сформирован на стадии создания шаблона, по идее при настройки - Вы должны поменять адрес на необходимый, и все.
Нет - это как раз "пасхальные яйца"! В шаблонах на приборы ОВЕН адреса разбросаны в безобразном порядке( группа Регуляторы - 8, 9, 1, 1, 216 ). Вот этим мы и отличаемся от импортных инженеров - тем, что не задумываемся над тем, как сделать лучше (безопасней, удобней и т.д.) для пользователя. А если уставший (замордованный, торопящийся) пользователь забыл исправить этот параметр... хорошо, если в цепи нет прибора с таким адресом, а если он уже есть... пойди потом найди ошибку. А вот если бы мы не рассуждали в терминах "...должен поменять...", а прописали бы в шаблоне единый адрес 0 (или другой недопустимый адрес в MODBUS), а еще лучше - по аналогии с атрибутом placeholder в HTML - прописать текстовое поле "адрес прибора 1-255". Вот тогда пользователь и захочет, а не ошибется (попадет в цикл поиска ошибок), а пропишет нужный ему адрес. А если пользователь совсем начинающий, то текстовое поле любезно подскажет ему допустимый диапазон адресов, чтобы он не мучался выбором.
А пока вот так и живем: пользователь "... должен поменять....". Ничего пользователь не должен - пользователь может прописать (ввести, указать, заполнить).
Не думаю, что Вы меня поняли. Ну да ладно, это так - мысли вслух...
Спасибо. Мы услышали Ваше мнение.
И снова, здравствуйте!
Мне вот просто интересно, зачем SIMP OPC назначили ровно такую же иконку, что и "Конфигуратору каналов"?
День добрый.
Да, иконка на ОРС такая же. В будущем сменим.