Контроллеры работающие с GSM модемом, всевозможные варианты Опции

[Mars]

Я к тому говорю, что при использовании раздельно среды программирования контроллера и SCADA-системы оператор не сможет нанести значительный вред, потому как будет действовать в пределах алгоритма заложенного в контроллер, в тоже время имея интегрированную среду можно изгадить даже те самые "заложенные алгоритмы".

К тому же зачем конечному пользователю переплачивать за инструмент разработчика? Это же денег стоит, не так ли? В том смысле, что это как в советские времена продавали товар "с нагрузкой" - хочешь купить один продукт, а тебе в нагрузку ненужный товар впаривают.
А если кому и надо, то купят отдельно.

[Mars]

Я к тому говорю, что при использовании раздельно среды программирования контроллера и SCADA-системы оператор не сможет нанести значительный вред, потому как будет действовать в пределах алгоритма заложенного в контроллер, в тоже время имея интегрированную среду можно изгадить даже те самые "заложенные алгоритмы".

К тому же зачем конечному пользователю переплачивать за инструмент разработчика? Это же денег стоит, не так ли? В том смысле, что это как в советские времена продавали товар "с нагрузкой" - хочешь купить один продукт, а тебе в нагрузку ненужный товар впаривают.
А если кому и надо, то купят отдельно.

[Гость_Представитель ОВЕН_*]

Или я чего то не понимаю...
Инструмент разработки что функций SCADA, что программы для контроллера бесплатен (хотя у кого то и платен - но покупается единожды - как у всех производителей конфигурируемых контроллеров типа Synco). Платится за "исполняемую" систему, которая как раз и доступна конечному пользователю:
Окна для просмотра и изменения уставок, просмотра архивов... на ПК.

Ну и берутся деньги за возможность записать программу в контроллер с помощью этой же среды.

Конечный пользователь не имеет инструмент разработки, а поэтому ничего и не может поменять ни в контроллере, ни в окнах отображения, кроме того, естественно, что ему разрешили менять при разработке проекта.

SoftLogic - удобное средство для разработчика, позволяющего ему экономить время и количество необходимых специалистов. Для заказчика все это прозрачно, ИМХО какая ему разница запрограммирован контроллер из Мастер SCADA или из CoDeSys...

А зачем платить заказчику за удобство разработчика каждый решает для себя сам. Вот мы CoDeSys не продаем, а уважаемые немецкие компании продают - что ложится на стоимость системы для заказчика. Или кто то из за этого отказался от использования контроллеров Wago?

Сообщение отредактировал Представитель ОВЕН - 25.3.2009, 15:33

[Mars]

Или я чего то не понимаю...
Инструмент разработки что функций SCADA, что программы для контроллера бесплатен (хотя у кого то и платен - но покупается единожды - как у всех производителей конфигурируемых контроллеров типа Synco). Платится за "исполняемую" систему, которая как раз и доступна конечному пользователю:
Окна для просмотра и изменения уставок, просмотра архивов... на ПК.

Ну и берутся деньги за возможность записать программу в контроллер с помощью этой же среды.

Конечный пользователь не имеет инструмент разработки, а поэтому ничего и не может поменять ни в контроллере, ни в окнах отображения, кроме того, естественно, что ему разрешили менять при разработке проекта.

SoftLogic - удобное средство для разработчика, позволяющего ему экономить время и количество необходимых специалистов. Для заказчика все это прозрачно, ИМХО какая ему разница запрограммирован контроллер из Мастер SCADA или из CoDeSys...

А зачем платить заказчику за удобство разработчика каждый решает для себя сам. Вот мы CoDeSys не продаем, а уважаемые немецкие компании продают - что ложится на стоимость системы для заказчика. Или кто то из за этого отказался от использования контроллеров Wago?

