Отчеты

[Антон Сидоров]

Здравствуйте. Можете выслать папку отчетов "..\Simple-Scada 2\Project\ИМЯ_ПРОЕКТА\Reports", или целиком папку проекта на support@simple-scada.com для проверки?

Отправил.

[Simple-Scada]

Спасибо. Нашли причину проблемы в несоответствии типов при преобразованиях переменных. Чтобы исключить ошибку смените тип данных у переменной PV4 в словаре отчета как показано на скрине во вложении. В ближайшем обновлении исключим эту проблему и тип не придется менять вручную.

[Антон Сидоров]

to Simple-Scada

Ок. Проверим.
Локализуем еще странности - сообщим.
Спасибо за информацию.

[АО.МХЗ]

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

[Simple-Scada]

АО.МХЗ, если вариант с "тяжелым" запросом исключается (или с запросом за чрезмерно большой интервал времени), то причину нужно искать в других вычислениях которые могут использоваться при построении отчета, либо в неправильном использовании источников данных. Пришлите папку с проектом на support@simple-scada.com для проверки, если возможно.

[АО.МХЗ]

Отправил

[Simple-Scada]

Не можем в точности проверить работу вашего проекта т.к. при работе через скаду Вы используете вызов хранимых процедур, например "call report(...)", а в системе отчетов используется обычный код. Вы уверены что код запроса в отчетах и в хранимых процедурах полностью совпадает? Также у Вас в отчете (мы рассматривали отчет "349_levels_ontime" есть два источника, соответственно при построении будут выполняться два отдельных запроса, сначала для источника "ИсточникДанных1", затем для источника "ИсточникДанных1Копия". Отчет не будет выведен на экран пока не выполнятся оба запроса.

Почему Вы не используете вызов хранимой процедуры в отчете, также как это делается в скриптах скады?
Если запустить редактор отчетов (Reports.exe), двойным кликом открыть источник данных, а затем в открывшемся окне нажать кнопку "Выполнить" (см. скрин во вложении), то запрос выполняется быстро? (проверьте таким способом все источники данных в отчете).

[АО.МХЗ]

Угу. Источник данных забыл... Но для чистоты эксперимента, отчет 349_outcome очень простой. sql таблица маленькая - 100 кб. Запрос  отрабатывает в базе мгновенно. Но отчет грузится в первый раз при запуске программы ну совсем долго. После того, как прогрузился, остальные запуски выполняются в приемлемое время. Хранимка report  и скрипт в отчете 349_levels_ontime идентичны.

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

Почему Вы не используете вызов хранимой процедуры в отчете, также как это делается в скриптах скады?

Так сложилось. Сначала хранимки не было. Но когда озаботился скоростью, решил проверить как система будет отрабатывать выгрузку данных в таблицу и как в отчет. Текст запроса скопировал в хранимку, т.к. сил написать 30 строк sql в редакторе скриптв не было, и написал процедуру выгрузки в таблицу (кнопка быстрый отчет).  Таблица заполняется практически мгновенно. Отчет - тупит.

[Simple-Scada]

АО.МХЗ, ответили Вам по e-mail. Также хотелось бы получить ответ на этот вопрос:

Если запустить редактор отчетов (Reports.exe), двойным кликом открыть источник данных, а затем в открывшемся окне нажать кнопку "Выполнить" (см. скрин во вложении), то запрос выполняется быстро? (проверьте таким способом все источники данных в отчете).

[AutoCY]

День добрый!

На данный момент времени использую отчет по циклам, одной из целей которого заключается в формировании отрезков времени наработки оборудования. Возник следующий вопрос:
- Предположим оборудование включалось пять раз в течении первой смены. Во время начала второй смены - оно находилось в отключенном состоянии. Здесь отчеты по циклам работаю идеально.
- Во время начала второй смены оборудование находилось во включенном состоянии. Отчет по циклам посчитает четыре цикла, отбросив пятый (как не сформированный цикл). Возможно ли в данном случае посчитать время работы четырех циклов плюс работу пятого, но не завершенного до точки выборки? Может стоит для данной задачи воспользоваться другим типом отчета?

Спасибо за ответ.

[Simple-Scada]

Здравствуйте.

Возможно ли в данном случае посчитать время работы четырех циклов плюс работу пятого, но не завершенного до точки выборки? Может стоит для данной задачи воспользоваться другим типом отчета?

Подсчитать время наработки можно средствами скады, используя процедуру ArchiveTimeOn. Результат вычисления будет записан в другую переменную, которую Вы укажете. Но как время наработки должно быть отображено в отчете? Как отдельное поле с временем наработки за смену?

[TeNQ]

Здравствуйте.
Пытаюсь создать динамический отчет и пока не получается. При работе в проекте он не создается. И у меня возникла пара вопросов. При запущенном проекте, я нажимаю "Получить данные" в Редакторе отчетов и получаю ошибку - "Файл не найден ...". Что это? При этом, нажимаю "предварительный просмотр" и отчет строится с данными.
P.S. С этим вопросом разобрался. У переменной, которую я создал для получения ID в третьей колонке было включено масштабирование от 0 до 100 - создавал ее дублированием и не заметил. Поэтому третья колонка была пустой, т.к. ID очевидно не находился. Убрал масштабирование, ошибка пропала, все три колонки заполнились данными. Но отчет так и не появляется при создании в проекте - буду дальше разбираться.
Второй вопрос. Я удаляю динамическую колонку vrTRM_Input1 из источника данных в словаре. Но захожу в Действия-Редактор ссылок и там привязка остается. Удаляю и здесь. Пытаюсь добавить снова переменную vrTRM_Input1 как динамическую колонку в тот же источник и получаю ошибку - "Необрабатываемое исключение.." А это что?

[Simple-Scada]

Здравствуйте.

Может прислать текущую версию проекта и отчетов в которых возникают ошибки?

[TeNQ]

Да, вышлю. Но у меня возникли другие вопросы. Во-первых, я запустил тот же самый проект, с тем же самым отчетом, который не создавался из проекта. И он создался. А ведь ничего не изменилось, кроме того что я выкл./вкл. компьютер.
По отчету. Источник данных периодический некорректно отображает данные. Точнее абсолютно корректно читает их из БД. Я помню и раньше так было, но я не согласен что это правильная работа системы отчетов. Вы то пишите в БД используя алгоритмы сжатия. Мне как пользователю видится эта система как черный ящик, мне все равно что там происходит. На выходе должны быть восстановленные данные соответствующие оригиналу. Почему для визуального отображения тренда вы восстанавливаете данные. Я специально снял ролик с визиром. А для отчета пишите как "есть". Постройте по вашим данным из отчета тренд и вы поймете какая ерунда получилась.
И еще один вопрос. По визиру в момент времени 10.41.07 значение выхода 99.29. В отчете же последнее значение за этот период 100. Как ни округляй из 99.29 ста не получишь.

[Simple-Scada]

Убрал масштабирование, ошибка пропала, все три колонки заполнились данными. Но отчет так и не появляется при создании в проекте - буду дальше разбираться.

Учитывайте, что т.к. у Вас отчет с динамическими колонками, то перед построением отчета Вы должны сначала в переменные vrTRM_Input1, vrTRM_Output1 и vrTRM_Setpoint записать ID тех архивных переменных, которые требуется отобразить в отчете. И только потом вызывать построение отчета. Иначе переменные могут быть не найдены и построение не удастся.

Источник данных периодический некорректно отображает данные. Точнее абсолютно корректно читает их из БД.

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

Отчет получили, сейчас проверяем. Запустили проект. Через скаду назначили переменным [vrTRM_Input1, vrTRM_Output1, vrTRM_Setpoint] ID архивных переменных [vrTRM1_Input1, vrTRM1_Output1 и vrTRM1_Setpoint], т.е. [8, 11, 35]. У архивных переменных меняли значения, в том числе задали 99.29. Задали интервал времени для отчета через переменные vrTRM_StartIn и vrTRM_EndAt и вызвали построение отчета. Значения в отчете отображаются корректно: 99.29 не округляется.