Не работает исторический режим

Содержание

Тема: СП 270 Исторический график не строится.
СП 270 Исторический график не строится.
Не работает исторический режим

Тема: СП 270 Исторический график не строится.

Опции темы

Отображение

СП 270 Исторический график не строится.

СП270 Перестала строить исторический график. После загрузки проекта вроде строит, но через пару минут пропадает и вместо времени и даты пишет FF-FF-FF.
На другой панели этот проект отлично работает. Может как-то перепрошить или это память полетела.

Возможно:
а) в проекте случайно используются регистры PFW из области отведенной под графики.
б) может это и флеш память исчерпала ресурс.
По варианту а) проект не работал бы и в другой.
По варианту б) попробовать выделить для графиков другую область регистров PFW
Захват-1.png

Можно посоветовать, от куда и до куда можно взять PFW, чтобы не набедокурить потом.

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

Хороший вопрос.
Последний доступный адрес PFW = 1 000 000.
При включенном авторазмещении для графиков будут доступны регистры от заданного в настройках параметра «число PSW» до 1 000 000
Захват-1.png
По умолчанию «число PSW»=1024, следовательно доступно 1 000 000 -1 024=998 976 регистра.
Много это или мало? Потребность в регистрах для графиков и выборок http://www.owen.ru/forum/showthread. l=1#post139595
Для исторического графика нужно
N =4+(n+1)*( K w+2* K dw+6) регистров
где:
K w-количество переменных Word
K dw—количество переменных DWord
n-количество записей в выборке, заданное в ее настройках «всего», см рисунок
Захват-2.png

Таким образом, если в историческом графике одна переменная Word, то в 998 976 регистрах поместятся
(998 976-4)/7 — 1= 142 709 точек.
К стати, может причина у Вас именно в превышении числа точек? Ведь конфигуратор при включенном авторазмещении позволяет загрузить в панель графики с существенным превышением количества точек. Где-то только после того, когда количество используемых PSW достигнет

272000 точки) будет ругаться на не хватку памяти.
Захват-1.png

Только вот скорей всего точки с PSW> 1 000 000 не будут сохраняться и не будут отображаться.
Таким образом от куда и куда двигать нужно смотреть по обстоятельствам, что бы для последней точки графика PSW не превышал 1 000 000

ЗЫ. Про «Только вот скорей всего точки с PSW> 1 000 000 не будут сохраняться и не будут отображаться.» я наверно поспешил.
Если график начинается в PFW с адресом 14:23 .

Источник

Не работает исторический режим

Вот и у меня дошел ход до исторических данных, сразу возникли вопросы.
Лоджик 3.32.0114, SMH4 — форматнутый.

Исходное положение:
Блок History пишет 5 параметров по триггеру.
Загружаем программу в контроллер, делаем триггером 1 запись.
Формируем отчет — все хорошо, видим одну запись.
Делаем триггером вторую запись.
Формируем отчет — все хорошо, видим две записи.

Позишн намбер ту:
Та же программа, тот же блок, те же параметры по тому же триггеру.
В свойствах блока ставим использование фильтра «==» на один из параметров (с другими фильтрами не пробовал).

Загружаем программу в контроллер, делаем триггером 1 запись.
Формируем отчет(да, конечно, на входе для фильтра задаем правильное значение, чтобы нашлась именно нужная запись) — все НЕ хорошо. В начале таблицы видим четыре пустых строки, только поле дата/время заполнено, остальные поля пустые. И только пятой строкой идет наша единственная запись, которую мы сделали. Число на выходе Count соответствует числу строк — 5.

Делаем триггером вторую запись. Значения записываемых параметров другие.
Формируем отчет(да, конечно, на входе для фильтра задаем правильное значение, чтобы нашлась именно нужная запись) — все также НЕ хорошо, иногда еще хуже.

Далее имеем два варианта, закономерности проявления варианта 2 за пару-тройку десятков проб не уловил.
Вариант 1 — те же пустые 4 строки и под ними наша искомая.
Вариант 2 — те же пустые 4 строки, но под ними у нас теперь 2-3 строки, содержащих нужную нам запись(которая у нас всего одна такая вообще-то), все поля идентичны, кроме поля «дата/время» — в нем отличаются миллисекунды).
Отчеты смотрел в SMArt-овском диспетчере отчетов.

2. Вход row number.
Не уверен, что правильно понял из справки — это номер строки из сделанной для отчета выборки, значения из которой будут на выходах? Со смещением 2, то есть при значении на этом входе «0» выводятся значения из первой строки данных, которая в самом отчете числится под номером 2?
А как быть, если в выборке будет большое число строк и нужна будет строка с номером, который не влазит в int?

3. Другие косяки

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

— В SMArt-овском «Диспетчере отчетов» при просмотре отчета нажатие на Esc приводит не к закрытию отчета и возврату к списку отчетов, что было бы логично, а отрабатывает сразу настроенный на Esc выход из экрана диспетчера. Дико неудобно.