Видимо, все-таки, не понимаете.
Пример: у Honeywell есть EBI (упрощенно - инструмент для визуализации, для хранения архивов, трендов и т.д., т.е. АРМ диспетчера) и есть CARE (инструмент разработчика программ). Объясните, на кой ляд конечному пользователю эта CARE, если он сам не собирается писать программы для контроллеров? Зачем CARE интегрировать в EBI?
EBI позволяет загрузить исполняемый код в контроллеры. Собственно, позволяет также писать различные скрипты для обработки информации на верхнем уровне, но не позволяет изменять сами алгоритмы, прошитые в контроллер. И это правильно.
По поводу платного или бесплатного софта. У кого как. У иностранных брендов - в основном платный. Конечный пользователь платит за конечный продукт - SCADA. Разработчик платит за софт разработчика и работает с ним. Теперь представьте, что конечный заказчик еще должен заплатить за софт разработчика, интегрированный в SCADA. А теперь поинтересуйтесь сколько стоит тот же CARE. Оно заказчику надо?

[Гость_ggg__ggg_*]

Тут надо рассматривать несколько ситуаций.
1) Средство программирования контроллеров жестко интегрировано в некую Инструментальную Среду. Для проектов "на пару пива" это неудобно,
особенно когда SCADA не требуется. Тогда удобнее отдельная программа, с помощью которой разрабатываем и "заливаем" софт в контроллеры.
Для проектов на "пару бочек вискаря" все наоборот. Имеем цетнрализованное хранилище софта, легко поддерживается актуальность проекта.
Если кто участвовал в программных проектах, с коллективом > 2человек - тот поймет, про что речь
2) Средство программирования контроллеров МОЖЕТ быть интегрировано в некую среду, но и продается отдельно. Очень гибкий вариант, но таит в себе опасность НЕРАЗБЕРИХИ в сложных проектах.
3) Средство программирования АБСОЛЮТНО независимо от SCADA - наиболее часто встречающийся случай. Универсальные SCADA обладают ВСЕМИ НЕДОСТАТКАМИ универсальных изделий, хотя и вполне удобны для 90% проектов. Как правило, поддерживать актуальность проекта приходится ОРГАНИЗАЦИОННЫМИ мероприятиями или "самоделными" софтинами. Результат непредсказуем.

Сообщение отредактировал ggg__ggg - 26.3.2009, 8:21

[Гость_Представитель ОВЕН_*]

Полностью согласен с последним высказыванием. Что было в моем первом посте:
Больше сред программирования, хороших и разных. Мы не собираемся отказываться от CoDeSys ни при каком раскладе, но много клиентов, которые делают диспетчеризацию и проекты на "пару бочек вискаря".
И если одному АСУшнику не нужно чтобы у него было все в одном - велком - встроенные пакеты. А другому только среда программирования - тоже велком.

А для заказчика и в том и в другом случае все остается прозрачным (ну никто не будет ему даже сообщать какими средствами он разрабатывал систему).

[Гость_Роман "ВиВ"_*]

SCADА можно сравнить с хорошей должностной инструкцией. Контроллер, точно выполняющий эту должностную инструкцию, прекрасная вещь!
В современных SCADА есть библиотеки готовых решений по управлению, в т.ч. различные виды регуляторов. Задача конфигурации - выбрать из библиотеки нужный модуль, обозначить входы и выходы (обычно это делается на красивой и интуитивно понятной вкладке). Все остальное SCADА делает сама.
У меня есть видеоматериалы по обучению SCADА Freelance 800F. Могу поделиться, очень полезная информация.

Отлично, с удовольствим посмотрел бы на этого зверя!
Только сколько весит видео?
Может у тебя ссылка есть, где оно в инети висит!

[Mars]

Для проектов на "пару бочек вискаря" все наоборот. Имеем цетнрализованное хранилище софта, легко поддерживается актуальность проекта.
Если кто участвовал в программных проектах, с коллективом > 2человек - тот поймет, про что речь

