Comments 14
абсолютно.... SNmp must have на таких вещах..
И вообще хотелось бы чуть больше понимать процесс... Я так понимаю вы проволоку делаете?
Перегруз преобразователя от чего случился ? Ведь оборудование было изначально настроено на рутинные операции...
Просто имеющийся софт для сбора данных не предусматривал работу по SNMP, зато как получать данные по UDP мы уже знали и давно использовали.
У нас агрегат непрерывного горячего цинкования полосы, на выходе оцинкованный рулон металла, но это не имеет значения, потому что компрессор не завязан на него. Компрессор просто качает в магистраль. После техобслуживания, перегрузы прекратились, и если я правильно понял помогла просто продувка самого ЧП. Но это не точно, техобслуживанием занимался представитель компании производителя компрессорной установки.
Интересно а что за контроллеры используют компрессоры с вебинтерфейсом.
Мама, хочу Факторио
У нас есть Факторио дома
Факторио дома:
По русски это называется бомж автоматизация: упало давление воздуха, заблокировались пневматические тормоза, но ошибки вылезли не по давлению воздуха, а по технической части... С умных компрессоров не читаются ошибки в ПЛК и не выводятся предупреждения на SCADA - это чтобы увеличить время простоя за счёт увеличения продолжительности диагностики неисправности! Параметры работы линии пишутся по WEB интерфейсу бог знает куда, чтобы осложнить наблюдения за состоянием оборудования обслуживающему персоналу.
Автоматизация, безжалостная и беспощадная!
Я не согласен. Во-первых, компрессоры качают в общую магистраль, без привязки к конкретной линии и ПЛК, к тому же технолог должен следить за линией, а не за работой компрессоров. Ситуация нестандартная и при таком раскладе не требует особо быстрого реагирования, собственно потому и 3 компрессора, потому что один из них всегда в резерве. Во-вторых, изначально не было вообще ничего, и добавив таким божеметодом хоть что-то, считаю что все же удалось облегчить работу обслуживающему персоналу, то бишь и мне самому. Предположим, подойдет энергетик ко мне и скажет что один компрессор стал хуже качать, я хотя бы смогу по истории посмотреть сколько он качал неделю назад, а сколько стал сейчас, выросли ли токи нагрузки, ну или еще что-нибудь.
Но вообще согласен, что остановка компрессора должна хоть как-то оповещать операторов, потому как об этом узнали постфактум, что конечно же усложнило поиск неисправности. Но опять же, в проекте не было заложено такого, потому имеем что имеем
Ну во первых контроль давления воздуха должен быть на линии.
Ситуация нестандартная, и не требует быстрого реагирования... Ну штошь: предприятие встало из за просадки давления в воздушной сети из-за отказа компрессора, но ситуация не срочная - можем постоять пару деньков...
Предположим подойдёт ко мне энергетик... Простите, а вы в каком отделе работаете что энергетик может к вам так запросто завалиться со своими проблемами?
Ну и контроль за работой должен быть непрерывным, хотя в свете того что отказ воздушной магистрали для вашего предприятия не форс мажор...
как-то решение все-таки отдает избыточность.Наверняка и о первый и у последнего можно было собирать данные по Modbus и OPC на CAS сервер или сразу на станцию с возможностью формирования и хранения архивов (у всех скад уже имеется подобный функционал,Даже если просто отдельно панель Wientek- она эту задачу из коробки потянет, только карту памяти вставить)
Как мы получали данные от компрессоров