4. Хотелки
Раздельные функции создания выборки блоком History и записи файла отчета на носитель. Сделали выборку, нашли нужные данные, забрали их дальше в FBD для обработки — всё, сохраненный на носителе отчет не нужен. Если нужен, то по сигналу на отдельном входе записали.
Выходы со значением констант в блоке History.

Фильтры, как в History, для SMArt-овского исторического графика.

Это пока только то, что сразу бросилось в глаза с самого начала.

Эскейп в этом окне есть по умолчанию, ручное задание выхода должно было быть заблокировано. Поэтому у вас дабл эскейп получается. Запретим)

Добавлено через 29 минут

Фильтры, как в History, для SMArt-овского исторического графика.

У исторического блока есть режим который в справке называется «Функция по умолчанию». В этом режиме исторические данные из базы данных (не обработанные, как есть) поступают на выход блока
и могут быть использованы в FBD.

Нужно несколько функций: объединяйте несколько блоков в единую базу — в справке написано, как это сделать.

В силу того, что в результате выборки значений по переменной может быть несколько (массив значений, таблица значений), а выход для переменной у блока в этом режиме только один. Требуется как то получить доступ к остальным значениям. Для этого используется вход row number, число на этом выходе задает какой элемент из массива полученных данных будет выводиться на выходы значений и таймштампов блока.

Оперативная память в контроллере не бесконечна и драматически далека от памяти доступной для архива. Все данные выборки в принципе не могут быть загружен за раз. Поэтому функция работает с ограничениями, за раз она может загрузить максимум 1000 исторических значений, реальное же количество отобранных исторических значений выводиться на выход «count». Поэтому гипотетический максимум для row number будет 1000 (row = 0..999), а реальный максимум определяется значением на выходе «count».

1000 всегда влезет в int.

Тем не менее, ограничение в 1000 не должно смущать. Если в результате выборки получено настолько большое количество данных и нет уверенности, что в выборка пуста. Нужно взять таймштамп 1000-ой записи (row = 999), подать его на вход begin у блока и повторить выборку еще раз, получив доступ к следующей тысяче.

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

Всё так и работает. Хотеть уже сделанное — это как минимум странно Возможно вы путаете отчет и хранилище.

Добавлено через 55 секунд

Похоже какой-то косяк, будем исправлять.

Добавлено через 8 минут

Константы в историю не пишутся а записываются в отчет на момент его формирования, если нужно сохранять константы возможно задача поставлена некорректно и это не константы.

Добавлено через 9 минут

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

Арсений, вы неверно поняли слово «функция»в данном контексте.
Речь не идет о математических функциях обработки данных.
Речь о входе Select, который выполняет 3 действия(у которого три функции) — выборка, математика, создание отчета.

Это не так, и по справке и по факту. Или есть способ получить выборку в блоке без сохранения отчета? В справке такого не описано.

Не путаю.
По select-у создается отчет и сохраняется на носителе, неважно на каком — внутренняя память, USB или флешка. Внутренняя память контроллера это тоже носитель, просто внутренний, а не внешний. Вот управление этим сохранением файла с отчетом хотелось бы иметь отдельно от формирования выборки.

Вот это должно быть описано в справке, я такого там не видел. Может плохо смотрел. Кстати, эта 1000 не зависит от количества параметров? Это тысяча строк по 2-3-10-300 параметров в каждой или всего 1000 значений параметров(если в одной записи 100 параметров, то ограничимся 10 записями)?

Но ведь в историческом графике внутри работает все тот же History, верно? Почему бы не вывести этот функционал History в смарт?

Да там кроме History и диспетчера отчетов в смарте больше ничего и нет, прикладываю.

Чудеса на виражах — сегодня в отчете не 4, а только 2 лишние пустые строки образуются.

Два блока. Один создаёт отчёт (в нём это указано — стоит галочка), другой нет (в нём это не указано — галочка не стоит). Блоки запараллелены — входы данных и строба имеют один источник (в справке есть об этом).

Можно три блока, 4, 10, 20. Они будут работать с одной и той же БД. Реализовывать разные фукнции и можно даже отчёты разных видов. Один во внутреннюю память, два других на флешку.

Похоже у вас не уложилось, что блоки умеют работать расшаривать архив, т.е. БД с данными.

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

Можно и так, а можно эту галочку и вытянуть как отдельный вход блока. Было бы удобно, и не надо было бы плодить лишние сущности на поляне.

И еще пара хотелок к этому блоку образовалась:
— объединение фильтров не только по «И» но и по «ИЛИ», на выбор
— отдельный вход для выбора этого типа объединения
— дополнить фильтры входом enable для каждого фильтра. В свойствах блока указываем все нужные фильтры, а применением каждого рулим оперативно из FBD. Опять же уберет сущности с поляны.

Уложилось, уложилось. В приложенной выше программе это используется.

UPD.
Упс, только сейчас заметил, что файл не приложился к предыдущему сообщению, хотя в предварительном просмотре был.

Вложения