Вот в этом и соль. Т.е., если рассматривать SCADA в качестве софта для разработчиков-программистов, то, наверное, в интегрированной системе смысл есть. Если же рассматривать SCADA как продукт для заказчика, то нафига козе баян?
И, кстати, если рассмотреть поподробнее ситуацию с централизованным хранилищем софта, то возникает вопрос - каким волшебным образом в этом централизованном хранилище будет постоянно обновляться проект, если 10 инженеров бегают "в поле" каждый со своим ноутом и со своей чудесной интегрированной SCADA?
ЗЫ. Доводилось принимать участие в проектах, где из одного конца объекта до другого идти не меньше 30 минут, и разок в проекте трубы (1500 км).
Естественно, команда гораздо больше 2 человек.

[Гость_Представитель ОВЕН_*]

И, кстати, если рассмотреть поподробнее ситуацию с централизованным хранилищем софта, то возникает вопрос - каким волшебным образом в этом централизованном хранилище будет постоянно обновляться проект, если 10 инженеров бегают "в поле" каждый со своим ноутом и со своей чудесной интегрированной SCADA?

Что, и все 10 имеют право вносить изменения в проект для контроллера??? Я бы в поле не дал на уже отлаженном проекте всем руки сувать - назначил бы одного, который имеет право исправление в работу вносить...так сказать "главного вносителя". Правда к чести сказать опыта таких проектов не было...

Если речь идет о групповой разработке в офисе (когда один проект пишут несколько человек) - можно для CoDeSys докупить специальное приложение ENI server. Возможно что то такое и у интегрированных пакетов есть.

[Mars]

Что, и все 10 имеют право вносить изменения в проект для контроллера??? Я бы в поле не дал на уже отлаженном проекте всем руки сувать - назначил бы одного, который имеет право исправление в работу вносить...так сказать "главного вносителя". Правда к чести сказать опыта таких проектов не было...

Если речь идет о групповой разработке в офисе (когда один проект пишут несколько человек) - можно для CoDeSys докупить специальное приложение ENI server. Возможно что то такое и у интегрированных пакетов есть.

А дело видите ли в том...
Хорошо, программы для контроллеров написаны, залиты в них. Начинается процесс пуско-наладки. В каждом цеху по 20-30 приточных установок, немерено вытяжек, ОЗК и пр. И таких цехов с десяток, а то и более. При этом нужно соблюдать не только температурно-влажностные характеристики подаваемого воздуха, но и перепад давления в "чистых" и "грязных" помещениях. Сколько времени один инженер будет бегать по такому "полю"?
Поэтому 10 человек и трудятся. Естественно, каждый вносит в проект различные коэффициенты ПИД, уставки, графики и т.п. Это как минимум. Как эти актуальные исправленные коды попадут в замечательную интегрированную SCADA? Все-равно ручками. А когда уже все отлажено-налажено, то и лезть в алгоритмы незачем, соответственно, зачем в этой SCADA инструмент разработчика? Пусть меняют уставки или что им там позволено, а не налаженные алгоритмы.

[Гость_ggg__ggg_*]

to Mars
Вся "фишка" в том, КАК процесс орагнизовать Если SCADA (точнее, некая Интегральная Среда Разработки) устроена так, что залить программы в контроллеры можно ТОЛЬКО через нее, то ВЫ в ЛЮБОЙ момент имеете в ее базе АКТУАЛЬНЫЕ коды. Более того, изменения в параметры программы Вы вносите тоже ТОЛЬКО через нее, то бишь коннектитесь к контроллеру. работаете с загруженым софтом, потом завершаете сеанс - и в базе данных оказывается ИМЕННО АКТУАЛЬНАЯ прога. Далее, Вы преспокойно переводите систему в режим RunTime (например, поменяв аппаратный ключ) и спокойно передаете систему Заку. Понятно. что если попадется ну дюже профессиональный программер в СЭ Зака, то он может и залесзть куда не надо. Но это очень маловероятная ситуация. к тому же "против лома нет приема".
А теперь , в любой момент, когда потребуется модифицировать программы, Вы приезжаете к Заку, меняете ключ или коннектитесь к серваку через свой ноут с требуемым правом доступа - и перед вами актуальные проги. Вносите изменения , которые опять же прописываются в базе ИСР - и расстаетесь "до лучших времен". Если не доверяете способности Зака сохранять данные - делаете копию ИСР или ее отдельных баз ШТАТНЫМИ, проверенными средствами. Никакого бардака с версиями. уволившимися программистами и прочее...
Что характерно, одновременно могут работать хоть 2, хоть 100 программеров, причем как локально, так и удаленно. SCADA будет "подхватывать" данные "на лету", сразу видны проблемы с точками и контроллерами.
Единственный минус таких систем (кроме дороговизны ) - это то, что они, как правило, "заточены" под конкретного производителя оборудования. Но на серьезных объектах плодить "зверинец" как-то не принято. ИМХО, конечно....

