Мы иногда используем вторую концепцию у нас на заводе, на доменной печи. "Умные" разработчики ничего не знали о Producer/Consumer и ВСЕ делают через MSG. Хотя в некоторых случаях это удобнее. Поясню. Насколько я знаю нельзя сделать тэг Produced в online редактировании. А иногда ОЧЕНЬ нужно быстро изменить программу и для этого нужно пересылать данные из контроллера в контроллер. Поскольку это доменная печь, то останов производства хотя бы на 10 минут влечет за собой очень нехорошие последствия. Поэтому используем MSG. Хотя правильнее и красивее было бы использовать Producer/Consumer
Мы иногда используем вторую концепцию у нас на заводе, на доменной печи. "Умные" разработчики ничего не знали о Producer/Consumer и ВСЕ делают через MSG. Хотя в некоторых случаях это удобнее. Поясню. Насколько я знаю нельзя сделать тэг Produced в online редактировании. А иногда ОЧЕНЬ нужно быстро изменить программу и для этого нужно пересылать данные из контроллера в контроллер. Поскольку это доменная печь, то останов производства хотя бы на 10 минут влечет за собой очень нехорошие последствия. Поэтому используем MSG. Хотя правильнее и красивее было бы использовать Producer/Consumer
Абсолютно с Вами согласен - эта концепция более гибкая.
А Вы используете MSG вручную или у Вас есть "культурная обвязка" с интерфейсом на верхнем уровне по типу Проскона?
Не могу согласиться с тем, что MSG удобнее. Не могли бы Вы привести пару аргументов в пользу этой концепции?
Мне кажется, что просто использовать у себя consumer-тэги, вообще ничего не кодируя, - это гораздо проще и удобнее, чем писать дополнительный код для получения информации в тэги, которые, к тому же, должны быть созданы у себя на борту.
Цитата:
"культурная обвязка" с интерфейсом на верхнем уровне
Что именно Вы имеете в виду?
Вы видели оболочку программирования RSLogix? Куда уж, по-моему, "культурнее"
Позвольте полюбопытствовать, зачем нужна какая-то дополнительная оболочка? для какой цели?
+1
Скажем так. Как выход из ситуации (быстрый выход) и очень даже безболезненный - можно и нужно использовать MSG. Но при разработке проекта НОВОГО необходимо использовать producer/consumer тэги. Это мое личное ИМХО. Лично мне намного проще просто указать с каким тэгом работать чем создавать в контроллере дополнительный тэг, указывать что он записывается (или читается) из какого то другого контроллера, прописывать пути коммуникационные и т.п.
oldDad писал(а):
Вы видели оболочку программирования RSLogix? Куда уж, по-моему, "культурнее"
И снова +1
Настройка MSG сводится к минимуму. И понятна буквально через пару минут как столкнулся с данной командой. Немножко конечно приходится подумать насчет как прописать путь - но это тоже "победимо"
Не могу согласиться с тем, что MSG удобнее. Не могли бы Вы привести пару аргументов в пользу этой концепции?
Мне кажется, что просто использовать у себя consumer-тэги, вообще ничего не кодируя, - это гораздо проще и удобнее, чем писать дополнительный код для получения информации в тэги, которые, к тому же, должны быть созданы у себя на борту.
Цитата:
"культурная обвязка" с интерфейсом на верхнем уровне
Что именно Вы имеете в виду?
Вы видели оболочку программирования RSLogix? Куда уж, по-моему, "культурнее"
Позвольте полюбопытствовать, зачем нужна какая-то дополнительная оболочка? для какой цели?
Вы можете запостить тут несколько интересных скринов из RSLogix?
Не могу согласиться с тем, что MSG удобнее. Не могли бы Вы привести пару аргументов в пользу этой концепции?
Вы так и не ответили ни на один из моих вопросов
Цитата:
Вы можете запостить тут несколько интересных скринов из RSLogix?
Я не знаю, какие скрины для Вас могут оказаться интересными, покажу несколько каких-нибудь из Google:
Цитата:
И ещё, в Ваших ПЛК можно кодить на С?
Да, для любителей писания на С или BASIC есть специальные модули.
Вообще, такое "свободное" писание не поощряется в силу нескольких причин:
1) Мало ли кто что напишет. Может получиться непредсказуемая функциональность, а этого может зависеть жизнь и здоровье людей.
2) Если писатель уволится, сопровождать систему может оказаться некому.
3) В мультизадачной операционной среде реального времени такое писание довольно специфично. Кроме того, это обычно просто дорого, сложно и неэффективно. Смысл как раз в том, чтобы любой инженер, не владеющий программированием, мог быстро создавать работающие системы и их просто и эффективно эксплуатировать.
4) Честно говоря, не представляю, что и зачем в контроллерах писать на С, если есть Ladder, FBD, SFC, Structured Text. Cистема команд содержит всё, что только может понадобиться, включая самонастраивающийся PID, а если кому-то нужно всё-таки какое-нибудь извращение, то в RSLogix есть возможность создавать свои собственные команды.
Что вообще (и зачем) писать в контроллерах на С? Ну, могу представить себе какой-нибудь очень специфический протокол обмена данными. Но у нас есть модули для практически всех протоколов.
Эти стандартные языки и появились как раз именно потому, что мировое automation community захотело уйти от вышеперечисленных усложняющих жизнь субъективных вещей и упростить себе жизнь.
Цитата:
Вы хоть раз видели интерфейс "Проскона" ?
Нет Я даже документации по нему никакой не нашёл, настолько всё это устарело
Правда, в одном месте я смог прочесть вот что:
Цитата:
PROSCON is an HMI system developed by Outokumpu, a Finnish company which specialises in mineral processing installations.
At the heart of PROSCON is GE Fanuc's CIMPLICITY HMI software.
The PROSCON package provides easy installation and visualisation of motor and PID control.
Всё новое - хорошо забытое старое (с)
Я так понимаю ,что это редактор логики для Вашего ПЛК.
Вижу объект ПИДа и его обвязку... А как Вы поднимаете это всё "наверх" с кучей переменных? Руками? Каждый ПИД оформляете "внизу"?
Если ещё подскажете как тут вставлять картинки, то вообще будет здорово!
Контуры ПИД конфигурируются и работают непосредственно в контроллерах, никакая "куча переменных" никуда не поднимается. В отличие от DCS, где все ПИД-контура крутятся на сервере, а PV пересылается в них по сети, в контроллерах Allen-Bradley потоки информации замыкаются непосредственно там, где эта информация возникает - прямо на месте. Этим обусловлена независимость от сети и высокая реактивность управления. По сети пересылается не "куча переменных", а только то, что нужно - PV, SP, CV, A/M, а также - для любителей настраивать регуляторы руками - P, I, D-коэффициенты.
Для SCADA RSView существуют т.н. Faceplates, позволяющие оператору увидеть виртуальную переднюю панель оператора, если это нужно.
Картинки Вы можете с помощью FTP положить на какой-нибудь сервер и поместить сюда ссылку в тэгах [img] или прислать мне почтой, а я помещу. Возможности пользователя на этом форуме размещать файлы и/или картинки из соображений безопасности очень ограничены. Но можно попробовать разместить картинку - меню "Новая информация" - "Добавить картинку" (может не получиться).
Понимаю что мы толкуем об одном и том же, только несколько по разному
И Вас с наступающим!
Допускаю мысль , что мировое automation community видит такое будущее: вся инженерная мысль будет сведена к рисованию "мультиков" в каком-нибудь Скрин-Шопе и непрерывной отгрузке разнообразного железа(ПЛК)
Удачи!
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.135 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
