|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Господа! Программисты и еже с ними! Есть кто занимается с производственным оборудованием (допустим KRONES, KHS) на линиях (а их несколько) по розливу пива . Есть задача по сбору данных с датчиков этого оборудования и формирования из этих данных БД для последующей обработки в отчеты и графики. Что можете сказать по такой теме? С. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.10.2003, 10:03 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Тык :) мы собираем данные и сразу их заливаем в бутылки с последующим употребелнием по назначению :) вопрос какой интересует то ? сбор данных с датчиков? или работа с данными, которые уже собраны? если первый - то в форуме по Проектированию БД ни к чему на него вопрос искать. а если второй - то подробнее опишите вопрос ... |
|||
:
Нравится:
Не нравится:
|
|||
14.10.2003, 12:58 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
По-моему, сначала надо выяснить, какие данные могут выдавать датчики. Потом спроектировать БД, куда эти данные будут попадать. Затем подумать о способе, посредством которого данные датчиков попадут в БД. (Кстати, неясно, в каком виде выдают данные датчики) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.10.2003, 13:31 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Если система уже неплохо заточена для работы с PC, есть все драйвера и ПО для мониторинга, рекомендации и типовые примеры систем, то может вообще там делать нефиг? Если ничего этого нет, читаем дальше: 1. собери информацию/спецификацию/описание - что, чего и в каком виде эти датчики меряют/выдают. 2. определись, что из этого нужно/не нужно/пишем/не пишем/анализируем/игнорируем, что на выходе, чего вообще хотим - это спросить у заказчика системы, но возможности датчиков опишешь им ты, т.к. будешь уже подготовлен к разговору. 3. структура системы в целом, подбиваем, что у нас есть, чего нет. (Возможно надо будет заказать дяде Васе пару преобразователей? - как это все в PC-то попадает?) 4. в общей структуре системы рекомендую выделить отдельную машину, в которую будут поступать данные и подвергаться первичной обработке (старая коробка p-133..333), ну а затем, кусками сбрасываться в какую-нить DB. Возможно в существующую, в которую вставить дополнительный модуль (1С?). 5. согласно п.2. делаешь формы отчеты и т.д., гоняешь тестируешь. :) Успехов. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.10.2003, 18:26 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Спасибо за ответы (даже почти без ёрниченья, как ни странно) На самом то деле нам нужна работа в первую очередь по сбору данных с датчиков на оборудовании (сигналы разные - как дискретные так и обработанные, уже с контроллера например) конечно уже определено и оборудование и какой сигнал нужен, и куда примерно "он" должен попадать (теоретически) Я думал вдруг объявятся именно специалисты в области промышленной автоматики и тогда с ними можно было бы обсудить задачу на предмет сотрудничества (правда при условии, что я сам не спец. в ИТ технологиях и автоматике тоже, я просто пытаюсь найти способы реализации данной идеи... С уважением ... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2003, 12:01 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Skladowoy, \r Можешь еще сюда заглянуть, тут тов. sti тоже с какого-то оборудования данные собирал... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2003, 11:31 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Вот как заведено делать на производстве: Из контроллера или распределенных блоков сбора данных значения сливаются в исторические архивы: метка времени, название сигнала (тег), значение. Skladovoy! Для вас отдельное письмо! Смотрите почту. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2003, 15:56 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Указанная задача является типовой задачей для автоматизированных систем управления технологическими процессами (сокращённо АСУТП) и в абсолютном большинстве своём имеет следующую схему построения: 1. Уровень технологических объектов (непосредственно объекты, подлежащие контролю и/или управлению - например линия по розливу) 2. Уровень аппаратных средств контроля и управления технологическими объектами и процессами (здесь как правило используются так называемые контроллеры) 3. Уровень программного обеспечение (компьютерная техника) В свою очередь, уровень 3 разбивается на следующие подуровни: 3.1. ПО обмена с аппаратным обеспечением (уровень 2). В этой роли обычно выступают OPC-сервера или любое другое подобное ПО. 3.2. Средство хранения информации, поступившей от технологических объектов. В этом качестве обычно используются СУБД (Oracle, Microsoft SQL Server и т.д.) 3.3. ПО отображения информации в соответствии с потребностями пользователей (SCADA-системы, системы построения отчётов, WEB-доступ и т.д.) В зависимости от конкретной задачи число уровней схемы и их состав может меняться, но подобная схема применяется в том числе и для опасных производств (например - добыча, подготовка и транспортировка газа). В качестве примера построения системы для указанной задачи (см. выше) могу предложить следующее решение. 1. Определяем способ подключения технологических объектов к серверу сбора информации (напрямую или через контроллер). 2. Ищем OPC-сервер, который позволяет серверу сбора считывать информацию с объектов. Если такого нет, то поручаем разработчикам (своим или сторонним) его разработать. Для справки: стандарт OPC разработан специально для систем АСУТП и определяет единый интерфейс обмена информацией для подобных систем. Это нечто подобное спецификациям протоколов FTP, POP3 и т.д. и т.п. 3. OPC-сервер получает информацию об изменении состояний технологических объектов в виде: - значение - дата/время возникновения значения (временная метка) - качество значения - при необходимости представляются дополнительные атрибуты значения (если OPC-сервер их поддерживает). 4. Сохраняем информацию в базу данных. Это может делать либо сам OPC-сервер, либо какой-нибудь другой софт. Структуру хранения информации мы определяем сами - как будет наиболее удобно. 5. Задачу отображения информации из базы данных конечным пользователям - решаем с помощью любых программных средств (начиная от Visual Basic, Delphi, ASP и т.д. и т.п.). Системы автоматизации - штука как очень интересная, так и очень емкая... Если кто заинтересуется, особенно в плане реализации реальных проектов, всегда готов к сотрудничеству... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2003, 07:29 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
сразу вопрос: При разработке использую ОРС сервер, но в VB не очень то и описанны все методы и события этого объекта. Не подскажете где нарыть доку? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2004, 12:42 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
elephant_work - везде твои вопросы на мои ответы :-) вроде где-то я уже написал про сайт http://www.opcfoundation.org там вся возможная дока (на английском), в том числе и для VB ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2004, 11:18 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Простите, конечно, если вдруг нельзя поднимать старые темы, но и подобные темы плодить не хочется! Тоже пытаюсь найти решение по оптимальной выдаче через интернет от сетевого СУБД некоего объема данных (к примеру не более сотни строк в каждой метка времени, наименование датчика и поле с текущей цифровой величиной). Другими словами нужно организовать раздачу данных клиентам с одного сервера АСУТП на котором работает и копит данные этот СУБД. Я в этом не понимаю одного - клиентам нужно постоянно в режиме опроса (через интернет с периодом желательно 1 раз в сек) гонять запросы и получать ту самую сотню строк? т.е. клиенты должны подключаться к СУБД и в режиме непрерывного опроса получать данные? Хочу отметить, что данные могу и не обновляться например в течение минуты и можно ли запрограммировать СУБД так, чтобы он самостоятельно уведомлял что такие-то данные обновлены и соответственно их можно получать по сети. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 08:06 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Curr93Я в этом не понимаю одного - клиентам нужно постоянно в режиме опроса (через интернет с периодом желательно 1 раз в сек) гонять запросы и получать ту самую сотню строк? т.е. клиенты должны подключаться к СУБД и в режиме непрерывного опроса получать данные? Нет, так делают только чайники. Думай о своей задаче как о сетевой игре. Датчики меняют игровой мир, клиенты на это смотрят. СУБД тут вообще сбоку припёка и непосредственно в процессе участвовать не должна. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 14:02 |
|
Сбор данных с произв оборудования
|
|||
---|---|---|---|
#18+
Curr93 Я в этом не понимаю одного - клиентам нужно постоянно в режиме опроса (через интернет с периодом желательно 1 раз в сек) гонять запросы и получать ту самую сотню строк? Никто, кроме вас, не знает. Выше уже предложили подход как к сетевой игре. Я же считаю, что данные датчиков обязательно нужно хранить всегда (хотя бы год) для дальнейшей аналитики. Например, можно сделать прогноз по выходу оборудования из строя, чтобы более гибко и своевременно оное обслуживать/заменять. Но делать это не через классическую СУБД, а через брокер сообщений, а для хранения использовать что-то типа кликхауса. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2021, 20:40 |
|
|
start [/forum/topic.php?fid=32&msg=32292622&tid=1539817]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
5ms |
track hit: |
40ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 234ms |
total: | 387ms |
0 / 0 |