Вид для печати
Добрый день.
Стоит задача архивирования сигнала с пары аналоговых входов в файл Excel, чтоб получить точную картину сигнала. Знаю что можно архивировать данные из Trend в визуализации, но это слишком медленно. У меня сохранилось 4 показания в секунду. Хотелось бы архивировать значения с частотой опроса этих самых аналоговых входов программой.
Подскажите пожалуйста как проще всего решить эту задачу
opc сервер с функцией хранения
А есть еще какие то ENI, DDE. Для меня это все новые понятия. Как и OPC сервер. Они подойдут ли и не будут ли проще?
ну, если вдруг на форуме объявятся специалисты по ENI, DDE, предлагаю подождать, когда они ответят
ENI это совсем не то. Это технология "контроля версий", для упорядоченной разработки ПО. Хранит историю ваших сорцов, грубо говоря. Бесплатный ENI, идущий с кодесисом -- порнография, толку от него мало, но это так, в сторону.Цитата:
Сообщение от ymnuhj
DDE -- такая технология обмена данными в Виндоуз, довольно низкоуровневая. Напрямую писать вызовы DDE -- не барское дело, всё уже сто лет как написано. Всякое OPC живет поверх него, если дело присходит в винде.
Так что скорее всего - не проще.
Спасибо всем за ответы.
krollcbas. Данный условно бесплатный метод вероятно не подходит. Я почитал, там внизу страницы написано что данные обновляются "Шустро" (Не более 500 мс). Так вот для моей задачи это слишком медленно. У меня есть датчик работающий с частотой 400Гц, и мне бы в идеале хотелось увидеть все эти 400 показаний в секунду. Если это конечно возможно.
Немножко продвинулся. Работает OPC сервер собирающий показания с контроллера. Но данные он не архивирует. "Функции хранения" походу нету. Может есть какой нибудь сторонний OPC Client который мог бы архивировать данные?
Еще в похожей теме на форуме видел что нужен DCOM. Что это и как использовать? Не тоже ли это самое что OPC Client?
Что-то Вы темнитеhttp://www.owen.ru/forum/attachment....5&d=1425224217Цитата:
Сообщение от ymnuhj
400 показаний в секунду с аналогового входа ПЛК? Это время преобразования для аналогового входа должно быть 2,5 мс, у ОВЕНа нет таких ПЛК.
В лучшем случае ПЛК160 имеет время преобразования(обновления) аналогового сигнала 15мс http://www.owen.ru/catalog/programmi...lk160/17971350
Не буду скрывать контроллер не Owen, а Fastwel cpm713 с модулем AIM723. Мне нужно просто увидеть значения с одного - двух ModbusTCP/IP выходов. Можно даже не масштабировать. Так что программа простейшая. Думаю должна успевать выполняться за это минимальное цикла, которое 1 мс если я все правильно понял.
А вопрос я задал именно в этом форуме, потому что во первых контроллеры обоих этих фирм используют программную среду Codesys 2.3 а значит программируются они одинаково. А во вторых этот форум как мне показалось довольно удобный и оживленный.
Будет печально если OPC обновляет данные тормознуто. Разве он не может работать на одной частоте с контроллером? Какой тогда есть способ заархивировать максимальное число показаний в секунду?
При чем здесь простейшая у Вас программа или нет. Ограничение будет не во времени минимального цикла, пусть оно будет даже не 1мс, а 0,000....1мс. Ограничение у Вас на аппаратном уровне, т.е. "железо" не позволит получить 400 отсчетов за одну секунду.Цитата:
Сообщение от ymnuhj
Мало того, что Вы будете использовать вход не контроллера, а внешнего модуля, а это означает наличие ограничения по скорости передачи данных по внешней шине между ПЛК и модулем, так Вы еще и не ознакомились с характеристиками этого модуля.
Ваш AIM723 в лучшем случае имеет время преобразования по одному каналу -8,4 мс
Вложение 21509
А это означает только 120 измерений в секунду. Модуль четырех канальный, с большой долей вероятности получите только 120/4=30 измерений в секунду. И "по барабану", что датчик у Вас "работающий с частотой 400Гц".
Так, что Ваша затея сохранять 400 раз в секунду данные , которые обновляются 30 раз в секунду, не что иное как "monkey business"(мартышкин труд):rolleyes:.
ЗЫ. С реальной величиной ограничения по скорости связи между ПЛК и модулем разбираться не хочу, сами почитайте/посчитайте будет она влиять или нет http://www.cta.ru/cms/f/352126.pdf
ЗЫ. Для общего развития. Кроме трендов в визуализации можно использовать трассировку, можно будет писать данные вплоть до каждого цикла ПЛК.
Вложение 21510
Скрытый текст:
Трассировку можно сохранять в ПЛК.
Спасибо за конструктивную критику и подробные разъяснения.
Я просто совсем новичок в этой теме. Многое стало яснее. И английский подучил) С наступающим
Попробую поднять тему). Научился получать данные с ПР200 в Excel через DDE Lectus. Но нужна обработка привязанная к системной дате. Данные - часы наработки различных режимов, которых под 30 штук. Не знаю или всю логику делать в ПР200 у которой есть часы реального времени но боюсь не хватит ресурсов или как-то уже на верхнем уровне обработать. Нужно часы разложить по дням, ночам, месяцам, годам. Кто что делал подобное?
Переходите к секундам, в смысле, к UNIX TimeЦитата:
Сообщение от Вадим2881
http://www.owen.ru/forum/showthread....l=1#post219992
ЗЫ.
Не уверен, что Вам действительно нужна привязка к системной дате.
Нашел свой проект для панели - Расчет интервала между датами
Скрытый текст:
Если вместо 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
Спасибо за ответ!) Зря не описал задачу сразу. В общем нужно со станков снимать время работы в автомате и время простоя, причину которой выбирает оператор. Задача конечно не простая... Все временных причин под 30 штук. Причём данные должны копиться на 4-е операторские смены аз месяц год. Станков 20 штук. Предполагаю использовать ПР200 на каждом станке для определения режима работы и ввода причины простоя, а вот дальше верхний уровень не ясно как организовать. Хотелось бы ещё и на скаду заодно вывести состояние оборудования. Сейчас пробно сделал пр200 - Lectus - телемеханика лайт.