Вас понял, про Лебедева тут в авторитеты заносить не буду, не знаю вообще кто, и у кого больше ума сказать тоже не могу.
У своих спрошу удобно им иль нет смотреть на цифры.
Вид для печати
а сверните ка в другую плоскость, посмотрите на это со стороны сколько занимает символ шрифта и векторная графика сегментного знакоместа
в случае с андроидом, прога одна а экраны у устройств могут быть разные, выводить адекватный шрифт под свое разрешение позатратнее будет чем вектор увеличить
Цитата:
Это просто ваше имхо или есть источник?
Пространство вокруг символа играет слишком важную роль, чтобы отбрасывать его в излишки. Вариативность формы в общем случае заметнее вариативности комбинаций.Цитата:
посмотрите на это со стороны сколько занимает символ шрифта и векторная графика сегментного знакоместа
Вложение 23126
я не о пространстве, а больше об объемах ресурсов в самой проге. Обилие шрифтов говорит же само за себя что не всем нравиться какой то определенный, к тому же красиво вывести текст на слишком узком экране, заставит искать шрифт по предпочтительнее, а это значит подгружать некоторое количество дополнительно к дефолтным.
А объём ресурсов реально будет играть значение?
Вот если бы на рынке были десятки разных Android-HMI, то можно было бы и размер файла обсуждать.
Шрифты занимают копейки (~200КиБ), и тут не игры пишут, чтобы каждый байт экономить.
Если оно работает, и выглядит на отлично, то есть ли разница сколько занимает файл?
Взять ту же Каскаду. Ну, лежит в ней мегабайтный wav файл. И? Ужас-ужас? Может, этот файл там по делу лежит, специально для планшетов, которые mp3 не поддерживают.
Даже стоимость шрифта наверняка окажется ниже, чем стоимость разработчика, который будет программировать "знакоместо".
200кБ против двух?
выглядит на отлично при своем размере, а что бывает если начать растягивать/уменьшать, поворачивать экран ни чего не делая для textviev?
то что в устройстве лежит и то что в ОЗУ разные вещи
Реализация Пикового индикатора компонентами Динамический текст и макроса PIC на ПР200
<iframe width="640" height="360" src="https://www.youtube.com/embed/-54J_V1GSF8" frameborder="0" allowfullscreen></iframe>
макрос для ПР тут http://www.owen.ru/forum/showthread....l=1#post201278
Визуализация счетчика импульсов с использованием Макроса СИ100
<iframe width="640" height="360" src="https://www.youtube.com/embed/ljq0x_H6xxU" frameborder="0" allowfullscreen></iframe>
макрос для Пр тут http://www.owen.ru/forum/showthread....l=1#post201292
На Пр можно реализовать любой блок управления с визуализацией ,в рамках быстродействия его,оформив их в макросы .А так же скомбинировать несколько блоков ,помимо реализации основного алгоритма работы устройства .
Пример регулятора вентиляторов
В Каскаду добавлен новый компонент -ГРАФИК .С Авто масштабированием по всем координатам .Можно работать свайпами ,просматривая график ...
-задаётся периодичность опроса от 1 секунды до 60 минут
-задаётся лимит точек, отображаемых на графике, от 2 до 300
-задается цвет линии, цвет фона
<iframe width="640" height="360" src="https://www.youtube.com/embed/C6CjZsm2bNQ" frameborder="0" allowfullscreen></iframe>
скачивание https://cloud.mail.ru/public/BJuN/6pETvaAM8
Обновление Каскада выложены http://www.owen.ru/forum/showthread....l=1#post191806
на очереди АРХИВ .
Пока нет ,очередь не дошла :
Сейчас ищем возможность русификации веб страницы .Выпуск планируется в июне ..
так блютуз или Wifi в вашем модуле?
В апреле блютуз ,в мае езернет ,в июне вайфай ;) для Пр200
а в мае - июне блютуса уже не будет :)?
В этой теме обсуждаем только Каскаду ,а железо в ПР теме .
Начали реализацию компонента АРХИВ.Пока планируем следующее -
До 4каналов архивирования по событию в флоат формате на компонент.Сам архив в формате для эксель.Сохраняем значения и метки времени (дата,время) .Количество используемых компонентов Архив в проекте не ограничиваем ,то есть можно архивировать до4,8,12,16,20.....каналов .Но это уже на ответственности пользователя следить за обьемом архива ,что бы памяти хватило .На канал думаем выделить до 10мб.
Может будут еще какие пожелания ...
Добрый день.
Мы разрабатываем архиватор, компонент, который будет писать данные в файл по внешнему событию (биту).
Архиватор будет читать FLOAT значения, ему нужно указать с какого регистра читать и сколько FLOAT значений (до 4), это и есть каналы, добавление времени автоматически при записи в файл.
Выглядеть в результате будет как csv файл, который можно посмотреть с помощью excel'я на ПК.
Нужно разделить задачи, архиватор это одно, график - другое.
График - представление данных, не более.
Архиватор - немного аналогичен archive в codesys.
Пока речь об архиваторе, ему нужно событие, по которому он будет делать запрос на slave и записывать полученные данные в энергонезависимую память устройства + дата\время.
Событие мы хотим привязать с сетевой переменной, это даст гибкость системе.
Что потом делать с этим архивом это другой вопрос, возможно он будет отображаться в каскаде в отдельном графике подгружаясь по нажатии кнопки, но есть еще много нюансов, опять же, shift mode тут будет мешать.
а зачем делать дублирующие запросы,почему не взять с того же места откуда берет визуализация
Над пользователями довлеет опыт прошлых лет ,они привыкли к тому как это было сделано где то ранее ,причем без учета первого опыта (забыли как мучились ранее) .Например если часто использую СИ8 ,то не заглядываю в инструкцию ,а если год прошел ,то не помнишь ,потому как меню сложное и параметров много ,но не чего ,многие привыкли .Нам проще ,мы делаем с нуля .Мы исходим из того ,что компонент график это независимый и достаточный элемент визуализации .АРХИВ это другой компонент ,который решает другие задачи .Если графиков на одном экране бывает достаточно одного для оперативного управления .То Архив имеет смысл иметь как минимум 4 канала ,что бы спустя время видеть и анализировать не только последствия ,но и причины приведшие к не желаемому результату .Ну упало температура ниже критической ,запомнили ее и время ,но нужно еще несколько переменных писать ,влияющих на температуру ,что бы найти причину ....Одним нужен только график,другим только архив ,третьим все подавай .Нами выбрана концепция ,что все относительно сложные моменты реализуются не средствами Каскады ,иначе нас потянет на классическую скаду .Например -мнемосхемы рисуются не средствами каскады ,а внешними ,штатными редакторами .Аналогично и с данными Архива .Наша задача создать файл ,а визуализация его в виде графиков ,того или иного вида или таблиц это задача внешней программы(кому что нравится) .Причем ексель есть и на андроде и на винде .Запускайте приложение и делайте что хотите с данными ,для того мы и взяли специально флоат для архива ,что бы без масштабирования отображать реальные графики (таблицы) в штатных программах ...
Ни кто не запрещает использовать одни и те же переменные и для Графика и для Архива ,но только для Графика нужны целочисленные значения и масштабирование (запятую) делает разработчик проекта на ПР,а в Архиве все на автомате.Со временем может сделаем и тип данных для Графика по выбору ,а пока так .Нужно дать пользователю хотя бы минимум средств для работы ,но быстро ,чем они будут ждать разработки и отладки финальной версии годами,имхо.
ну можно начать с того а какой смысл архивировать какие то данные если в реале они ни кому не нужны, а можно и начать с того что что в ПР ограничена(или известна) карта регистров, копировать её на внешнее устройство одним групповым запросом, а в редакторе привязок указывая адрес в пр подразумеваем, что на самом деле привязываемся к зеркалу регистров в памяти устройства, архивирование становиться без проблем, отображение без видимых тормозов
Ну во первых групповое чтение не так уж и велико (12 что ли регистров) .Во вторых хранить зеркало в памяти смартфона накладно и избыточно ,а внешнего носителя нет .сотню переменных да еще раз в секунду ,ого го...если месяц писать ...
Я больше склоняюсь ,что для ПР Архивирование это способ выявления отклонений с целью анализа причин приведших к этому ,на протяжении достаточно большого времени (для лучшей статистики) ,а не подсчет мух пролетевших мимо оператора и севших на оборудования с целью осрамить его :D
.Если в меню,например задано 4 канала (4х4байта=8регистров по 16бит) то их чтение будет групповым ,это естественно .1секх16х3600х24х30=41472000байт ,если писать раз в минуту то 691200байт в месяц для 4 каналов ,вроде не много...А если всю область переменных писать ,то явно будет перебор ...
Совсем забыл ,это только на сами данные + еще нужны байты на запоминание даты времени ...это еще где то 6 байт на отсчет .
Вы не понимаете сути, в телефоне крутится зеркало сетевых переменных, один запрос к ПР обновляет их с заданной частотой. Пользователь выбрал несколько переменных для архивирования и Ваш разработчик предлагает, делать отдельно запросы к ПР для составления архива, я же предлагаю брать из этого зеркального образа, чтоб не делать лишних запросов. Я не предлагаю писать в архив все сетевые переменные
да в чем засор то, если с этого зеркала будут пользоваться все локальные потребители, визуализация мнемосхемы, архив, тренды и др. больше не обращаясь с запросами к самой ПР. будет крутиться отдельная задача в функции которой будет только считывать все сетевые переменные и записывать по событию, другим уже не потребуется вставать в очередь чтоб сделать свой запрос. Если возникают проблемы со связью, можно за раз изменить все данные на дефолтные, а не так что по мере поступления запросов элементы схемы будут отваливаться по таймауту, каждый в свое время
В этом что есть ,если говорить не об одном Архиве ,а о всех компонентах. Но тогда нужно считывать зеркало с максимальной скоростью ,потому как разные компоненты по назначению есть .цифровому индикатору нужно 1 раз в секунду обновляться ,а архиву или графику 1час подавай .значит нужно еще таймеры городить в Каскаде .А как у нас ,если приходит управляющий бит раз в час ,то раз в час и опращиваем для архива,графика.Причем Архиву все равно ,когда его ПР оживит для считывания .Это имело бы смысл и хороший результат если бы была возможность считывать сотню байт за раз ,а так ....не получим ожидаемого эффекта при 12 регистров .
Кроме того зеркало оно же и для записи ,а тут промедления чреваты (останов ,например).
Сама идея красивая !
зачем записывать в зеркало, по событию пишите сразу в ПР. Не знаю про какие Вы таймеры завели речь, если Вы обращаетесь с каким то периодом в ПР для получения инфы, точно так же будете обращаться только к локальной памяти. А заполняться локальная память будет по 12 регистров, если в ПР их больше то следующая партия еще 12, следующим запросом, тут главное как в сексе - регулярность
Только у одного регулярность раз в месяц ,а другого раз в день ;). Только с компонентом График период задает Каскада ,все остальные опросы в цикле ,на максимальной скорости .
как будто в моем случае это не так, я прям заставляю опрашивать медленнее. Приведу другой аргумент,например достался проект другому пользователю,а у него другое представление об адресации устройств и он вынужден менять у каждого элемента адрес слейва ну или что там привязывается, в моем случае произвели изменения в диспетчере,который работает независимо от остальных и в задачу которого входит только обмен с данными,другой диспетчер отвечающий за визуализацию как брал данные из локальной памяти,так и продолжит брать из тех же мест
Все же с внутренними делами постараемся сами разобраться .Вопрос был о внешних свойствах компонента Архив .Спасибо.
Для любителей визуализации и Каскады выкладываю компоненты (картинки красивые),которые пригодятся для создания проектов на планшете и не только:cool: ...