Просмотр полной версии : архивирование данных с контроллера в Excel
Добрый день.
Стоит задача архивирования сигнала с пары аналоговых входов в файл Excel, чтоб получить точную картину сигнала. Знаю что можно архивировать данные из Trend в визуализации, но это слишком медленно. У меня сохранилось 4 показания в секунду. Хотелось бы архивировать значения с частотой опроса этих самых аналоговых входов программой.
Подскажите пожалуйста как проще всего решить эту задачу
opc сервер с функцией хранения
А есть еще какие то ENI, DDE. Для меня это все новые понятия. Как и OPC сервер. Они подойдут ли и не будут ли проще?
ну, если вдруг на форуме объявятся специалисты по ENI, DDE, предлагаю подождать, когда они ответят
А есть еще какие то ENI, DDE. Для меня это все новые понятия. Как и OPC сервер. Они подойдут ли и не будут ли проще?
ENI это совсем не то. Это технология "контроля версий", для упорядоченной разработки ПО. Хранит историю ваших сорцов, грубо говоря. Бесплатный ENI, идущий с кодесисом -- порнография, толку от него мало, но это так, в сторону.
DDE -- такая технология обмена данными в Виндоуз, довольно низкоуровневая. Напрямую писать вызовы DDE -- не барское дело, всё уже сто лет как написано. Всякое OPC живет поверх него, если дело присходит в винде.
Так что скорее всего - не проще.
Спасибо всем за ответы.
krollcbas. Данный условно бесплатный метод вероятно не подходит. Я почитал, там внизу страницы написано что данные обновляются "Шустро" (Не более 500 мс). Так вот для моей задачи это слишком медленно. У меня есть датчик работающий с частотой 400Гц, и мне бы в идеале хотелось увидеть все эти 400 показаний в секунду. Если это конечно возможно.
Немножко продвинулся. Работает OPC сервер собирающий показания с контроллера. Но данные он не архивирует. "Функции хранения" походу нету. Может есть какой нибудь сторонний OPC Client который мог бы архивировать данные?
Еще в похожей теме на форуме видел что нужен DCOM. Что это и как использовать? Не тоже ли это самое что OPC Client?
Спасибо всем за ответы.
krollcbas. Данный условно бесплатный метод вероятно не подходит. Я почитал, там внизу страницы написано что данные обновляются "Шустро" (Не более 500 мс). Так вот для моей задачи это слишком медленно. У меня есть датчик работающий с частотой 400Гц, и мне бы в идеале хотелось увидеть все эти 400 показаний в секунду. Если это конечно возможно.
Немножко продвинулся. Работает OPC сервер собирающий показания с контроллера. Но данные он не архивирует. "Функции хранения" походу нету. Может есть какой нибудь сторонний OPC Client который мог бы архивировать данные?
Еще в похожей теме на форуме видел что нужен DCOM. Что это и как использовать? Не тоже ли это самое что OPC Client?
Что-то Вы темнитеhttp://www.owen.ru/forum/attachment.php?attachmentid=16915&d=1425224217
400 показаний в секунду с аналогового входа ПЛК? Это время преобразования для аналогового входа должно быть 2,5 мс, у ОВЕНа нет таких ПЛК.
В лучшем случае ПЛК160 имеет время преобразования(обновления) аналогового сигнала 15мс http://www.owen.ru/catalog/programmiruemij_logicheskij_kontroller_oven_plk160/17971350
Не буду скрывать контроллер не Owen, а Fastwel cpm713 с модулем AIM723. Мне нужно просто увидеть значения с одного - двух ModbusTCP/IP выходов. Можно даже не масштабировать. Так что программа простейшая. Думаю должна успевать выполняться за это минимальное цикла, которое 1 мс если я все правильно понял.
А вопрос я задал именно в этом форуме, потому что во первых контроллеры обоих этих фирм используют программную среду Codesys 2.3 а значит программируются они одинаково. А во вторых этот форум как мне показалось довольно удобный и оживленный.
Будет печально если OPC обновляет данные тормознуто. Разве он не может работать на одной частоте с контроллером? Какой тогда есть способ заархивировать максимальное число показаний в секунду?
Не буду скрывать контроллер не Owen, а Fastwel cpm713 с модулем AIM723. Мне нужно просто увидеть значения с одного - двух ModbusTCP/IP выходов. Можно даже не масштабировать. Так что программа простейшая. Думаю должна успевать выполняться за это минимальное цикла, которое 1 мс если я все правильно понял.
А вопрос я задал именно в этом форуме, потому что во первых контроллеры обоих этих фирм используют программную среду Codesys 2.3 а значит программируются они одинаково. А во вторых этот форум как мне показалось довольно удобный и оживленный.
Будет печально если OPC обновляет данные тормознуто. Разве он не может работать на одной частоте с контроллером? Какой тогда есть способ заархивировать максимальное число показаний в секунду?
При чем здесь простейшая у Вас программа или нет. Ограничение будет не во времени минимального цикла, пусть оно будет даже не 1мс, а 0,000....1мс. Ограничение у Вас на аппаратном уровне, т.е. "железо" не позволит получить 400 отсчетов за одну секунду.
Мало того, что Вы будете использовать вход не контроллера, а внешнего модуля, а это означает наличие ограничения по скорости передачи данных по внешней шине между ПЛК и модулем, так Вы еще и не ознакомились с характеристиками этого модуля.
Ваш AIM723 в лучшем случае имеет время преобразования по одному каналу -8,4 мс
21509
А это означает только 120 измерений в секунду. Модуль четырех канальный, с большой долей вероятности получите только 120/4=30 измерений в секунду. И "по барабану", что датчик у Вас "работающий с частотой 400Гц".
Так, что Ваша затея сохранять 400 раз в секунду данные , которые обновляются 30 раз в секунду, не что иное как "monkey business"(мартышкин труд):rolleyes:.
ЗЫ. С реальной величиной ограничения по скорости связи между ПЛК и модулем разбираться не хочу, сами почитайте/посчитайте будет она влиять или нет http://www.cta.ru/cms/f/352126.pdf
ЗЫ. Для общего развития. Кроме трендов в визуализации можно использовать трассировку, можно будет писать данные вплоть до каждого цикла ПЛК.
21510
http://www.owen.ru/forum/attachment.php?attachmentid=15291&d=1416369657
Трассировку можно сохранять в ПЛК.
Спасибо за конструктивную критику и подробные разъяснения.
Я просто совсем новичок в этой теме. Многое стало яснее. И английский подучил) С наступающим
Вадим2881
29.11.2017, 19:51
Попробую поднять тему). Научился получать данные с ПР200 в Excel через DDE Lectus. Но нужна обработка привязанная к системной дате. Данные - часы наработки различных режимов, которых под 30 штук. Не знаю или всю логику делать в ПР200 у которой есть часы реального времени но боюсь не хватит ресурсов или как-то уже на верхнем уровне обработать. Нужно часы разложить по дням, ночам, месяцам, годам. Кто что делал подобное?
Попробую поднять тему). Научился получать данные с ПР200 в Excel через DDE Lectus. Но нужна обработка привязанная к системной дате. Данные - часы наработки различных режимов, которых под 30 штук. Не знаю или всю логику делать в ПР200 у которой есть часы реального времени но боюсь не хватит ресурсов или как-то уже на верхнем уровне обработать. Нужно часы разложить по дням, ночам, месяцам, годам. Кто что делал подобное?
Переходите к секундам, в смысле, к UNIX Time
http://www.owen.ru/forum/showthread.php?t=25068&p=219992&viewfull=1#post219992
ЗЫ.
Не уверен, что Вам действительно нужна привязка к системной дате.
Нашел свой проект для панели - Расчет интервала между датами
http://www.owen.ru/forum/attachment.php?attachmentid=33910&d=1509300091
Если вместо delta сразу взять время наработки в секундах, то получите требуемое разложение
Время наработки в виде Лет-Месяцев-Дней Часов:Минут:Секунд
years = delta / 31556926 ;
months = (delta % 31556926) / 2629743;
days = (delta % 2629743) / 86400;
hours = (delta % 86400) / 3600;
minutes = (delta % 3600) / 60;
seconds = delta % 60;
Дни, часы, минуты и секунды - точные значения
А вот месяцы и годы -приблизительные, т.к. число дней в месяцах и годах есть величина переменная и для расчетов используются
Среднее количество дней в году - 365.24
Среднее количество дней в месяце - 30.44
Вадим2881
02.12.2017, 11:54
Спасибо за ответ!) Зря не описал задачу сразу. В общем нужно со станков снимать время работы в автомате и время простоя, причину которой выбирает оператор. Задача конечно не простая... Все временных причин под 30 штук. Причём данные должны копиться на 4-е операторские смены аз месяц год. Станков 20 штук. Предполагаю использовать ПР200 на каждом станке для определения режима работы и ввода причины простоя, а вот дальше верхний уровень не ясно как организовать. Хотелось бы ещё и на скаду заодно вывести состояние оборудования. Сейчас пробно сделал пр200 - Lectus - телемеханика лайт.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot