Промышленны nano-PLC на ATmega 128 16AU, Контроллер Миллениум3 фирмы КРУЗЕТ (Франция) Опции

[АндрейХ]

Промышленный nano-PLC фирмы КРУЗЕТ (Франция) на ATmega128-16AU

Люди добрые, поможите чем сможите...
Признаюсь сразу - я не программер железа (говорила мне мама -"Учи ассемблер" ), а системный интегратор, инженер АСУТП.
В наличии имеется прелестная французкая коробочка под милым названием - ПЛК (программируемый логический контроллер) Миллениум3 и всё необходимое ПО для работы с контроллером.
Проблема - всё устраивает в ентой штуке акромя возможности самостоятельно добавить в библиотеку свои FBD (функциональные блоки). Фирма выпускает допбиблиотеки оформленные в виде DLL файлов, но я не шарю в этом, тем более там нужны знания программирования как под Винду так и под АВР...
Может кто подсабит? Нужно либо создать порядка пяти недостающих мне FBD-блоков (ждать когда КРУЗЕТ разродится бесполезно - знаю по опыту что от производителей можно ждать выпускать дополнений несколько лет), или есчо лучше какой-нето инструментик для создания своих дополнений.
Что могу предложить взамен - полный комплект ПО, фотки внутренностей контроллера, и рекомендации по организации ПО для данных типов контроллеров (имеется опыт использования nano-PLC на протяжении пяти лет).
Может кто захочет выпускать аналоги. Данный сегмент рынка очень слабо развит, и есть достаточно большая ниша...
Фотки данного чуда можно взять здесь - http://ip.ifolder.ru/4175601

[anpilog]

Ой!
Где-то я это чудо уже видел 8)
Зачем Вам забивать гвозди микроскопом????
Возьмите другой PLC с возможностью нормального (IEC 61131–3) программирования и не заморачивайтесь.
Благо дело их в последнее время на рынке стало гораздо больше.

[АндрейХ]

Возьмите другой PLC с возможностью нормального (IEC 61131–3) программирования и не заморачивайтесь.
Мысль далеко не оригинальная...
Если вы имеете ввиду Step7 или CoDeSys то мы енто проходили:
1. Высокая стоимость PLC относительно nano-PLC. При решении простых задач автоматизации на S7-200 выходит что вы возите коробок спичек на Камазе... и себестоимость таких "игрушек" для заказчика неподъемная...
2. Step7 и CoDeSys мощные пакеты программирования и сходу их не одолеть, а если нужно быстро решить простую задачку? В CoDeSys так с одной конфигурацией будете разбираться фиг знает сколько, при чем для каждого типа контроллера свои причуды с таргетами... и недокументированными (ну забыли описать в доке, бывает... ) заморочками...
Другое дело что ПО малышек nano-PLC желательно привести к стандарту. Но есть одно но - IEC 61131–3 имхо не идеал, в нём то-же много неудобств...

[prottoss]

...а если нужно быстро решить простую задачку? ...

Два варианта -

1. Осваиваете по-быстрому AVR и пишете не казистое приложение, которое в процессе вылизываете

2. Нанимаете более-менее AVR-программера:-) и он Вам за пару-тройку недель сваяет, так необходимое Вам, чудо.

[oran-be]

Интересная железка - ПЛК на МЕГЕ. До этого попадались на 188, АРМ и старые - на 51-х. Можно попробовать через личку списаться - может чего и получиться. Не нравится мне в этих контроллерах отсутствие гальваноотвязки по входам.

[АндрейХ]

prottoss
Отвечаю - для данных типов ПРОМЫШЛЕННЫХ контроллеров как и положено продается ПО (не дорого, всего 30 евриков без ограничения использования, кабель стоит в 2 раза дороже), в котором работаете на ЯВУ инженера - языке МЭК (LD, FBD...), типа как в LABView, и им подобным. Принцип прост, всё визуально, программу создаете наподобе микросхем, проводов и паяльника... для электрика, электронщика и КИПиА енто самое оно... И не надо даже знать чё внутри ентой коробки, и уж тем более программировать на низком уровне.
А вот с расширением библиотек проблема - либо создавать макросы, либо просить фирму разработчик ПО. И то и другое не лучший вариант...
В CoDeSys с ентим дело обстоит гораздо лучше, можете создавать свои FBD на ассемблероподобном, или Си подобных языках, потом тестите, компилите, и создаете свой пакет (вплоть до защиты авторских прав для продажи). Но по большому счету енто монстр в сравнении с ПО для nano-PLC. И контроллеры под CoDeSys стоят как минимум в 2 раза дороже nano-PLC, потому как требуют солидных ресурсов для "мозгов"...

oran-be
Отвечаю - использовал до КРУЗЕТа три года nano-PLC Митсубисши ALPHA XL без всяких гальваноразвязок и по дискретным, и по аналоговым входам. За всё время был убит только один контроллер, юги умудрились вернуть в щит сигнал вместо "сухого" контакта фазу. Пару раз сварочные работы при работающем щите убивали нормирующий усилитель для ТСМ (устанавливаются между датчиком и ПЛК). И получается что для обычных объектов (без повышенных электромагнитных помех) экономически оправдано использование простых систем. Для аналоговых сигналов лучше использовать низкоомные цепи, например датчики с токовым выходом 0-5, 0-20, 4-20мА (на цену не влияет) с экранированным кабелем.

Сообщение отредактировал АндрейХ - Dec 2 2007, 11:50

[anpilog]

Хмм....
Мне казалось что цена этих контроллеров не намного меньше того же beckhoff'а.
Приведите стоимость...

ЗЫ:
По поводу монстроидальности CodeSys и т.д. - не увидел ничего сложного...
Ну ничего....
Даже с учетом недочетов в документации и т.д.
Геморрой от нефункциональности как правило (Ваш случай это и подтверждает) гораздо болезнен чем цена.

Давайте сравним цены.

[АндрейХ]

anpilog
Отвечаю - Миллениум3 26 I/O: 10 дискр.входов + 6 аналог.входов 10 бит (дельта 100гр.Ц с шагом 0,1 гр.) + 10 реле выход + 16х4 дисплей + 6 кнопок. Память на 300 FBD блоков = стоит 6000 руб.

Данный контроллер без усилий (со знанием дела) позволяет создать устройство САУ для "классического" теплового пункта с двумя контурами регулирования - контура отопления, и контура ГВС. Можно создать САУ полного кондиционера с контуром нагрева и охлаждения. По цене с учетом стоимости программирования и отладки данное устройство сопоставимо со стоимостью "классических" (железных) вариантов САУ даже на отечественных устройствах автоматики.
Для полного счастья мне не хватает 5 FBD блоков которые я могу организовать за счет существующих, но с избыточным кодом. Если добавить низкоуровневые недостающие блоки то будет совсем прекрасно.

Назовите цену Бенкофа с такими-же данными.

П.С. Вы программировали контроллеры в CoDeSys? Я не имею ввиду игру с эмуляцией. Ну и как?
Только документация по CoDeSys занимает буклетик в 300 листов мелкого текста. А еще нужно прибавить сотенку листов документации по конкретному контроллеру.
Step7 весит не меньше, но документирован грамотнее.
По хорошему для эффективной работы с такими системами необходимо потратить пару месяцев на обучение. И это с учетом того что с системой будет работать не ПТУшник, а более-менее подготовленный инженер.
И еще, МЭК развивается почти три десятка лет и до сих пор так и не стал полноценным стандартом (как например Си - вроде было только две редакции), и находится в стадии бесконечной доработки. В МЭК еще много противоречий и нестыковок. А про то что-бы признать его общим стандартом всеми производителями ПЛК включая старейших производителей Сиеменс и Митсубисши я вааще промолчу... Всё это связано не с противоречиями и конкуренцией фирм, а с тривиальными аппаратными различиями и возможностями аппаратных средств контроллеров, которые МЭК не в состоянии учесть. Используется такой выход - отдельно документируются отступления от МЭК (так сделано и в Step7 и в CoDeSys), но это уже НЕДОСТАНДАРТ.

Сообщение отредактировал АндрейХ - Dec 2 2007, 21:57

[SasaVitebsk]

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

Дело в том, что сделать можно всё. Но есть такие проблемы как тестирование готового изделия (представляющего из себя контроллер) что очень трудоёмкий и времяёмкий процесс, разработка ПО второго уровня в виде готовых библиотек (с теми же проблемами), Разработка документации с примерами и тестирование данных примеров и т.д. и т.п. То есть то что вам кажется простым - тянет за собой шлейф побочных проблем. Это НЕРЕАЛИЗУЕМО в единичном экземпляре. Такие вещи надо делать серией. Желательно большой. Иначе это зашкалит все ваши мыслемые оценки данного труда.

Я считаю, у вас есть два выхода.
1) Изучить рынок и преобрести другое изделие, более подходящее под ваши задачи.
2) Составить ТЗ и заказать новое изделие, в котором учтены все ваши замечания.

Доработка же готового неизвестным специалистом, за три рубля, приведёт к непредсказуемому поведению и отсутствию ответчиков за данное поведение прибора.

[oran-be]

Отвечаю - использовал до КРУЗЕТа три года nano-PLC Митсубисши ALPHA XL без всяких гальваноразвязок и по дискретным, и по аналоговым входам. За всё время был убит только один контроллер, юги умудрились вернуть в щит сигнал вместо "сухого" контакта фазу. Пару раз сварочные работы при работающем щите убивали нормирующий усилитель для ТСМ (устанавливаются между датчиком и ПЛК). И получается что для обычных объектов (без повышенных электромагнитных помех) экономически оправдано использование простых систем. Для аналоговых сигналов лучше использовать низкоомные цепи, например датчики с токовым выходом 0-5, 0-20, 4-20мА (на цену не влияет) с экранированным кабелем.

В свое время при развитии наших контроллеров мы встали перед выбором - делать гальваноотвязанные входы или нет. Элементарный расчет показал, что гальваноотвязаный вход стоит примерно центав на 5-7 дороже, зато сколько удобств! В особенности, если надо соединить по логике два контроллера в разных шкафах. И было принято боевое решение от негальванически отвязанных входов отказаться напрочь. Еще одна неприятная вещь в этих контроллерах - отсутствие расширения. На практике, если имеется в наличие контроллер, у которого 12 входов и 8 выходов, первой появляется задача, в которой для обеспечения техпроцесса необходимо иметь 13 входов и 9 выходов - все согласно занонам Мерфи

Доработка же готового неизвестным специалистом, за три рубля, приведёт к непредсказуемому поведению и отсутствию ответчиков за данное поведение прибора.

Кстати. это не факт. В наших контроллерах также используются блоки, но в большинсве случаев это не более 10-15 строк ассемблерного кода. Конечно, если этот блок -не ПИД регулятор. Главное - нормальное объяснение, как эти блоки ваять.

[AlexG_changed]

АндрейХ
Каких именно функциональных блоков вам не хватает?
Думаю, можно попробовать разобраться в устройстве фирменных DLL. У меня, к сожалению, нет Крузетовской среды разработки (только родственная ей Шнайдеровская) чтобы посмотреть что там к чему, может подкинете?

Есть приличный опыт программирования вот таких контроллеров на C/C++. Millenium 3 при желании тоже можно было бы перевести на C, отказавшись от FBD. С позволяет заложить в контроллер гораздо более сложную программу и получить высокое быстродействие, но за это приходится расплачиваться временем разработки.

Вообще, у Millenium 3 и Zelio Logic наверное лучшая среда разработки в этом классе контроллеров, главная проблема - мало памяти. Самому очень интересно что можно из них выжать.