[Mars]

to Mars
Вся "фишка" в том, КАК процесс орагнизовать Если SCADA (точнее, некая Интегральная Среда Разработки) устроена так, что залить программы в контроллеры можно ТОЛЬКО через нее, то ВЫ в ЛЮБОЙ момент имеете в ее базе АКТУАЛЬНЫЕ коды. Более того, изменения в параметры программы Вы вносите тоже ТОЛЬКО через нее, то бишь коннектитесь к контроллеру. работаете с загруженым софтом, потом завершаете сеанс - и в базе данных оказывается ИМЕННО АКТУАЛЬНАЯ прога. ...

Т.е. Вы предлагаете начинать строительство дома с крыши, а не с фундамента?
Применительно к автоматике получается, что мы должны сперва установить на объект SCADA с интегрированной средой разработки, обвязать все контроллеры и заливать в них алгоритмы, сидя в диспетчерской, а не бегая по полям с обордуванием. А еще лучше вообще сидеть у себя в офисе или дома на диване и пусконалаживать объект в каком-нибудь Якутске. Мечта инженера пусконаладчика! Жаль, мало соответствует реальности. Соответствует только в той части, что и в обычной системе ничто не мешает заливать сеть контроллеров через SCADA (по крайней мере, EBI это точно позволяет), но это можно делать тогда, когда уже все отлажено и в этой SCADA хранятся актуальные откомпилированные алгоритмы для контроллеров.
А делать ПНР, все-таки, приходится в поле. В поле заливать проги, в поле смотреть как и что отрабатывает, в поле производить юстировку и пр. и пр. Или предлагаете пойти в поле посмотреть, как там что работает, прикинуть параметры ПИД, пойти в диспетчерскую, где стоит сервак с замечательной интегрированной SCADA, внести там новые параметры, снова отправиться в поле наблюдать за установкой и обнаружить, что параметры нужно снова менять? Отличная организация труда! А если еще учесть особенности строительства, когда всем не до SCADA, а нужно вводить в работу сперва один объект, затем второй, третий и т.д., а уже потом думать о SCADA.
ИМХО, утопия эта интегрированная SCADA. Заливать контроллеры через SCADA - пожалуйста, если там по каким-то причинам прога слетела или контроллер заменили, а в процессе ПНР объекта - нереально.

[Гость_Представитель ОВЕН_*]

Mars, попробуйте услышать что Вам говорят:
Не из SCADA системы происходит программирование проекта.
Вы же понимаете, что система программирования контроллеров не достается клиенту, и не ставится на объекте - клиент просто получает контроллер программой.
Так же и для отрисовки и создания визуализаций, которые будут стоять у клиента существуют свои средства разработки (инструментальная система) - опять же сугубо ресурс разработчика интерфейса.
Сейчас в инструментальные системы для разработки визуализации для заказчика добавлены средства полного цикла управления, включая как ERP системы сверху над отображением процессов, так и возможность программировать контроллеры из этого же инструмента для разработчика.
То есть Вы имеете глобальный ресурс, в котором описываете и простраиваете систему с низу до верху.
И этот инструмент (инструментальная система) никак не попадает к заказчику, к нему попадают только Ваши результаты работы в этом инструменте, такие как запрограммированные контроллеры, приложение на ПК, где Вы четко регламентировали какие значения параметров клиент может изменять (и отсюда клиент при всем желании не может менять именно программу в контроллерах, а не значение параметров - надо эти вещи разделять).

