КаСкада для Андроид устройств

[rovki]

а в мае - июне блютуса уже не будет ?

Не понял ,я говорю о начале продаж ...,а конца не будет

[rovki]

В этой теме обсуждаем только Каскаду ,а железо в ПР теме .

[rovki]

Начали реализацию компонента АРХИВ.Пока планируем следующее -
До 4каналов архивирования по событию в флоат формате на компонент.Сам архив в формате для эксель.Сохраняем значения и метки времени (дата,время) .Количество используемых компонентов Архив в проекте не ограничиваем ,то есть можно архивировать до4,8,12,16,20.....каналов .Но это уже на ответственности пользователя следить за обьемом архива ,что бы памяти хватило .На канал думаем выделить до 10мб.
Может будут еще какие пожелания ...

[rovki]

Графики очень важная и неотъемлемая часть скады и подход к выбору нужно производить очень щепетильно. 4 канала на экран это приемлемо но не абсолютно посмотрите в сторону Интеграф по оформлению а по содержанию СИМП ЛАЙТ.

В данном случае речь не о графике как таковом ,они воспроизводятся на ПК штатными средствами(таблица эксель) ,а о Архиваторе .
4 канала это в одном компоненте ,а компонентов(не графиков) может быть множество на экранах Каскады .

[KaScada]

Графики очень важная и неотъемлемая часть скады и подход к выбору нужно производить очень щепетильно. 4 канала на экран это приемлемо но не абсолютно посмотрите в сторону Интеграф по оформлению а по содержанию СИМП ЛАЙТ.

Добрый день.
Мы разрабатываем архиватор, компонент, который будет писать данные в файл по внешнему событию (биту).
Архиватор будет читать FLOAT значения, ему нужно указать с какого регистра читать и сколько FLOAT значений (до 4), это и есть каналы, добавление времени автоматически при записи в файл.
Выглядеть в результате будет как csv файл, который можно посмотреть с помощью excel'я на ПК.

[KaScada]

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

Нужно разделить задачи, архиватор это одно, график - другое.
График - представление данных, не более.
Архиватор - немного аналогичен archive в codesys.
Пока речь об архиваторе, ему нужно событие, по которому он будет делать запрос на slave и записывать полученные данные в энергонезависимую память устройства + дата\время.
Событие мы хотим привязать с сетевой переменной, это даст гибкость системе.
Что потом делать с этим архивом это другой вопрос, возможно он будет отображаться в каскаде в отдельном графике подгружаясь по нажатии кнопки, но есть еще много нюансов, опять же, shift mode тут будет мешать.

[capzap]

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

[KaScada]

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

Мы давно думали об этом, но это подразумевает карту тегов (список). Ведь нужного для архиватора регистра может не быть в визуализации.

[capzap]

Мы давно думали об этом, но это подразумевает карту тегов (список). Ведь нужного для архиватора регистра может не быть в визуализации.

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

[rovki]

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

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