В материалах по Millenium 3 упоминаются заказные функции, может просто обратиться к производителю?

Сообщение отредактировал AlexG - Dec 3 2007, 08:50

[alexander55]

В свое время при развитии наших контроллеров мы встали перед выбором - делать гальваноотвязанные входы или нет. Элементарный расчет показал, что гальваноотвязаный вход стоит примерно центав на 5-7 дороже, зато сколько удобств!

5-7 центов оптроны не стоят.
Если приведете такие, будет очень здорово.

anpilog
Отвечаю - Миллениум3 26 I/O: 10 дискр.входов + 6 аналог.входов 10 бит (дельта 100гр.Ц с шагом 0,1 гр.) + 10 реле выход + 16х4 дисплей + 6 кнопок. Память на 300 FBD блоков = стоит 6000 руб.

По железу даже с гальваноразвязкой входов себестоимость (без накруток на отработанном изделии) в 3000 руб должна влезть.

[anpilog]

Хммм....
Цена на КРАУЗЕР действительно интересная.
Но мое мнение совпадение с SasaVitebsk.
Лучше мастерски владеть одной/двумя средами и платформами, чем биться головой об стену по законам Мэрфи.
Все это ИМХО.

[AlexG_changed]

Лучше мастерски владеть одной/двумя средами и платформами

А почему бы Крузет Millenium 3 не быть этой платформой?
А если серьезно, задачи довольно разнообразны и пока не нашлось такой одной платформы которая хорошо подошла бы для большинства наших задач. Тут как с МК, найдется работа и для ATtiny и для ATmega и для ARM9 тоже найдется.

Сообщение отредактировал AlexG - Dec 3 2007, 10:33

[anpilog]

А почему бы Крузет Millenium 3 не быть этой платформой?
А если серьезно, задачи довольно разнообразны и пока не нашлось такой одной платформы которая хорошо подошла бы для большинства наших задач. Тут как с МК, найдется работа и для ATtiny и для ATmega и для ARM9 тоже найдется.

Опять таки - согласен.
Просто личный опыт говорит, что чем всеобъемлющей будет такая технология, тем легче по жизни 8)

[oran-be]

5-7 центов оптроны не стоят.
Если приведете такие, будет очень здорово.

китайцы К1010 стоят 11 центав в розницу. Минус стоимость защитного стабилитрона в случае использования прямого входа.

[alexander55]

китайцы К1010 стоят 11 центав в розницу. Минус стоимость защитного стабилитрона в случае использования прямого входа.

Спасибо, Вы меня приятно удивили. Я ориентировался на оптроны типа TLP181, TLP126 в корпусе Mini Flat. Они дороже раза в 3.

[АндрейХ]

SasaVitebsk
Естественно что функциональность урезана, что вы хотите за 30 евро со всеми налогами...
По поводу вседозволенности - т.е. разработке низкоуровневых функций. Как быть с CoDeSys где вам дается полная свобода? При определенных знаниях и наглости вы можете приспокойно ковырять даже таргеты... Просто вся ответственность ложится на интегратора (о чем пишется в гарантийных соглашениях/обязательствах. Митсубисши обычно пишет так - "НИ при каких условиях.... Не несет ответственности, ну и т.д...."). По поводу других изделий - нет аналогов по такой цене даже в отчизне. У меня на стенде щас стоят гораздо более крутые отчественные приборы ОВЕН ПЛК100, ПЛК150, МВА8, ИП320, ну и конечно последний CoDeSys с обвязкой по Internet, MODBUS, RS-232. Вещь достаточно мощная за приемлемую цену, НО в эквиваленте вх./вых. в два раза дороже Миллениум3. Предполагается использовать ОВЕН как Master в сети и одновременно шлюз MODBUS-Internet, или на ответственных объектах где Миллениум3 не тянет. Вот в этой роли ОВЕН себя оправдывает на все 100...
oran-be
До Крузета 3 года использовался Митсубисши ALPHA XL без всяких гальваноразвязок. За все время из кучи установленных ПЛК умер только один, и то юги умудрились вместо "сухого" контакта дать фазу. А так даже сварочные работы при включенном оборудовании не убили, а вот несколько отечественных нормирующих усилителей для ТСМ померло...
Миллениум3 покруче ALPHA XL за то-же бабло. И кстати к КРУЗЕТу пристегивается модуль расширения (почти удваивается кол-во вх/вых). и сетевой модуль MODBUS RTU (50 евро), либо Internet.
Практика показывает, что при правильном подходе к сему девайсу на одной коробке можно сделать САУ "классического" теплового пункта с контуром отопления и подпиткой, ГВС и ХВС. На крайняк можно нацепить модуль расширения и сетевой модуль, что увеличит стоимость железки всего на 120 евро.
Даже на отечественных ПЛК по цене такого пока не получается, а у меня три года работают несколько ЦТП на АЛЬФАх (Миллениум3 есчо круче) и никаких проблем (до этого стояли ПЛК Джонсон-Контролз, которые за несколько лет задолбали эксплуатацию своей тупизной... )

AlexG
Лирическое отступление:
Си - язык программистов, а LD и FBD язык инженеров-электриков и КИПиА. Этим всё сказано. Например LD начал использоваться одновременно с появлением первых промышленных ПЛК, а Си стал применяться гораздо позже. Я не понимаю причину его использования для ПЛК в "чистом" виде. Имхо не обижайтесь, но программеры очень далеки от электрики и КИПиА, и если знают, то в большинстве теоретически. Программист_Си-КИПовец это уникум, таких единицы, и я пока не встречал таких. Прекрасных программеров Си - да, прекрасных КИПовцев и электриков - да, а всё в ОДНОМ нет... Слишком обширная получается сфера деятельности, и вместить её в одного спеца крайне сложно, необходимо как минимум два высших образования (10 лет обучения это не хило, одно из двух будет успешно забыто).
По поводу - каких FBD не хватает для сщастья:
Чисто аналоговых с возможностью задания параметров как internal, так и external, дополнительно должны быть дискретн. входа управления Работа/Стоп и Сброс. Желательна возможность запоминания текущих значений в независимой памяти при отключении ПЛК.
1. Ограничитель сигнала с внутренним/внешним заданием ограничений
2. НЧ фильтр сигнала с внутренним/внешним заданием Тф - демпфирование. (аналог RC-фильтра)
3. Задатчик зоны нечувствительности (неоднозначности) - можно объединить с ограничителем сигнала.
4. Задатчик скорости изменения параметра - не зависимо от величины входного сигнала (работа по вектору -1 0 1) на выходе изменяется параметр с заданной скоростью.
5. Ограничитель скорости изменения вх. параметра (не быстрее заданной скорости), можно объединить с Задатчиком скорости.
6. И на закуску Интегратор с ограничением по заданному мин. и макс. уровню.
Наиболее востребованные FBD - 1.2.3.4.6
Этого достаточно что-бы на этой малышке делать полнофункциональные ПИД регуляторы для процессов с реакцией 0,1 сек + связанное управление (или наоборот - автоматическое управление с интегрированной САР). В большинстве случаев вполне хватает ПИ-регулятора (Изодромного регулятора). Мне на АЛЬФЕ удалось реализовать ПДД' регулятор, не уступающий Минитерму.

Сообщение отредактировал АндрейХ - Dec 3 2007, 14:04

[SasaVitebsk]

SasaVitebsk
По поводу вседозволенности - т.е. разработке низкоуровневых функций. Как быть с CoDeSys где вам дается полная свобода? При определенных знаниях и наглости вы можете приспокойно ковырять даже таргеты... Просто вся ответственность ложится на интегратора (о чем пишется в гарантийных соглашениях/обязательствах. Митсубисши обычно пишет так - "НИ при каких условиях.... Не несет ответственности, ну и т.д...."). По поводу других изделий - нет аналогов по такой цене даже в отчизне. У меня на стенде щас стоят гораздо более крутые отчественные приборы ОВЕН ПЛК100, ПЛК150, МВА8, ИП320, ну и конечно последний CoDeSys с обвязкой по Internet, MODBUS, RS-232. Вещь достаточно мощная за приемлемую цену, НО в эквиваленте вх./вых. в два раза дороже Миллениум3. Предполагается использовать ОВЕН как Master в сети и одновременно шлюз MODBUS-Internet, или на ответственных объектах где Миллениум3 не тянет. Вот в этой роли ОВЕН себя оправдывает на все 100...

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

Я сталкивался с парой тройкой приборов "Овен". Они произвели на меня очень тягостное впечатление.
1. Использовать без инструкции - надо быть гением в третьем колене с феноменальной памятью.
2. Эргономика - никакая. Я не про корпуса, я про расположение и назначение кнопок а также выводящиеся сообщения порой просто вводят в ступор.
3. Внутренние протоколы совместимы только м/у собой и продуманность их весьма сомнительна.

Правда это достаточно древние изделия. Возможно новые изделия значительно лучше стали.

Мне, как разработчику, интересна эта тема. Если можно дайте ссылку на описываемый контроллер (описание), а также опишите кратко чега Вам катастрофически недостаёт. Процесс разработки такого изделия оцениваю примерно в 10-12 месяцев в зависимости от загрузки и требований, так что на меня расчитывать глупо. Но, возможно, мы займёмся данной тематикой в будущем.
Заранее спасибо.

[AlexG_changed]

Если можно дайте ссылку на описываемый контроллер (описание)

ОВЕН ПЛК 100/150/154

[amusin]

АндрейХ,
Непонятно, что вы имеете в виду под "полным комплектом ПО", но вряд ли это исходные файлы адаптации миллениума для меги128.

У меня встречный вопрос. Есть ли российское ПО, аналог CoDeSys'а? Можно даже без строгого следования МЭКу 61131-3.

[AlexG_changed]

У меня встречный вопрос. Есть ли российское ПО, аналог CoDeSys'а? Можно даже без строгого следования МЭКу 61131-3.

Российское ПО для разработки на МЭК-языках есть. Аналога такой мощной и сложной системы как CoDeSys - нет. Вот только какое значение имеет страна происхождения ПО?

[АндрейХ]

amusin
Я имею ПО среды разработки (80 мегов) к Миллениум3 + дополнительные исполняемые библиотеки. Конечно исходников у меня (да и ни у кого) нет. Вот в том -то и вопрос - надо "посмотреть" енто ПО с лупой. Меня лично интересует только возможность добавить несколько своих аналоговых FBD-блоков (написать на низком уровне, а не в виде макроблока) в виде DLL, и добавить по возможности кириллицу.
В остальном данный контроллер меня полностью устраивает как по надежности и быстродействию, так и по удобству программирования (хочется лучшего, но хотение бесконечно...)
А обсуждать какой контроллер и какое ПО круче я не собираюсь, для этого существуют соответствующий форумы.

[amusin]

Российское ПО для разработки на МЭК-языках есть. Аналога такой мощной и сложной системы как CoDeSys - нет. Вот только какое значение имеет страна происхождения ПО?

CoDeSys я назвал не столько из-за мощи, сколько из-за универсальности - возможности сделать адаптацию под любую платформу.
Обзор делаю для проекта. Есть много немцев, французы есть, чехи. А про наших не попадалось.
При прочих равных почему не купить российское?
Какие среды разработки вы можете назвать? Интересуют именно универсальные продукты независиых фирм-разработчиков.

[alexander55]

Какие среды разработки вы можете назвать? Интересуют именно универсальные продукты независиых фирм-разработчиков.

ISaGRAF, если Вы имеете ввиду среда разработки (моделирования) для пользователя.

[АндрейХ]