И как Вы думаете, наверное удобно, когда у Вас в одной системе разработке и визуализация, и одна программа на все Ваши 10 контроллеров, стоящих на расстоянии километра друг от друга (естесственно при условии, что они объеденены в сеть с ПК).

Mars, попробуйте услышать что Вам говорят:
Не из SCADA системы происходит программирование проекта.
Вы же понимаете, что система программирования контроллеров не достается клиенту, и не ставится на объекте - клиент просто получает контроллер программой.
Так же и для отрисовки и создания визуализаций, которые будут стоять у клиента существуют свои средства разработки (инструментальная система) - опять же сугубо ресурс разработчика интерфейса.
Сейчас в инструментальные системы для разработки визуализации для заказчика добавлены средства полного цикла управления, включая как ERP системы сверху над отображением процессов, так и возможность программировать контроллеры из этого же инструмента для разработчика.
То есть Вы имеете глобальный ресурс, в котором описываете и простраиваете систему с низу до верху.
И этот инструмент (инструментальная система) никак не попадает к заказчику, к нему попадают только Ваши результаты работы в этом инструменте, такие как запрограммированные контроллеры, приложение на ПК, где Вы четко регламентировали какие значения параметров клиент может изменять (и отсюда клиент при всем желании не может менять именно программу в контроллерах, а не значение параметров - надо эти вещи разделять).

И как Вы думаете, наверное удобно, когда у Вас в одной системе разработке и визуализация, и одна программа на все Ваши 10 контроллеров, стоящих на расстоянии километра друг от друга (естесственно при условии, что они объеденены в сеть с ПК).

[Mars]

Mars, попробуйте услышать что Вам говорят:

Mars, попробуйте услышать что Вам говорят:

Ветер с моря дул
Ветер с моря дул

Не надо мне два раза повторять.
Это как раз я говорю о том, о чем Вы мне дважды написали.
Не нужна конечному заказчику инструментальная среда, ему нужен конечный продукт, и не в его интересах платить за интегрированную в SCADA среду разработчиков.
А тут люди говорят о некоей интегрированной SCADA, которая и швец и жнец и на дуде игрец. То о чем Вы мне пишете называется не SCADA, а как раз средства разработки. Та же CARE от Honeywell позволяет создать алгоритм для контроллера, сконфигурировать железо, описать Lon-переменные, создать документацию, экспортировать проект для затягивания точек в EBI и т.п.
А в SCADA так или иначе нужно будет прорисовывать графику и привязывать графические элементы к точкам данных. Не думаю, что точки самостоятельно (автоматически) будут привязываться к графическим элементам, о которых еще не догадывается даже тот, кто рисует графическую оболочку в соответствии с хотелками заказчика.
И в чем тогда удобство совмещения среды программирования и визуализации? Нет, конечно, можно сделать так, что при создании в CARE модели объекта управления Schematic автоматически будет генерироваться модель визуализации объекта и точки данных будут сразу же привязываться к графическим элементам. НО! Думаете, что всех заказчиков устроит полученная в результате визуализация? Это еще только когда дело касается каких-нибудь вентустановок. А если пойти дальше? Например, поэтажная схема системы пожарной сигнализации. Как там будет генерироваться графика? Куда будут привязываться состояния датчиков и модулей?
В общем, не надо иллюзий относительно замечательной интегрированной SCADA. К тому же Вы говорите, что инструментальная система не попадает к заказчику. А куда она девается? Самоуничтожается после ПНР и удаления инженерного лицензионного ключа или чудесным образом переписывается на Ваш ноут? Причем, инженерная часть лицензии переписывается, а для визуализации остается у заказчика, но у Вас, тем не менее, получается снова полнофункциональная интегрированная SCADA, т.е. лицензия для визуализации размножается. Ах, да! Еще забыл. У Вас на компе должна быть суперлицензия, которая включает в себя все мыслимые и немыслимые протоколы, ОРС-сервера, драйвера, поддержку работы с видео, пожаркой, охранкой, СКУД и еще не знаю с чем. Ведь эта интегрированная SCADA должна быть у разработчика универсальной. Вы же не знаете какие требования завтра выдаст заказчик.