ee.psl (524.1 Кбайт, 13 просмотров)

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

Добавочка по глюкам. Закономерность проявления не уловил.

Конфигуратор архива периодически открывается пустой, хотя в проекте есть блоки работы с историческими данными.

Расчет занимаемого архивом места в конфигураторе. Странная логика расчета при выборе записи по триггеру.
Почему считается, что будет обязательно 25 сэмплов в секунду? При установленном по умолчанию тике в 100мс контроллер даже не успеет их сделать.

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

Окно свойств блока History периодически открывается пустым — как будто у блока не назначено ни одного входа, хотя входы назначены, на поляне у блока все отображается и он работает.

Добавлено через 5 минут

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

В общем случае в подавляющем большинстве программ используется заданный для проекта тик, а не меняется динамически. Можно хотя бы отталкиваться от него при расчете, а не от теоретически максимальной скорости сэмплирования.
Дело не в том, что не будет «жирнее», а в том, что нет возможности нормально задать период хранения архива.

Вот мне надо архив со сроком жизни в год. Считать сэмплы на год? Их может быть ни одного за день, а может быть десятки.

Поставить жирную флешку из расчёта максимальной скорости сэмплирования и ограничить время жизни данных годом. В скада-системах так и делают. Это гарантия 100% успеха.

Остальное — вероятностные процессы.

__________________
Добро всегда побеждает зло. Кто победил — тот и добрый.

Остальное — вероятностные процессы.

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

В тот же расчет при выборе триггера можно было добавить поле «Максимальная частота сэмплирования», значение которой будет задаваться пользователем, и считать те дни/года исходя из этого значения, а не теоретически возможного. Элементарнейшая же вещь, несколько строк кода, не требующая «глобальной переделки системного подхода в лоджике».
Вот скажите честно, Арсений — в вашей лично практике было много программ, которые что-то читали/записывали с частотой 25 раз в секунду, да хотя бы 10 раз/сек? Хоть 1% от общего числа наберется?

Ну вот, честно, порой трудно понять логику, по которой вы принимаете те или иные решения при реализации каких-то функций.

Исторический график смарта.

До фига непонятного сходу, а ссылка в справке «см. Руководство пользователя» — не работает.

В историческом графике в смарте нельзя вывести только значения заданного диапазона по времени, а не весь архив?

Едем дальше с косяками.

Еще один глюк с Esc в смарте.
Есть экран, на котором живет исторический график(не во весь экран) и рядом с ним другие элементы — кнопки, текст, вывод числа. Если в переходах таки назначим Esc для выхода из экрана, то нажатие на него приводит только пропаданию всего изображения на полсекунды и остаемся на этом же экране. Выйти можно только быстрым троекратным нажатием на Esc.

Косяк со слайдером задания диапазона.
1. Размер исторического графика не на весь экран.Сверху и снизу есть другие элементы.
2. Открываем панель управления, тыкаем в задание начала диапазона.
3. Приехали. Нижняя часть окна со слайдером не отображается. Закрыть мы его не можем — на Enter не реагирует, по Esс получаем выход из экрана.
4. Вылетев по Esc, возвращаемся на экран с графиком — а там так и висит этот слайдер, с которым мы ничего не можем сделать.
Логичной была бы, как минимум, отработка Enter и Esc для этого окна.Как максимум, либо масштабирование слайдера соответственно размеру графика, либо отрисовка его поверх всех элементов экрана с привязкой его координат к экрану, а не к координатам графика. Растянуть окно графика до низа экрана тоже не поможет — так как оно сдвинуто вниз от верха, слайдер тоже оказывается сдвинутым вниз. Соответственно, его кнопки «Отмена» и «Перейти» находятся за пределами экрана.

Расположение элементов по уровню нам не поможет разместить свои элементы поверх графика, так он всегда сверху.

Далее. Мелочь в общем-то, но осадочек остается.
Если у нас пустой архив — нет ни одной записи — нам все равно предлагается сохранить отчет. После нажатия на кнопу «Сохранить» никакого отчета не сохраняется.
Правильным было бы при нажатии на дискету в панели управления вместо окна «Создание отчета» сразу выдавать сообщение о пустом архиве. Ну или все же создавать отчет, пусть он и будет пустой. А еще можно сделать проверку на пустоту архива и делать дискетку неактивной, как это сделано с кнопкой для слайдера. (Что касается этих слайдеров вообще, мое сугубо субъективное мнение — дико неудобная штука . Пока введешь одно значение в попытках его поймать с этими инерционными прокрутками, с обычной клавы с цифирями уже бы штук 5 ввел, минимум.)

Лирическое отступление.
Блин, весь день в лоджике, из них от силы полтора часа потрачено на саму программу, а все остальное время на борьбу с косяками и непонятками с этими историческими делами.
Теперь вот придется менять структуру экранов в смарте и частично концепцию интерфейса в целом.
Эх. если б заказчику не приспичило с этими архивами, сидел бы себе без новых глюков и проблем на 3.28 и горя б не знал.

Источник