Как я понимаю здесь тусуются в основном разработчики embedded (встраиваемых) систем, поэтому сделаю маленький экскурс в историю ПЛК (программируемых логических контроллеров).
Появились эти устройства у зарубежников. Начнем с того что автоматизации как отрасли у них не существует - нет инженеров КИПиА и специальности "Автоматизация технологических процессов". Автоматизация - это всего лишь подраздел отрасли, направления. У Сиеменса есть департамент автоматизации, а сама фирма электротехническая. Данная ситуация наложила свой отпечаток на развитие ПЛК. Основное назначение ПЛК было замена релейных схем, и первый язык программирования ПЛК был - LD, язык релейных схем. И только позже в ПЛК начали появляться аналоговые входа/выхода, а позже ПИД регуляторы. При этом первые регуляторы были организованы аппаратно (выпускаются до сих пор) как модули расширения для ПЛК.

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

Теперь перейдем к концепции ПЛК (имхо я так понимаю - СВОБОДНО программируемый логический контроллер). Под словом СВОБОДНО я понимаю не столько неограниченные возможности сколько возможность оперативно программировать контроллер без знания внутренностей (тонкостей, нюансов аппаратной организации ПЛК), а обладая минимально необходимыми прикладными знаниями в области электрики и автоматики. Помощником в программировании является среда разработки прикладной программы. Данные программы появились на заре создания ПЛК, и реализовывались на программаторах под ДОС на текстовых терминалах в псевдографике типа I----II--N---<O1.1>-I что вполне читабельно и понятно любому электрику. Так появился первый МЭК-стандарт, он был простым и понятным.

Но прогресс не стоит на месте, и ПЛК начали насыщаться различными функциями. МЭК перестал удовлетворять требованиям прогресса и всё больше входил в противоречия с техническими возможностями ПЛК. Имхо в данный период МЭК является тормозом, и на него полагаться вредно, особенно в разделе обработки аналоговых сигналов. Так если реализовывать по МЭК интегратор то качественный регулятор вы никогда не получите!!! Почему? Всё очень просто, реальный интегратор должен обязательно иметь задаваемое ограничение сигнала по минимуму и максимуму, а МЭКом это не оговорено, а следовательно введение ограничения является отступлением от стандарта. Так в МЭК отсутствует блок зоны нечувствительности (неоднозначности), а без него реальный регулятор нормально функционировать не может! Выходит что по МЭК реализовать реальный регулятор невозможно!!! Вот такие неутешительные выводы.

Теперь о нас - в СССР пошли несколько иным путем. Ярчайшим примером являются разработки ЗЭиМ. Сначала в 80е годы был выпущен контроллер ДИМИКОНТ - дискретный логический контроллер, мало отличающийся от зарубежных аналогов, но потом был выпущен РЕМИКОНТ - РЕГУЛИРУЮЩИЙ ЛОГИЧЕСКИЙ микропроцессорный контроллер. Обратите внимание что регулирование (аналоговое, дискретное) первично, а логика вторична, т.е. логика добавлена как вспомогательная...
Совершенно иной подход к строению ПЛК. Данное устройство по тем временам было революционно и любимо наладчиками даже при всех его недостатках, а именно низкой надежности элементной базы, дубовый терминал (аж пальцы выгибались в другую сторону...), и внушительные размеры.

Вывод из всего выше изложенного - надо поменьше смотреть на МЭК, а больше уделять внимания на удобство и оперативность программирования (редактирования). Контроллеры должны быть надежными, безглючными, а ПО разработчика интуитивно понятным и удобным в использовании. Наиболее востребованными будут nano-PLC представляющие из себя смесь - LOGO!, ALPHA XL, Millenium3, РЕМИКОНТ Р-130. Если взять всё лучшее от каждого ПЛК и объединить в одном то получится прекрасная машинка.

ДЛЯ ЗАИНТЕРЕСОВАННЫХ, где взять соответствующее ПО:

LOGO! - http://www.automation.siemens.com/logo/htm...v5/install.html

ALPHA XL - http://www.mitsubishi-automation.ru/produc...WIN_content.htm

Millenium3 -
Фото - http://ip.ifolder.ru/4175601
ПО - http://ip.ifolder.ru/4175858
Допбиблиотеки - http://ip.ifolder.ru/4176199

РЕМИКОНТ Р-130
http://www.zeim.ru/ru/production/catalog/mpc/r130.php

Качайте, разбирайтесь, задавайте вопросы, обсуждайте. Таким образом можно будет совместно разработать КОНЦЕПЦИЮ nano-PLC с наилучшими потребительскими качествами...

В следующем посте опишу концепцию современного nano-PLC

Сообщение отредактировал АндрейХ - Dec 5 2007, 09:58

[anpilog]

Пиши ещё!
Так как тема действительно актуальна.
Особенно если учесть, что аппаратная часть не так сложна.
А наработки программных решений уже существуют.

По поводу "тормоза МЭК".
Так как использование ST дает возможность реализовать практически любой ФБ, то ни вижу особых проблем с тормознутостью стандарта.

[amusin]

Так как тема действительно актуальна.

Попробую поддержать.
На эту тему меня натолкнуло обсуждение http://electronix.ru:80/forum/index.php?showtopic=13407
Также по запросу "61131" на этом форуме много топиков.

Теперь результаты моих поисков.
1. Коммерческие среды программирования:

CoDeSys - http://www.codesys.ru/ 3S Software (royalty, 100 лицензий - по 110евро, 1000 - по 42, для 32-разрядных платформ, для 8/16 разрядных - в 2 раза меньше). Лучший саппорт в России и обилие информации. DevKit - 10кЕвро. Все без НДС.

Icon-L - http://www.pro-sign.de
Блестящая статья Александра Елисеева aly.projektas.lt/Projects/OpenPLC/VisualIDE.pdf
Нет поддержки языков МЭК 61131-3.

Straton - http://www.copalp.com/ Мало инфы

OpenPCS - www.infoteam.de (royalty-free на год) Мало инфы.

2. Полу-коммерческие.

ORF http://www.o-r-f.org/
Среда исполнения (runtime) бесплатна и open source , но среда программирования (Coryo) - за деньги, http://www.yellowstone-soft.de/engl/yscoryo.htm

3. Бесплатные (free, open source).

Beremiz - www.beremiz.org. Сырой проект. Нет коммьюнити.

Буквально сегодня был на выставке ПТА (Е-бург), общался с ребятами из Пролога, продвигающего CoDeSys в России. В т.ч. с Игорем Петровым. Вышеупомянутые цены - от них.
Уровень поддержки по среде программирования хороший. А вот для разработчика контроллеров до покупки девкита объем инфы очень урезан, и при применении out-of-list платформы нет четкой уверенности, что CoDeSys на ней "пойдет". Все же, после моих уверений, что я им не конкурент, они дали мне кое-какую информацию, но пока не было времени прочитать.
PS. В рамках выставки они организуют семинар по CoDeSys (завтра и послезавтра). Кто хочет - узнавайте подробности у них на стенде. Выставка, напоминаю, в КОСК "Россия".

Сообщение отредактировал amusin - Dec 5 2007, 11:35

[alexander55]

Все мы делаем контроллеры под себя. Но мало, кто хочет связываться с пользовательскими языками программирования. Этот вопрос станет, если нужно будет делать PLC на сторону.
Продолжайте, тема интересная.

[АндрейХ]

amusin anpiloq
Предлагаю сузить тему ПЛК до nano-PLC. Что хорошо для micro...mini-PLC то смерть для nano.
"Ключевой" стратегией развития nano-PLC должна стать формула - Plug and Play во всех отношениях, от подключения ПЛК до его программирования и обслуживания. Так сказать "Народный ПЛК по народным ценам".
Лозунг производителя и интегратора - "Дадим стране угля, мелкого но дофига".
ПыСы В свое время в "Митино" висел здоровый плакат -"Компьютер в каждую комнату", а тут нужен плакат "nano-PLC в каждый электрощиток"...

Ну это конечно шутки, а ежели серьезно то Миллениум3 почти отвечает требованиям "Народный" как по цене (даже зарубежной с ихней зарплатой и нашей растоможкой + дилерские %) так и по удобству работы с сим девайсом. Его можно взять за отправную точку, сделать аналог, а далее довести напильником (по нашенски) до истинно Народного изделия во всех смыслах, от дачников до пищевых комбинатов, ЖКХ и им подобных... (нефтевуху и газ не трогаем, а то загрызут). Идеальным будет результат когда будут довольны все - производитель, дилер (интегратор), и покупатель (заказчик).
Точек приложения сему девайсу немерено, повторюсь - от дачника до фермера, от новорашен до ЖКХ, деловых центров, складов, овощных баз, пищевых (перерабатывающих) комбинатов... т.е. там где требуется простой общепромышленный сертификат.
Далее обкатанный девайс можно портировать на более совершенные ЧИПы, например заменить ATmega128 на ADuC7128, и т.д. Имея опыт и наработки это делать будет проще.

Сообщение отредактировал АндрейХ - Dec 5 2007, 12:30

[anpilog]

amusin anpiloq
Предлагаю сузить тему ПЛК до nano-PLC. Что хорошо для micro...mini-PLC то смерть для nano.
"Ключевой" стратегией развития nano-PLC должна стать формула - Plug and Play во всех отношениях, от подключения ПЛК до его программирования и обслуживания. Так сказать "Народный ПЛК по народным ценам".
Лозунг производителя и интегратора - "Дадим стране угля, мелкого но дофига".
ПыСы В свое время в "Митино" висел здоровый плакат -"Компьютер в каждую комнату", а тут нужен плакат "nano-PLC в каждый электрощиток"...

Тогда получаем другую крайность 8(
Они станут ОЧЕНЬ специализированными... 8(

[alexander55]

Идея народного PLC - хорошая.
Только д.б. :
- народная цена
- простота для народа
- отсутствие ворованных средств разработки
- сертификаты всех для всех
- приличный рынок для сбыта.
Единственный момент вызывает недоумение: почему ADuC7128 (на мой взгляд, не удачный выбор).

[anpilog]

Единственный момент вызывает недоумение: почему ADuC7128 (на мой взгляд, не удачный выбор).

Флейм:
Хмм...
Мало срама
Нету MII
Дорого стоит

[oran-be]

Вывод из всего выше изложенного - надо поменьше смотреть на МЭК, а больше уделять внимания на удобство и оперативность программирования (редактирования). Контроллеры должны быть надежными, безглючными, а ПО разработчика интуитивно понятным и удобным в использовании. Наиболее востребованными будут nano-PLC представляющие из себя смесь - LOGO!, ALPHA XL, Millenium3, РЕМИКОНТ Р-130. Если взять всё лучшее от каждого ПЛК и объединить в одном то получится прекрасная машинка.

Сколько тока стоить будет такая машинка. Универсальность обходится очень дорого. Логический контроллер с большим трудом будет рещать задачу аналогового регулирования и наоборот. Пооэтому для реализации обоих задач одновременно при условии надежной работы контроллера необходимо иметь в одном контроллере два независимых ядра обработки, связанных между собой неким интерфейсом. МЭК описывает только логическую часть. Аналоговый модуль не вписывается в эту систему. Также и интерфейс пользователя. Последнее, кстати, - бич маленьких ПЛК. Система программирования экранов обычно весьма убогая и не поддерживает множество необходимых вещей для создания качественного интерфейса пользователя.
Мы решили проблему универсальности по другому - организацией распределенной многозадачной среды. То есть, логический контроллер обрабатывает логические сигналы, а аналоговый - аналоговые. Связываются между собой они по сетевому интерфейсу. Для описани алгоритмов пришлось сотворить опять же альтернативную систему описания, чем то похожую на МЭК, но имеющую некоторые фишки в ней отсутствующие, в частности, поддержку событий. И соответственно, систему описания пользовательского интерфейса.

[АндрейХ]

oran-be
Я же не с бухты-барахты открыл эту тему, правда тема плавно перетекла от конкретики к общему.
Зачем гадать на кофейной гуще. Всё уже пройдено в течении трех лет, и результаты положительные. И нормальные ПИД регуляторы получились, и многоуровневые меню, и даже в сеть включили несетевые АЛЬФы. Всё проверено несколькими сезонами эксплуатации, работают не хуже микро-ПЛК Разница в скорости работы для общепромышленных САУ не актуальна, для нано-ПЛК реакции вход/выход при полной загрузке 100мс вполне приемлемая. Ну а если будет 10мс на прогу в 300-500 FBD это совсем шоколадно, большего и не надо.
Есть только одно "узкое" место - вход счётчик импульсов и ШИМ выход. Используются они крайне редко и реализовывать их надо аппаратно, а не программно, тады проблем не будет.
Я выше дал ссылку на ПО nano-PLC. Достаточно скачать, установить и поиграться. У всех ПО есть вполне реальноработающий режим эмуляции. Конечно за один день сделать чёткое представление о достоинствах-недостатках сложно, но если надо будет я их могу перечислить поименно. Енто получится приличный реферат. Смысл его писать только под конкретного разработчика, а не просто так для души (был опыт, но канул в лету. Департамент АГ Сиеменса просил дать замечания по ЛОГО! пару лет тому назад. Приняли, поблагодарили и благополучно забыли... )

Привожу фотку использования нано-ПЛК. Это не простые приточные системы вентиляции, а с управлемой производительностью при помощи частотника и 5-ти ступенчатого 3-ф автотрансформатора. Работает без проблем (месяцами эксплуатация в венткамеру не ходит) три года, а ПЛК без всяких гальваноразвязок и не боится частотника (частотник без ВЧ фильтра по питанию)


alexander55
Я не разработчик - вам виднее какой ЧИП лучше.
Меня ADuC7128 привлек тем что флэш как у АТмеги 128 кб, ОЗУ больше - 8кб против 4, выигрыш по Mips и самое ценное до 12 АЦП 12 бит. Отпускная цена у АД 7 баксов от 1000 штук (разве это дорого?)

Сообщение отредактировал АндрейХ - Dec 5 2007, 16:01

[zltigo]

Отпускная цена у АД 7 баксов от 1000 штук (разве это дорого?)

К вопросу о выборе ядра. АRM-ы, например, LPC2138/48 c 512Flash и 32/40RAM 60MHz менее 7 баксов поштучно.
Пример использования: http://aly.projektas.lt/Projects/ADP_LPC2148/ADP_LPC.htm#3

[АндрейХ]

Возвращаясь к вопросу по нано-ПЛК Миллениум3
Всё-таки кто нибудь из спецов готов поюзать софт на предмет создания пользовательских FBD-блоков на DLLках?
Софт брать здесь:
Millenium3 -
Фото - http://ip.ifolder.ru/4175601
ПО - http://ip.ifolder.ru/4175858
Допбиблиотеки - http://ip.ifolder.ru/4176199

До кучи добавляю фотку двойного теплового пункта (четыре контура регулирования + подпитки) на нано-ПЛК ALPHA XL. Работает третий зимний сезон. Обслуга приходит гораздо реже чем когда стояли ПЛК Джонсон Контролз, торжественно выброшенные на помойку...


Сообщение отредактировал АндрейХ - Dec 5 2007, 17:39

[oran-be]

oran-be
Я же не с бухты-барахты открыл эту тему, правда тема плавно перетекла от конкретики к общему.
Зачем гадать на кофейной гуще. Всё уже пройдено в течении трех лет, и результаты положительные. И нормальные ПИД регуляторы получились, и многоуровневые меню, и даже в сеть включили несетевые АЛЬФы. Всё проверено несколькими сезонами эксплуатации, работают не хуже микро-ПЛК Разница в скорости работы для общепромышленных САУ не актуальна, для нано-ПЛК реакции вход/выход при полной загрузке 100мс вполне приемлемая. Ну а если будет 10мс на прогу в 300-500 FBD это совсем шоколадно, большего и не надо.

Привожу фотку использования нано-ПЛК. Это не простые приточные системы вентиляции, а с управлемой производительностью при помощи частотника и 5-ти ступенчатого 3-ф автотрансформатора. Работает без проблем (месяцами эксплуатация в венткамеру не ходит) три года, а ПЛК без всяких гальваноразвязок и не боится частотника (частотник без ВЧ фильтра по питанию)

Ваще то ядро у наших ПЛК работает с циклом 1 мСек, входы -соответственно 0.5 мсек. Тогда они работают хорошо везде. В машинах 10 мСек много.
А фотка - это к чему? У нас подобные шкафы-красавцы иногда по нескольку штук в неделю со стапелей сходят. Только я не понял - ПЛК, что щитовой? или это ОпПанель торчит? Или как то присобачили реечный ПЛК На переднюю панеь?

[АндрейХ]

oran-be
Фотки для того чтобы показать как могут использоваться нано-ПЛК, типа наглядной агитации.
ПЛК на фотографиях - обычный DIN-реечный моноблок ALPHA XL по 180 евриков.
По поводу быстродействия - ежели вам 10 мсек. медленно то вы видать на своих ПЛК летаете. А мне 10 мсек в самый раз. Быстрее нет смысла, всё равно конечные устройства - реле с пускателями быстрее хлопать не будут. Даже 100 мсек не напрягает, в итоге все зависит не от быстроты, а от умения.

"У нас подобные шкафы-красавцы иногда по нескольку штук в неделю со стапелей сходят" ГЫ... и чё, сразу в море?

Сообщение отредактировал АндрейХ - Dec 5 2007, 20:32

[sensor_ua]

Не знаю, nano или как, но вот собрался сделать одну поделку и нашёл аж за 100 баксов с НДС в розницу модель AF-10M R-D (индикатор ещё 20 баксов) http://www.promsat.com/page/1502/ - софт фри - LD и FBD. А насчёт сделать свой вариант FBD - не понимаю при чём тут dll. Вопрос, ИМХО, должен ставиться по-другому - в контроллере виртуальная машина (интерпретатор) и программа на компе фактически транслятор схемы в параметры конфигурации, или программа контроллера предкомпилируется на компе. Если первое, то это не придумывать, а делать или не делать надо потому как спецификации на функциональные блоки (равно кусочки ладдера) есть, количество параметров и их названия для блоков определены, остаётся только виртуальная машина, принимающая конфиг. Я не говорю, что это очень просто, но думаю, что вполне решаемо. Вот сделаю свою поделку и попробую в какой-нибудь из своих контроллеров чего-нить такого положить. Кстати, ладдер бесплатный (но лицензию надо смотреть) на AVR и PIC какой-никакой есть http://www.cq.cx/ladder.pl. Я его софт даже как-то русифицировать пытался (получалось, но не закончил)

[АндрейХ]

sensor_ua
Знакомо сие чудо... Это не нано-ПЛК, а простое Программируемое реле, типа китайский LOGO! первого поколения, по этому и цена такая.
На данном девайсе нормальный ПИ-ПИД регулятор никогда не сделаете в отличии от КРУЗЕТовоского нано-ПЛК Миллениум3.

[sensor_ua]

нормальный ПИ-ПИД регулятор никогда не сделаете

Мне не для того это нужно. Если бы у них был функциональный блок ПИ или ПИД-регулятора, то, думаю, что сделал бы

[AlexG_changed]

Буквально сегодня был на выставке ПТА (Е-бург), общался с ребятами из Пролога, продвигающего CoDeSys в России.

Был на ПТА примерно в тоже время. То-то ребята из Пролога на стенде с CoDeSys возмущались что у них конфиденциальную инфу выспрашивают

[AlexG_changed]

Скачал я Крузетовский софт... сдается мне что файлы *.bm3 это бинарники прошивок контроллеров и дополнительных функций. Причем дополнительные функции тоже используют систему команд AVR, а не какую-нибудь виртуальную машину. У Шнайдера аналогично - *.bz2 - прошивки для Zelio Logic. Внутри они устроены немного иначе, но можно попробовать перепрошить Millenium 3 в Zelio Logic или наоборот
DLL похоже устроены довольно просто: три функции, одна из которых явно отвечает за симуляцию и bmp-иконка.

[АндрейХ]

AlexG
Скачал я Крузетовский софт... сдается мне что файлы *.bm3 это бинарники прошивок контроллеров и дополнительных функций. Причем дополнительные функции тоже используют систему команд AVR, а не какую-нибудь виртуальную машину....
DLL похоже устроены довольно просто: три функции, одна из которых явно отвечает за симуляцию и bmp-иконка.
А выводы какие? Есть возможность сваять свои FBD-блоки? Есть возможность интсрументик для создания пользовательских блоков сварганить, или если проще то сделать 5 дополнительных FBD? Этого будет более чем достаточно для полного счастья хотя-бы на год, а за это время появится что нибудь более продвинутое


Всем, всем, всем.... Есчо раз повторюсь, просьба не давать умных советов типа "выбрось КРУЗЕТ и возьми чё нить типа S7-200". STEP7, CoDeSys, IsaGraf очень хорошие инструменты, НО они расчитаны на microPLC и круче. Данные системы ИЗБЫТОЧНЫ для SAS (Системы Малой Автоматизации)

[sensor_ua]

Есть возможность сваять свои FBD-блоки? Есть возможность интсрументик для создания пользовательских блоков сварганить, или если проще то сделать 5 дополнительных FBD?

Вы бы разделили вопросы на есть ли возможность поломать (декомпилировать) чужое плюс добавить своей функциональности и насколько сложно создать своё всё. Для меня нарисовать сам функциональный блок - вопрос техники, но поднимать систему со всей красотой и рюшечками - это коллективный и/или небесплатный труд. Продукт должен либо иметь совсем свою нишу (утопия) либо с чем-то конкурировать. А тут сразу начинается бизнес. Вы бы всё-таки конкретизировали предложения (как понял, ломавших указанные в топе контроллеры/систему не находится).

[АндрейХ]

sensor_ua
Естественно меня интересует только "доработка" существующего ПО - добавление нескольких FBD к тому что имеется.
Разработчики ПЛК пусть ужо решают для себя сами чё им надо. Естественно что им потребуется сваять свое ПО, чтобы не было потом проблем,
а ПО КРУЗЕТ пригодится как образец для подражания...

Сообщение отредактировал АндрейХ - Dec 6 2007, 22:59

[amusin]

Был на ПТА примерно в тоже время. То-то ребята из Пролога на стенде с CoDeSys возмущались что у них конфиденциальную инфу выспрашивают

Забавно. Когда я повторно подошел к ним, чтобы скинуть подготовленную ими инфу на флешку, Петров сказал, что это они "сгоряча" и, мол, все это недоразумение, дал свою визитку. Да еще раньше книжку подарил!
Они пояснили, какую именно конфиденциальную информацию я хотел получить? Только не надо про исходники, я говорил про хидеры платформенно зависимой части, которую надо написать МНЕ.
Меня интересовали:
- требования к ПЗУ и ОЗУ для платформы на ARM7,
- объем и содержание работы по адаптации системы исполнения,
- возможность загружать МЭК-программы по своему протоколу.
Аргументированного ответа на первую часть я от них не получил, причем они копались для ответа в доках, которые отказались предоставить.
ARM7 от ARM9 они не отличали, к сожалению. На вторую часть вопроса ответили общими фразами, типа за 2 дня управитесь. На третий сказали - да, но тоже без аргументов.

В итоге в выцыганенном файле Test adaptation... только краткое описание, как "завести" plc и связать со средой программирования, а также ссылки на доки, в которых они и копались.

Понятно, что они боятся предоставить инфу, которая может помочь их конкурентам. Но, на мой взгляд, они переборщили с закрытостью и не дают достаточно инфы для принятия решения в пользу CoDeSys.
Не смешно было бы потратить 10кЕвро + лицензии, чтобы убедиться, что runtime просто не влезет в мою контроллер и надо ставить внешнее ОЗУ, а может даже переходить на более "жирную" платформу!

Сообщение отредактировал amusin - Dec 7 2007, 05:14

[AlexG_changed]

amusin
Вопрос серьезный и интересный. Странно что они не смогли ничего внятного сказать. Возможно дело в том что они продвигают Beck IPC и не привыкли задумываться о выборе платформы
Мне их расспрашивать было не о чем, делать собственный ПЛК мы пока не планируем.

АндрейХ
Вы не пробовали связаться с Крузет и узнать, сколько будет стоить разработка нужных блоков для вас? У них вроде бы есть такая услуга.

Я посмотрю еще в свободное время как оно устроено, но ничего обещать не могу, взлом и реверсинжиниринг не моя специализация.

[amusin]

amusin
Вопрос серьезный и интересный. Странно что они не смогли ничего внятного сказать. Возможно дело в том что они продвигают Beck IPC и не привыкли задумываться о выборе платформы
Мне их расспрашивать было не о чем, делать собственный ПЛК мы пока не планируем.

Они толковые ребята. Я разговаривал с Пастушенковым Дмитрием, который лично адаптировал CoDeSys на ПЛК на базе C16x. То, что они делают, они делают хорошо.
В итоге про возможность адаптации на ARM7 мне рассказал инженер службы поддержки другой фирмы-экспонента в частном разговоре. Правда, у них в ПЛК ОЗУ больше 1М, так что на вопрос по мин. требованиям и он не смог ответить.

[AlexG_changed]

про возможность адаптации на ARM7 мне рассказал инженер службы поддержки другой фирмы-экспонента

А что за фирма, если не секрет? Интересно взглянуть на их ПЛК.

[amusin]

А что за фирма, если не секрет? Интересно взглянуть на их ПЛК.

К сожалению, я не уверен, что не подставлю его.

[АндрейХ]

AlexG
Сам лично с КРУЗЕТ не связывался, а вот через Питерских дилеров вопросы задавать приходилось. Отвечают вяло, долго (на вопрос по полмесяца уходило), и весьма раплывчато. На Руси данная фирма представлена очень скупо, в Москве один продавец, и в Питере дилер. Всё...
По этому делаю вывод что быстрее самому дойти до изготовления FBD, чем их просить.
Как пример - Митсубисши после настоятельных просьб руссифицировал дисплей АЛЬФы через ТРИ ГОДА, и то наверно потому что открыло представительсто Митсубисши электрик в Москве...

[АндрейХ]

Все таки может кто нибудь из знатоков подскажет как можно адаптировать блоки библиотеки под свои нужды.
Предполагаю делать так - выбираю наиболее схожий ФБД-блок и с помощью соответствующих интструментов, например PE explorer и IDA потрошу файлы подобного блока, с минимальными изменениями заставляю его делать то что мне необходимо.
Насколько это возможно? И как это сделать?
Как имхо понимаю библиотечный блок состоит из 3 файлов - *.dll, *.ini, *.bm3. Как они связаны, и что в них надо изменять для получения новых свойств библиотечного блока?
Конечно лучше это сделать спецу, но как вижу желающих нет... А мне нужно для щастья изменить минимум 3 а максимум 5 блоков для реализации ПИД регулятора - остальное в Миллениум3 полностью отвечает моим требованиям. Конечно было-бы совсем шоколадно внедрить кириллицу, но это более проблематично...

Сообщение отредактировал АндрейХ - Dec 8 2007, 20:21

[anpilog]

Все таки может кто нибудь из знатоков подскажет как можно адаптировать блоки библиотеки под свои нужды.
Предполагаю делать так - выбираю наиболее схожий ФБД-блок и с помощью соответствующих интструментов, например PE explorer и IDA потрошу файлы подобного блока, с минимальными изменениями заставляю его делать то что мне необходимо.
Насколько это возможно? И как это сделать?
Как имхо понимаю библиотечный блок состоит из 3 файлов - *.dll, *.ini, *.bm3. Как они связаны, и что в них надо изменять для получения новых свойств библиотечного блока?
Конечно лучше это сделать спецу, но как вижу желающих нет... А мне нужно для щастья изменить минимум 3 а максимум 5 блоков для реализации ПИД регулятора - остальное в Миллениум3 полностью отвечает моим требованиям. Конечно было-бы совсем шоколадно внедрить кириллицу, но это более проблематично...

Проще и, наверное, дешевле уболтать производителя, чем подрядить народ на реверс инжиниринг.
Хотя все это ИМХО.

Предложите КРОУЗЕТу свою помощь.
Может быть они дадут соответствующие средства или хотябы документацию на такие операции.
Вот с этим уже можно будет работать.

Чисто теоретически могу представить как изменить поведение какого-то уже существующего ФБД, а вот как, например добавить вход/выход - уже с трудом 8(

[SasaVitebsk]

Насколько это возможно? И как это сделать?
Как имхо понимаю библиотечный блок состоит из 3 файлов - *.dll, *.ini, *.bm3. Как они связаны, и что в них надо изменять для получения новых свойств библиотечного блока?
Конечно лучше это сделать спецу, но как вижу желающих нет...

Спец, скорее всего не возьмётся за такую работу. Причина проста, - даже в чужих исходниках разобраться - и то мало приятного, а в оттранслированных библиотеках, - вообще работа посложнее чем забахать это всё с нуля. То есть сделать можно всё, но стоимость такой работы будет дороже чем обратится к самому разработчику.

С другой стороны anpilog говорит дело. Можно попробовать обратится к разработчикам, за протоколами нижнего уровня. И необходимое дописать самому. Хотя, судя по описанию, сделать это - тоже не дорогу перейти. Я например обращался на тот же Овен и они мне присылали свои протоколы и методы расчёта CRC. Понятно, что это не одно и тоже, но тем не менее возможны варианты.

[АндрейХ]

anpilog SasaVitebsk
Вот в том-то и проблема что обращение к разработчикам - крик в пустой колодец...
Имел в свое время контакты с зарубежными производителями ПЛК... Это вам не с ОВЕНом контачить.
Задолбаетесь доказывать что не верблюд... Первый ответный вопрос - на сколько вырастет процент продаж... ну и т.д., а что блоки нужны для ПИД им по барабану... либо плати бабло, либо доказывай что енто для них щастье... а енто сложно, у нас разный менталитет, и взгляды на автоматику иные...

[AlexG_changed]

SasaVitebsk
Тут просто нужен специалист в области реверсинжиниринга и исследования чужих программ.

Некоторые файлы *.bm3 с дополнительными функциями довольно короткие, и я думаю что те, кто программируют AVR на ассемблере, смогут в них разобраться.

[anpilog]

Интересно насколько будут отличаться суммы для доработки от производителя и реверс инжиниринга? 8)))

Что-то мне подсказывает, что не очень 8)

[АндрейХ]

anpilog
Интересно насколько будут отличаться суммы для доработки от производителя и реверс инжиниринга?
Я расчитываю на другой подход - взаимозаинтересованность, т.е. на спеца, которого интересует подобное ПО, и ему по любому надо делать "реверс" для того что-бы понять как работает прога. А я со своей стороны готов дать подробные данные что нужно изменить с точки зрения интегратора (что добавить, что убрать, а что изменить, с подробным описанием ФБД-блоков) на основании имеющегося 3-х летнего опыта использования нано-ПЛК. Т.е. расчитываю на взаимную заинтересованность.
Надеюсь что найдутся заинтересованные лица, желающие выпускать подобный нано-ПЛК, и возможно даже с лучшими характеристиками. Так желательно иметь нано-ПЛК с 12-ти битным АЦП и с временем цикла работы 2х5мс. при полной загрузке не менее 300 ФБД и полным набором вх./вых. порядка 60 с учетом модулей расширения. Ну и конечно дисплей 16х4 с кириллицей.

Сообщение отредактировал АндрейХ - Dec 9 2007, 14:01

[SasaVitebsk]

SasaVitebsk
Тут просто нужен специалист в области реверсинжиниринга и исследования чужих программ.

Некоторые файлы *.bm3 с дополнительными функциями довольно короткие, и я думаю что те, кто программируют AVR на ассемблере, смогут в них разобраться.

Честно говоря, не владею данным вопросом. Но если бы я делал такое изделие, то совершенно не понимаю причём здесь проги на AVR?

Мой бы подход был следующим (с точки зрения AVR)
1) Я бы реализовал интерпретатор элементарный и описал бы хранение/передачу параметров.
2) Реализовал бы необходимые интерфейсы связи.
3) Я реализовал бы максимально возможное число вылизанных функций разного уровня. Вплоть до самых низкоуровневых. Чем забил бы флэш до предела.

Таким образом программа на PC выглядела бы как алгоритм составленный из этих функций и хранилась бы в ОЗУ либо подгружалось любым из предусмотренных способов. Наличие низкоуровневых блоков позволяло бы в принципе создавать более высокоуровневые на PC, которые на самом деле расспадаются на более мелкие. Но всё это никаким образом к самому процессу программирования AVR либо другого процессора не имеет. Наоборот это позволяет использовать общее ПО на PC для ПЛК разработанных на разных процессорах и имеющих разные возможности. Например время реакции, колличество входов/выходов, объём ОЗУ (что определяет максимальный размер проги/данных) и т.д.

Таким образом, если бы вы исследовали моё изделие, то Вы бы ничего там не дизасемблировали. Для того чтобы разобраться в этих блоках, надо было бы знать набор микрокоманд/микроблоков и структуру хранения/передачи данных.

Насколько я понимаю, именно это и описано одним из стандартов IEC 61131–3. Хотя я могу и серьёзно заблуждаться. Я с этим не имел дела и, пока, к сожалению, времени на изучение совершенно нет. Мне бы довести до конца то, что я уже задумал и начал.

[АндрейХ]

SasaVitebsk
Описываемый вами подход естесно не нов, например он реализован в ЯВУ ФОРТ. В Форте можно даже на ассемблере вставки писать и тут-же проверять без всякой нуторной компиляции, линковки и чёрт знает чего (на древних машинах даже простенькая программа убивала уйму времени). Эх... это было давным давно, в прошлом тысячелетии, когда машины были большие, а память маленькая...

По поводу КРУЗЕТа я и хотел узнать у спецов насколько возможно создавать свои ФБД блоки именно низкоуровневые на уровне ассемблера, потому как нужные мне макроблоки я давно сбацал, но они выходят весьма избыточными по коду (приходится извращаться что-бы сделать НЧ-фильтр и уж тем более интегратор), а хочется покомпактнее что-бы попусту не тратились и так ограниченные ресурсы...

[SasaVitebsk]

SasaVitebsk
Описываемый вами подход естесно не нов, например он реализован в ЯВУ ФОРТ. В Форте можно даже на ассемблере вставки писать и тут-же проверять без всякой нуторной компиляции, линковки и чёрт знает чего (на древних машинах даже простенькая программа убивала уйму времени). Эх... это было давным давно, в прошлом тысячелетии, когда машины были большие, а память маленькая...

По поводу КРУЗЕТа я и хотел узнать у спецов насколько возможно создавать свои ФБД блоки именно низкоуровневые на уровне ассемблера, потому как нужные мне макроблоки я давно сбацал, но они выходят весьма избыточными по коду (приходится извращаться что-бы сделать НЧ-фильтр и уж тем более интегратор), а хочется покомпактнее что-бы попусту не тратились и так ограниченные ресурсы...

Вот я ставлю себя на место разработчиков и отвечу Вам просто. Я бы такие возможности не закладывал.
Поясню почему.
1) Вы плохо себе представляете ассемблер. Там, абсолютные адреса. Таким образом созданный Вами блок надо расположить в конце (к примеру) уже готового ПО (Вы же просто хотите дополнить) при этом необходимо перекомпилировать его на конкретный адрес. А если таких блока вы два добавили?
2) Надо отслеживать исполнения. Так как конечный адрес может находится в произвольном месте.
3) Необходимо предусмотреть переход на ваши блоки или их вызов из основной программы, при этом не зная их адреса на момент написания.

Безусловно написать можно всё, но, я думаю, что это излишне сложный, и главное совершенно избыточный путь. Я уверен, что пошли моим путём. При чём здесь FORTH? Форт - универсальный язык использующий синтаксис. Здесь это не надо. Здесь уже готовый оттранслированный язык.

Например принимаю что операция состоит из 4 байтов. где 2 байта код комманды 2 байта адрес параметров. Например команда вывода в порт 0001. При этом значение порта (например 1) это не самостоятельное значение порта (к примеру PORTA для AVR), а это порт отмеченный на вых. разъёме как порт 1 (на самом деле это может быть PORTD). Такая реализация скрывает от Вас внутреннее устройство самого изделия. Вам ведь и не гарантируется, что следующее закупленное изделие будет тоже на базе atmega128. Вам гарантируется, что Ваша прога будет работать ИДЕНТИЧНО. Естественно Вам самим не надо набирать 00010001 Это от Вас скрыто. Кстати при такой реализации возможный объём свободного места под программы будет больше, чем при прямой реализации.

С другой стороны, при правильном написании, эффективность будет не хуже чем в 10 раз. Таким образом, выбранное Вами время отклика 100мс соответствует 1.6 млн операций, что будет примерно соответствовать 160 000 микроопераций. Естественно чем крупнее блоки, тем короче прога, но медленнее исполнение. Поэтому я и пушу, что я бы забил всю имеющуюся память блоками разного уровня абстракции. Чтобы найболее часто используемые блоки можно было бы сразу применить, а уникальные - самому сваять из низкоуровневых.

В принципе здесь где-то отвечал разработчик (насколько я понял) таких изделий. Можно подробности у него спросить.

[AlexG_changed]

Вот я ставлю себя на место разработчиков и отвечу Вам просто. Я бы такие возможности не закладывал.
Поясню почему.
1) Вы плохо себе представляете ассемблер. Там, абсолютные адреса. Таким образом созданный Вами блок надо расположить в конце (к примеру) уже готового ПО (Вы же просто хотите дополнить) при этом необходимо перекомпилировать его на конкретный адрес. А если таких блока вы два добавили?
2) Надо отслеживать исполнения. Так как конечный адрес может находится в произвольном месте.
3) Необходимо предусмотреть переход на ваши блоки или их вызов из основной программы, при этом не зная их адреса на момент написания.

Тем не менее, такие возможности в Millenium 3 заложены. Я не знаю как, но разработчики решили эти проблемы.

Можете посмотреть сами, вот одна из дополнительных функций и одна из прошивок контроллера:
 func.zip ( 13.9 килобайт ) Кол-во скачиваний: 173
 firmware.zip ( 27.01 килобайт ) Кол-во скачиваний: 185


Сообщение отредактировал AlexG - Dec 10 2007, 02:09

[khach]

Если это полная незашифрованная прошивка- то ИдаПро вам в руки. Где-то за неделю ручной работы прошивка с нуля разбирается на удобочитаемые блоки. Тем более, что все разбирать ненедо- достаточно разобраться только с интерфейсом плугинов и механизмом их загрузки. Потом на основанни этого делаете несколько h файлов ( с адресами интерфейсных функций, структурами данных) и линкуете их к пректам своих плугинов. Портите один PLC- запаиваете в него Атмегу с незакрытой отладкой, грузите туда свое творение и проверяете с отладчиком.

[AlexG_changed]

Работы будет несколько больше, каждый плагин имееют еще и PC-шную часть.
Мегу перепаивать скорей всего не придется, надо вывести JTAG и разъем программирования, если его нет.
С JTAGом изучение прошивки должно вообще весело пойти.

[mse]

Вот я ставлю себя на место разработчиков и отвечу Вам просто. Я бы такие возможности не закладывал.
Поясню почему.
1) Вы плохо себе представляете ассемблер
...

Это как раз совсем не проблема. ;О) Оформляйте ваши блоки как подпрограммы и располагайте где угодно.
Ну и вызывайте сколько угодно раз, ессно.

[АндрейХ]

Господа, а зачем гадать на кофейной гуще
Скачиваете ПО, которое я вам дал, запускаете, "рисуете" простейшую прогу и запускаете в режиме эмуляции. Не знаю как организован эмулятор, с помощью вертуального ПЛК, или иначе, но эмуляция очень схожа с работой оригинала, т.е. ПЛК.
Вообще лучше один раз увидеть чем сто раз гадать. Прога всё контролирует. Для контроля памяти в меню есть шкала прогресса, и при добавлении нового библиотечного ФБД происходит постепенное заполнение, причем на один экземпляр ФБД, а потом сколько на рабочее поле кидай копий данного ФБД шкала не меняется. Есть таблица использованной памяти, и расчет времени исполнения. При загрузке в контроллер производится перекомпиляция прошивки и выдается таблица с перечнем добавленных ФБД. Это очень удобно. Т.е. библиотека состоит из двух частей - минимальной библиотеки ФБД, и библиотеки расширений. Причем из библиотеки расширений будут компилироваться только те ФБД, которые вы добавили в проект, что дает возможность оптимизации проекта за счет использования по возможности однотипных ФБД блоков.
Хоть я и не разбираюсь в программировании, но данный подход к реализации ПО для малых промышленных ПЛК самый удачный.
Из недостатков Миллениум3 вижу три - есть ряд ненужных ФБД в основной библиотеке, которые я бы заменил на 5 нужных, нет поддержки кириллицы в дисплее, и желательно иметь хотя-бы простенький менеджер меню дисплея по подобию АЛЬФовского. Такого ПЛК точно хватило бы на 2...3 года до появления более продвинутых систем за те-же деньги.

[SasaVitebsk]

Тогда всё понятно. Просто стоит bootloader, а сама система, по сути, представляет собой законченную систему программирования с набором библиотек и своим высокоуровневым языком для упрощения программирования.

В таком случае из этого проистекает следующее:
Наверняка есть стандартные программные средства для создания собственных FBD. Возможно они не входят в базовую версию поставки, но СТОПРОЦЕНТНО существуют.

[khach]

Господа, а зачем гадать на кофейной гуще
Скачиваете ПО, которое я вам дал, запускаете, "рисуете" простейшую прогу и запускаете в режиме эмуляции. Не знаю как организован эмулятор, с помощью вертуального ПЛК, или иначе, но эмуляция очень схожа с работой оригинала, т.е. ПЛК.

Ну тут же телепатов нет.. есть только реверсеры. Раз там эмулятор встроен- скачаем 80 мег, посмотрим. Вот только главное, чтобы эмулятор не функциональный был, а именно витруальная машина.
По поводу JTAG- ну надо быть совсем тупым, чтобы продавать устройство с незалоченным интерфейсом отладки. Часто бутлоадер с залоченной Атмеги вычитать вообще неудается, и приходиться писать свой, функционально аналогичный.
А вы пожалуста сделайте расписку выводов Атмеги- какой порт к какой группе выходов PLC подключен, ну и типовые схемы обвязки тоже желательны. Частота кварца какая?

[AlexG_changed]

Ну тут же телепатов нет.. есть только реверсеры. Раз там эмулятор встроен- скачаем 80 мег, посмотрим. Вот только главное, чтобы эмулятор не функциональный был, а именно витруальная машина.
По поводу JTAG- ну надо быть совсем тупым, чтобы продавать устройство с незалоченным интерфейсом отладки.

1. Предупреждаю, скорость скачивания очень низкая. У меня получилось докачать только с третьей попытки
2. Судя по всему эмулятор именно функциональный, в режиме эмуляции используется dll, а не код для АТмеги. (надо будет проверить, это просто)
3. Залоченный или незалоченный интерфейс не имеет значения когда прошивка лежит в открытом виде, можно самостоятельно все что угодно разлочить. Другое дело что JTAG на платах часто не разведен.

Сообщение отредактировал AlexG - Dec 10 2007, 12:57

[АндрейХ]

khach
Один из трех файлов, которые я выкладывал - фотки внешнего вида контроллера и его потрохов. Если фотки неудачные, напишите что надо снять, я сфоткаю и файлы выложу.

Вааще-то Миллениум3 игрушка интересная и при правильной раскрутке аналога может органично вписаться в средства автоматизации. Самое главное - надежный ПЛК + модули расширения, + локальная сеть (например MODBUS) и возможность цеплять GSM-модемы (всё это есть у Миллениум3), удобное ПО, и хорошо прописанная документация для чайников (по подобию того как пишет Сиеменс)... (вот с ентим у Миллениум3 напряжопка)...

[AlexG_changed]

АндрейХ
Кстати, вы смотрели на контроллеры фирмы Сегнетикс? В некоторых моментах они оставляют Millenium 3 позади, правда среда разработки по удобству оставляет желать много лучшего .

[АндрейХ]

AlexG
Сегнетикс? Смотрел, не устраивает. Я перебрал все нано-ПЛК, которые можно найти у нас. Вывод - по соотношению цена/возможности Миллениум3 отвечает полностью требованиям автоматизации технологических процессов. Остальные контроллеры либо выходят дороже (например EASY-800 Мюллера), либо функционально не способны отвечать требованиям САУ (либо малая разрядность АЦП, либо недостаточно аналоговых входов и отсутствие необходимых ФБД блоков для обработки аналоговых сигналов). В основном ограничения связаны с аналоговыми измерениями и регулированием.

[Denisvak]

АндрейХ
Кстати, вы смотрели на контроллеры фирмы Сегнетикс? В некоторых моментах они оставляют Millenium 3 позади, правда среда разработки по удобству оставляет желать много лучшего .

Я использую сейчас как раз их железо. Пишу под него на Си. Мне проще так написать на си чем разбиратся в том что там намудрили , да и быстродействие выше, и сделаю чего захочу...завишу тока от железа, но увы железо тоже не ах!!!

[AlexG_changed]

Я использую сейчас как раз их железо. Пишу под него на Си. Мне проще так написать на си чем разбиратся в том что там намудрили , да и быстродействие выше, и сделаю чего захочу...завишу тока от железа, но увы железо тоже не ах!!!

Гм, а что вас не устраивает в железе?
Тоже есть наработки на C под SMH2010, но при каждом изменении программ приходится тратить время на отладку. А менять их приходится почти каждый раз из-за изменения требований и состава оборудования. В результате выгода от использования приличной системы программирования на МЭК-языках стала очевидной, только где ж ее взять? Экспериментировал с Zelio Logic (немного урезанный Millenium3) на симуляторе и не смог даже близко приблизиться к функциональности наших сишных программ - мало памяти.

АндрейХ
А как у Millenium3 со сроками поставки? Кто-нибудь теперь их держит на складе?

Сообщение отредактировал AlexG - Dec 10 2007, 19:55

[АндрейХ]

AlexG
В SMH2010 много всего разного, интересного и в основном ненужного для КИПиА (видно не спецы в автоматике его творили). Например в нем есть функции sin, cos, tg, всякие логарифмы, которые не используются в автоматике, или крайне редко например экспонента, а интегратора, дифференциатора, ограничителей сигналов, зоны нечувствительности, НЧ фильтров, модуля ФИМ нет, и следовательно САР реализовать невозможно. Zelio Logic - это весьма заметно урезанный Millenium3, поэтому Зелио был сразу исключен, хотя в Москве есть дистрибьютер - компания RS.
К сожалению Миллениум3 в Москве продает только РТД-Универсал. Но возможно что его скоро можно будет приобретать у дистрибьютеров Шнейдер Электрик так как КРУЗЕТ вслед за Телемеханику влился (или его туды засосало) в Шнейдер...
А вааще если рассматривать САР (системы автоматического регулирования) то образцом для подражания является библиотека РЕМИКОНТ 130. Она была отточена десятилетиями опыта разработки регуляторов (в том числе и микропроцессорных) и обкатана на серьезных объектах. Первоначальное назначение сего девайса было - Металлургия, в частности плавильные печи.
А логика и смешанные блоки, такие как компораторы, и т.д. можно взять по стандарту МЭК, и не парится.
Вот и получится прекрасный ПРиЛК - программируемый регулирующий и логический контроллер. Почему так? Просто на любом объекте всегда найдется что регулировать и чем управлять...

Denisvak
Это конечно замечательно что вы знаете и пишите на Си.
Первый раз мне довелось программировать Симатик S5-115 в 1984г. на LD, потом перешел на FBD. Это действительно "реальные" инженерные языки программирования - "что вижу, то пою". Программируешь как паяльником водишь, полностью реально визуально. Чем замечательно, можешь с любого конца начинать, не заморачиваться всякими правилами, и т.д. Грамотный язык программирования должен создавать псевдопараллелизм (его нет в Сигнетиках, зато есть в простом Миллениум3), как если бы вы делали схему в железе - на релюхах или микросхемах.
Все языки ЯВУ, в том числе Си имхо абстрактные, виртуальные... и есчо куча всяких правил, и т.д.
Находясь на объекте править прогу на коленке можно находясь в реалии, а не в абстракции...
Как говорится каждому своё, но факт остается фактом - первый инженерный язык LD появился одновременно с промышленным контроллером. ГЫ, встречал такие убогие контроллеры, которые программировались не то что-бы на ассемблере, а вааще в бинарниках...

[AlexG_changed]

Denisvak
Все языки ЯВУ, в том числе Си имхо абстрактные, виртуальные... и есчо куча всяких правил, и т.д.
Находясь на объекте править прогу на коленке можно находясь в реалии, а не в абстракции...

Если изменения не слишком серьезные, программа на Си при необходимости вполне нормально правится на объекте - проверено.

А как вы к ST относитесь? У меня как-то была программа, в которой использовались одновременно FBD, LD, SFC и ST - разные задачи в пределах одного контроллера оказалось удобнее решить на разных языках.

Сообщение отредактировал AlexG - Dec 11 2007, 02:00

[Denisvak]

AlexG

Denisvak
Это конечно замечательно что вы знаете и пишите на Си.
Первый раз мне довелось программировать Симатик S5-115 в 1984г. на LD, потом перешел на FBD.

Я конечно не хочу спорить, но например Си я освоил за две недельки сидя вечерами, А когда столкнулся первый раз с Сегнетиксом у меня ушло не меньше времени чтобы разобраться как его програмить. Если правильно писать на Си, составить шаблоны то как мне кажется это будет не сложнее чем все эти ""реальные" инженерные языки программирования - "что вижу, то пою"" Даже графическую оболочку под это можно написать. Зато по гибкости и быстродействию вы будите далеко впереди от всех...
ИМХО

Вы бы лучше составили и написали тут список и описание всего того чего бы хотелось Вам иметь в ПЛК. авось производители прислушаются...

[АндрейХ]

Denisvak
Я конечно не хочу спорить, но например Си я освоил за две недельки сидя вечерами, А когда столкнулся первый раз с Сегнетиксом у меня ушло не меньше времени чтобы разобраться как его програмить.
Возможно вы не КИПовец, или проги у вас несколько иные, например всякие интерфейсы однозначно удобнее писать на СИ, или создавать блоки ФБД...
У меня и у многих спецов по КИПиА, да и у электриков всё с точностью до наоборот. Возможно сказывается менталитет, привычка работать с "физикой", а не с "лирикой". В начале 90-х попался мне древний ОМРОН (вроде С-20), который загружался с кассетного магнитофона. Прога к нему писалась на терминальном устройстве в IL (типа ассемблера). Дык для того шоб понять работу логики всей программы а не отдельных кусков я в тетрадке переводил с IL в LD, вносил изменения и переводил обратно в IL...
Чем отличается текстовой язык от графического - это как рассматривать картину или читать её описание. Разница в том что при визуальном программировании мозг работает методом дедукции - от общего вида схемы к конкретному куску схемы, а в текстовых прогах методом индукции - от конкретной строки к пониманию всего текста, т.е. что-бы понять кусок программы нужно просмотреть всю прогу, даже если она у вас хорошо структурирована и прекрасно закомментирована.

[АндрейХ]

Что-то тема подзаглохла
Или народ подзадумался об чём?
Вот тут можно скачать демо-версию ПО Миллениум3 - http://www.crouzet.com/millenium3/html/en/...ct-logiciel.htm
Пишете в формах всякую ерунду и скачиваете прогу, весит 15 метров. Полностью рабочая кроме связи с ПЛК.
Тут на ebay ПЛК выставлен по смешным новогодним ценам - http://cgi.ebay.fr/Crouzet-Millenium3-CD20...2QQcmdZViewItem
и даже с Российскими накрутками цена получается очень вкусная (главное что-бы дилеры палку не перегибали).
Хочу взять дополнительно модуль MODBUS и скрестить с терминалом ИП320. Получается офигенно выгодная система диспетчеризации с распределенным независимым управлением. Это самое то что надо для Систем Малой Автоматизации Цена полной системы (БП+ПЛК+нормир.усилители+программирование и тестовая отладка) со всеми затратами соизмерима с "голыми" отечественными ПЛК типа КОНТАР...
Например ОВЕН ПЛК+ИП320 оправдывает себя на верхнем уровне как мастер-ПЛК, потому что на порядок быстрее Миллениум3, имеет "большие мозги" и кучу интерфейсов связи. Это позволяет организовать высокоуровневое качественное управление группой подчиненных Миллениум3...

[SasaVitebsk]

Что-то тема подзаглохла
Или народ подзадумался об чём?

А что Вы хотите? Чтобы кто-то кинулся модернизировать и развивать чужое изделие за просто так? Или Вы хотите чтобы кто-то с нуля разработал аналогичный ПЛК но с большими возможностями и за меньшие деньги?

К сожалению мы здесь с Вами находимся по разные стороны баррикад. Мы выступаем в качестве поставщиков, а Вы в качестве покупателей и, поэтому у нас разные цели.

За тему спасибо. Кто хотел, тот внимательно её просмотрел. И сделал свои выводы. Я Вам скажу, что я сильно погорячился указав Вам срок исполнения 1 год. Если рассматривать такое изделие как универсальное, то полный цикл разработки, включая саму аппаратную часть, ПО изделия + ПО IBM + документация включая примеры разработки + маркетинг (чтобы довести до потребителя так как один покупатель здесь не проканает, а рынок достаточно плотно занят). Я думаю это для средней конторы года так на 1.5 - 2. Надо также учитывать, что такое изделие надо выпускать семейством. То есть группу изделий разной сложности с разными возможностями и ценами. Таким образом выходят 2.5 - 3 года. Так за это время другие поставщики тоже сопли жевать не будут, а учитывая свои наработки уйдут далеко вперёд.

Поэтому заниматься таким может мощная контора с серьёзными разработчиками и серьёзным вливанием денег в данную тему. Даже если Вы сейчас и побудили кого-нибудь к такому творчеству, то неизвестно когда Вы дождётесь результатов.

[anpilog]

Я бы точнее не сказал

[AlexG_changed]

Что-то тема подзаглохла

Времени пока нет основательно заняться изучением возможностей Millenium3, но есть надежда что появится.

ИП320 мне кажется еще сырой, у ОВЕНу похоже год нужен чтобы устранить основные глюки.

PS: "серебрянной пули нет"

[АндрейХ]

AlexG
На безрыбье и рак рыба...
Альтернативы ИП320 пока не знаю, поэтому взял одну штуку для пробы. Попробую, посмотю...
Главное что ОВЕН заинтересован и работает над своими изделиями, не толчет воду в ступе и не отписывается.

SasaVitebsk
Вообще-то тема была мною открыта по другому вопросу, но как всегда бывает на Руси из конкретики плавно перетекла в глобальное...
Я всего лишь задавал вопрос по возможности незначительных изменений в существующем ПО, а всё закончилось обсуждением создания альтернативного контроллера с расплывчатым "если да кабы" чисто по нашенски.
Кстати ОВЕН выпустил ПЛК за год, с ошибками, но оперативно их исправляет. Не всё гладко, оно и понятно, начинали с ноля...
А если рассуждать как вы то имхо вааще не стоит браться за это дело... оно обречено изначально...

Нано-ПЛК как замена приборам КИПиА должны отвечать следующим требованиям - аналоговое измерение (не менее 10 бит), возможность реализации САР, логика управления, создание многоуровневых меню с возможностью внесения изменения с кнопок (например уставок задания).

По поводу рынка - я знаю всего три модели нано-ПЛК пригодные для замены приборов КИПиА: ALPHA XL (нет сетевой поддержки), EASY-800 (дорогой), Millenium3 (то что надо, но желательна доработка ПО).
Все остальные существующие нано-ПЛК пригодны только для простых логических задач. Отечественные производители вааще не выпускают нано-ПЛК, даже самый дешевый ОВЕН можно отнести к микро-ПЛК как по цене так и по возможностям.

П.С. Из данной темы я понял - всё всегда заканчивается флудом...
Попробую с КРУЗЕТом побазарить, предоставлю им макросы на ихнем-же ПО шоб они сделали на их основе низкоуровневые ФБД... может согласятся, а может нет... а там будем посмотреть...

Сообщение отредактировал АндрейХ - Dec 17 2007, 21:47

[AlexG_changed]

Кстати ОВЕН выпустил ПЛК за год, с ошибками, но оперативно их исправляет. Не всё гладко, оно и понятно, начинали с ноля...

ОВЕН использовал готовую среду разработки и исполнения - CoDeSys. Для нано-ПЛК нужно что-то попроще и полегче.

...создание многоуровневых меню с возможностью внесения изменения с кнопок (например уставок задания).

Вы решили эту задачу на Millenium3 ? Если да, можно взглянуть как? У меня с Zelio Logic возникли трудности именно с реализацией интерфейса пользователя - память на текстовые сообщения (Display) расходуется очень быстро.

Отечественные производители вааще не выпускают нано-ПЛК

А это что тогда: http://www.segnetics.com/main.aspx?Page=316 ?

Попробую с КРУЗЕТом побазарить

Сообщите о результатах?

[АндрейХ]

AlexG
Как ни крути а меню съедают от 20 до 50% ресурсов. Можно экономить за счет оптимизации самих меню, и за счет оптимизации исполняемой программы (вот именно поэтому мне и нужно несколько собственных низкоуровневых ФБД для экономной реализации ПИ, ПИД-регуляторов).

[AlexG_changed]

На картинке ничего нового для себя я не увидел, но с отсутствием кирилицы выкрутились красиво