[Гость_Представитель ОВЕН_*]

Понятно, это называется спорим об одном и том же... оба умные
Считаю больше постить на эту тему не стоит. Кому это действительно нужно и интересно разберутся что такое SCADA и какие ключи нужны для неё и что такое система разработки, и какие ключи нужны для неё. Ну а кому не надо, так ведь тоже прав.

[Mars]

Именно.
Внесли тут путаницу с определениями SCADA, смешали все в кучу...
А все уважаемый господин директор со своими понятиями об автоматизации.

[Гость_Представитель ОВЕН_*]

Именно.
Внесли тут путаницу с определениями SCADA, смешали все в кучу...
А все уважаемый господин директор со своими понятиями об автоматизации.

Путаницу не вносили - рассказали о дополнительной возможности
А то что у нас с Вами вышло недопонимание по терминам, так тут чего уж поделаешь...

[Гость_ggg__ggg_*]

Действительно, диспут несколько витиеватым путем идет. Kassa не хватает. Придет - и всех построит....
Теперь о сути вопроса.
Настройка параметров программы в контроллере. С моей точки зрения, глупо платить за возможность отображения трендов в средстве программирования контроллеров, если эта возможность ОТЛИЧНО реализована практически в ЛЮБОЙ SCADA. Таким образом, совершенно незачем бегать с ноутом от контроллера к контроллеру и настраивать опции типа ПИДовских. Смотрим на тренд в SCADA и спокойно, в достаточно комфортных условиях, корректируем параметры проги и смотрим на резалт в виде трендов. На ВНУТРЕННЕМ языке SCADA( 90%) или на ДРУГИХ языках пишется софт, который анализирует тренды и подправляет параметры. Да, такая технология требует начальных затрат, но потом РЕЗКО снижает "количество пива и сигарет на одну единицу управления "
SCADA есть МАЛЕНЬКИЙ кусок Интегрированной Среды, причем ОРС туда редко входит, т.к. есть "тело инороднее для SCАDA" по своей природе.
При покупке практически ЛЮБОЙ SCADA заказываются ДВА ключа - Инженерный и Исполнительный. Стоимость отличается СУЩЕСТВЕННО. По окончании работы на объекте, Инженерный ключ забираем себе, а Исполнительный оставляем Заку (он именно его и оплатил ). Инженерный ключ покупается, как правило, ОДИН раз. Как-то менторски получилось....
Еще момент. Если на объекте предусмотрена ДИСПЕТЧЕРИЗАЦИЯ, то СЕТЬ строится сразу и по проекту. Так что к Диспетчерской протянут сразу. Заодно и протестируем, пока до контроллеров "достучимся".
Что касается автопостроения картинок, то достаточно иметь НАБОР ActiveX, чтобы Зак выбрал нужные картинки. Структуры же данных (в абстрактном виде) описываются на этапе проектирования (собственно, с этого программный проект и начинается). Так что рисовать картинки и привязывать их к точкам можно СОВЕРШЕННО НЕЗАВИСИМО от работы программистов по контроллерам. Если же что вдруг поменяется, то, при загрузки софта через Интегрированную Среду, будет СРАЗУ ясно, какие точки диспетчеризации исчезли, а каке появились вновь. Тем самым решается проблема ОЧЕПАТОК.

Сообщение отредактировал ggg__ggg - 27.3.2009, 14:50