[SasaVitebsk]

SasaVitebsk
Вообще-то тема была мною открыта по другому вопросу, но как всегда бывает на Руси из конкретики плавно перетекла в глобальное...
Я всего лишь задавал вопрос по возможности незначительных изменений в существующем ПО, а всё закончилось обсуждением создания альтернативного контроллера с расплывчатым "если да кабы" чисто по нашенски.
Кстати ОВЕН выпустил ПЛК за год, с ошибками, но оперативно их исправляет. Не всё гладко, оно и понятно, начинали с ноля...
А если рассуждать как вы то имхо вааще не стоит браться за это дело... оно обречено изначально...

Нано-ПЛК как замена приборам КИПиА должны отвечать следующим требованиям - аналоговое измерение (не менее 10 бит), возможность реализации САР, логика управления, создание многоуровневых меню с возможностью внесения изменения с кнопок (например уставок задания).

По поводу рынка - я знаю всего три модели нано-ПЛК пригодные для замены приборов КИПиА: ALPHA XL (нет сетевой поддержки), EASY-800 (дорогой), Millenium3 (то что надо, но желательна доработка ПО).
Все остальные существующие нано-ПЛК пригодны только для простых логических задач. Отечественные производители вааще не выпускают нано-ПЛК, даже самый дешевый ОВЕН можно отнести к микро-ПЛК как по цене так и по возможностям.

П.С. Из данной темы я понял - всё всегда заканчивается флудом...
Попробую с КРУЗЕТом побазарить, предоставлю им макросы на ихнем-же ПО шоб они сделали на их основе низкоуровневые ФБД... может согласятся, а может нет... а там будем посмотреть...

Давайте по пунктам.
1)

...вопрос по возможности незначительных изменений в существующем ПО...

- Можно. Но для того чтобы внести "незначительные" изменения, постороннему разработчику, придётся сначала ПОЛНОСТЬЮ разобраться со всем изделием. Плюс разобраться с механизмом внесения изменений. Плюс ПОЛНОСТЬЮ разобраться с программным обеспечением комплекса программ IBM. Иными словами постороннему разработчику придётся потратить времени ЗНАЧИТЕЛЬНО БОЛЬШЕ чем официальным разработчикам. Соответственно стоимость внесения таких изменений будет сопоставима либо даже больше чем запросят официально.
2)

Кстати ОВЕН выпустил...

. ОВЕН крупная фирма и работает именно в этом направлении. Я удивлён, что они раньше не выпустили данное изделие. Откуда вы знаете, что они его разрабатывали год? Плюс правильно отметили, что они использовали готовую среду. (Тоже верное решение. Я бы тоже так делал. Совместимость снизу и разбиение разработки на два этапа). Кроме того, подозреваю что с документацией как всегда напряг? То есть они выполнили одно из десяти необходимых условий (которые я описывал). Но мне кажется, что мы увидим и следующие шаги от них. В том числе и более слабые и более сильные ПЛК. Должно быть семейство.
3)

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

Вы меня не поняли. Перечитайте ещё раз. Оно не обречено на провал, оно займёт слишком много времени. Что с точки зрения Вас - одно и то же. С моей же точки зрения - не совсем. Я сейчас обдумываю сделать несколько изделий в этом направлении (возможно ещё кто-нибудь тоже). Просто вам это никак не поможет. Вам надо здесь и сейчас. Зачем вам через год - два.

За тему - спасибо. Разрешите несколько вопросов задать вам как думающему и ищущему пользователю.

Рассмотрим дешёвый вариант типа вашего любимого милениума.
Надо чтобы вы понимали, что можно сделать море памяти, но он будет достаточно медленный, и наоборот. Так вот хотелось бы узнать, по возможности более полно...
1) Как вы оцениваете быстродействие
2) какое быстродействие и по каким параметрам вы считаете приемлемым
3) Считаете ли вы достаточными органы управления данного контроллера
4) Сколько вам необходимо памяти для работы
5) Какие "сетевые" интерфейсы вам важны и какие "на всякий случай".
6) Сколько портов и каких вы считаете достаточным
7) Как часто вы перепрограммируете ваш ПЛК и не напрягает ли вас система перепрограммирования милениума
8) свои пожелания.

Заранее спасибо.

[АндрейХ]

AlexG
Естественно ничего нового не придумаешь, дык всего один блок ФБД.
Можно только слегка оптимизировать механизм перехода между экранами, но не более того...
Кстати, а ты знаешь что можно вводить данные с дисплея? Например в FBD - MEM.
Соединяешь блоки как на картинке и ставишь в меню ФБД (клик правой лапой мыша по ФБД) флажки Authorized modification. Можно установить ограничение Minimum и Maximum. Вот только без багов не обходится, при превышении установленных значений происходит сброс в ноль, а по хорошему просто должно "заморозиться" значение на максимуме или минимуме. И есчо мне не нравится мигание черными квадратиками значений (У АЛЬФЫ ХЛ есть несколько вариантов выделения), лучше шоб линия подчеркивания моргала при просмотре, а при редактироании моргало значение...


SasaVitebsk
Если вам интересно то отвечу вам исходя из 3-х летнего опыта интеграции нано-ПЛК как САР+управление.
Давайте по пунктам.
1) Как вы оцениваете быстродействие - желательно 10мс на всё. Приоритет естественно за средой исполнения, далее сеть, вывод данных на дисплей и низший приоритет у кнопок.
3) Считаете ли вы достаточными органы управления данного контроллера - диплей 4х16(18) + 8 кнопок: 4 стрелки, +,-, ESC, OK.
4) Сколько вам необходимо памяти для работы - 300 "чистых" ФБД вполне достаточно (можно исходить из имперического правила - 5...10 ФБД на канал вход/выход), это без учета инфы для дисплея, и сетевых данных. Т.е. получается по АТмеге 8кБ ОЗУ, но "чисто" под исполнение, без учета дисплея и сети.
5) Какие "сетевые" интерфейсы вам важны и какие "на всякий случай" - классика - MODBUS RTU, и "на всякий случай" наверно CAN для связи с низкоуровневыми "железками" и расширениями вх/вых.
6) Сколько портов и каких вы считаете достаточным - один MODBUS, порт программирования, и до двух CAN (на всякий случай, если выступает как универсальная шина расширения).
7) Как часто вы перепрограммируете ваш ПЛК и не напрягает ли вас система перепрограммирования милениума - часто перепрагроммируется ПЛК только в процессе разработки "новинок" (ну тут и убить не жалко один ПЛК, лишь бы результат был положительный. Современные чипы вроде позволяют 10000 раз перепрограммировать, хватит за глаза). При "типовом" (с использованием проверенной библиотеки макросов) программировании перепрограммируется изделие не более 10 раз.
8) свои пожелания - В ПЛК есть одна отличительная особенность: переменные-константы, т.е. перепрограммируемые константы, или наоборот надежно сохраняемые переменные - изменяются как переменные, а хранятся как константы. Еще есть флаги состояния. Многие ФБД блоки позволяют сохранять состояние своего выхода (например триггер) на момент вырубания питания - вещь нужная, но с возможностью её выбора, потому как в одних случаях необходимо обязательно сохранить состояние, а в других это категорически запрещено.

[АндрейХ]

Серфингируя по просторам интернета наткнулся на аналог CoDeSys от фирмы kirchner SOFT под названием logiDOC и logiCAD. Внешне проги схожи с CoDeSys, но как работает я так и не врубился... Есть одна отличительная особенность - в пакете инсталлируется gcc с библиотекой Си. Ежели кому интересно то посмотрите, может чего интересного нароите...

[АндрейХ]

Вот нарыл еще одну интересную вещицу - MODBUS constructor. Может кому будет интересно - http://www.kurysoft.com/

[АндрейХ]

Нашел программу с открытыми ресурсами для PIC и ATmega
Думаю будет интересно спецам, что думаете?
Ссылка - http://www.cq.cx/ladder.pl#dl

[Denisvak]

Нашел программу с открытыми ресурсами для PIC и ATmega
Думаю будет интересно спецам, что думаете?
Ссылка - http://www.cq.cx/ladder.pl#dl

Делал что-то типа плк....(с элементами И,ИЛИ,НЕ, что-то типа таймера) правда просто модель в VC++ все работало. Логика задавалась текстом

[АндрейХ]

[/b]Denisvak[b]
ПО на этом сайте имеет простенький графический интерфейс и генерит *.hex и *.ld коды

[AlexandrY]

Вцените в таком случае http://www.pro-sign.de/html/I2005/english.html
И статейку если еще не читали: http://aly.ogmis.lt/Projects/OpenPLC/VisualIDE.pdf
Сделать PLC нет проблем, и очень дешевый тоже можно.
Но что-то мне говорит, что юзеров с такими запросами как у вас на самом деле очень мало.
В этой отрасли важны не тех.характеристики, а исключительно человеческие отношения

[/b]Denisvak[b]
ПО на этом сайте имеет простенький графический интерфейс и генерит *.hex и *.ld коды

[amusin]

Нашел программу с открытыми ресурсами для PIC и ATmega
Ссылка

Вот еще Classic Ladder.
http://membres.lycos.fr/mavati/classicladder/

А как было бы здорово, если бы был открытый проект runtime + среда программирования!
В ПЛК - javaVM + специализированные классы.
Среда программирования:
ввод - Beremiz, сохранение проекта в XML (OpenPLC дает фррмат - см. вложенный файл),
XML to java - некий компилятор генерит исходный файл java (Beremiz делает в Си, к сожалению, что, имхо, направление в никуда из-за требования наличия Си-компиляторов, которые почти всегда платные для большинства платформ).
Дальше подсовываем исходник компилятору java из JDK, например, и имеем на выходе процессорно-независимый байт-код.
Плюсы - мейнстримовский тулчейн, royalty-free система исполнения.

Итого - платить нужно только разработчику ПЛК за компилятор. Юзеры не платят ни прямо, ни косвенно (roylaty-то нет).

Самое интересное, что поиск в инете дает слабую корреляцию между Java/JRE и PLC. Только IsaGRAF отметился. Хотя, по-моему, все должно идти к стандартизации системы исполнения, будь она хоть на java, хоть еще на чем (LUA и пр.)

Прикрепленные файлы

 TC6_XML_V101.pdf ( 677.46 килобайт ) Кол-во скачиваний: 303

 

[АндрейХ]

amusin
Если ты любитель покурить Явку то тебе поможет ПО LOGO! comfort, которое работает на nano-PLC LOGO! compact. ПО сделано всё на Яве. Сделано весьма не дурно, удобнее работать чем с Step7...
Кстати неплохая и очень распространеная игрушка, но есть одно НО!. Разработчики "забыли" добавить математические ФБД блоки, и на все просьбы скромно отмалчиваются уже два года - типа и так схавают...
Скачай, посмотри, попробуй... рекомендую, если ты спец по JAVA....

ГЫ... Как время летит, а ведь в конце 80-х годов работал вот с такими гробами...

страшно сказать, но за такое чудище даже щас просят 7500 убитых енотов...
Я за такие бабки десяток ноутов купить могу.

[SasaVitebsk]

Вцените в таком случае ... статейку если еще не читали: http://aly.ogmis.lt/Projects/OpenPLC/VisualIDE.pdf

Похоже Millenium пошёл по пути iCon-L. То есть заведомо прописанные кусочки и сборка готового проекта.

[АндрейХ]

SasaVitebsk
Похоже Millenium пошёл по пути iCon-L. То есть заведомо прописанные кусочки и сборка готового проекта.
А может КРУЗЕТ использует iCon-L для создания целевой системы?
Надо будет попробовать намыть сеё чудо...