Для самообразования, раскажите какие задачи решает "Системы Малой Автоматизации". Что-то типа связное управление рефрижератора и системы обдува ?
ПС я так понимаю вы здесь не найдете то что ищите.

Техподдержка - наше всё!



От открытия проекта до первых серийных образцов - год. И своего кода в ПЛК в 2 раза больше, чем CoDeSys-овского.
А линейки разрабатываем.

Вот взгляните есть интересная разработка:
http://smartbox.jinr.ru/doc/smart-basic.chm

Программирование контроллеров на языке BASIC

Или вот, например, программируемый на ВАСИКе контроллер на АТМЕГА8: http://www.cqham.ru/PLC_1.htm
Где-то на форуме это уже обсуждалось.

Тема заглохла слегка, но попробуем реанимировать...
Что новенького появилось в мире nano PLC?
Я нашел пока из свеженького Siemens LOGO! V6.
Из приятного - дисплей поддерживает кириллицу, много функций доступно из меню, например настройки ПИ-регулятора. Не считая нескольких мелких неприятностей эта игрушка вполне пригодна для создания РАБОТАЮЩЕГО ПИ-регулятора с различным "обвесом" и вменяемым меню. Такие фичи трудно реализовать на классических регуляторах, а брать micro-PLC влом не столько из-за денег сколько из-за возни с ПО. STEP7 вещь нужная и хорошая, но для простых задач тяжеловата.
Еще по тихоньку развивается CROUZET Millenium 3 Вышла свежая версия v.3.5.1, причем скачал не демо, а рабочую версию. От предыдущей отличается дополнительными расширениями, а так ничего новенького, хотя моделька интересная. Плохо то что CROUZET не представлен в России официально. Имхо один из наиболее удачных вариантов нано ПЛК с программным обеспечением - пример для подражания...
Если у кого есть инфа или мысля по nano PLC плиз заходите на огонек...

Появление в продаже дешевых, легких и компактных неутов облегчили жизнь простого наладчика.
Я приобрел для работы неут ASUS Eee PC 900 Celeron 900, 1Gb ОЗУ и 20Gb твердотельным диском. Вместо Люникса воткнул Винду и доволен как слон... Неут нормально общается с разными железками через USB адаптеры, в частности USB-RS232(full), реализованный на Prolific. Осталось только сбацать USB-RS485 и всё будет в шоколаде. Есть ОВЕНовский АС4, но он не пашет нифига...
Прикупил неуту дешевенькую сумочку с кучей отделений, напихал туда разного наладочного добра и получил легкую, компактную РС лабораторию весом в 1кг.и ценой меньше 15 т.р.
Думаю что через годик можно будет за те-же деньги взять полностью боевую машинку, способную ворочать даже таких монстриков как LabView.
Нажмите для просмотра прикрепленного файла

А я сейчас проект делаю на Siemens S7-314C-2DP + CP341 + экран 10" тач.

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

В результате, чтобы подключить привод постоянного тока Mentor (а у меня их 9 штук) к профибасу, надо купить опцию, которая стоит 900 (здесь и далее цена в euro на границе с Германией. То есть без накруток и растаможек. Иными словами - умнож на 2). Я заржал - а они готовы были купить!!!!

И это притом, что профибас на базе RS485 реализован. Ну покопался - нашёл что можно по-дешаку, всего за 1500 подкупить CP341 - фактически адаптер RS232/422/485 к данному процу. При всех мыслимых наворотах (а их, кстати очень мало) стоимость по кркмнию такой железки никак не должна быть больше 100. Ну, думаю, в инете найду кучу дров для разного нестандартного оборудования.

Как бы не так!!! Плавает где-то драйвер MODBUSа от сименса за 1500!!!!
Недоделанный!!!! То есть реализованы только базовые команды. (Оно и понятно)

Я его помню на х51 за неделю с отладкой!!!! Этож надо так людей ненавидеть. Задал на форуме вопрос - ответов практически 0. Все капусту рубят. За даром нифига не получишь!!!

Изучил 4 толмуда включая FBD/LAD/STL/SCL/WinCC. Заканчиваю проект. Драйвер привода вчера проверил окончательную редакцию на STL.

Протокол к Mentor писал похоже ребёнок. О какой помехозащищённости может речь идти? Ответ на посылку - одним байтом. Контрольная сумма XOR.
STL писал не ребёнок. Просто дебил. Причём я не оскорбляю - я льщу! Ассемблер с одним аккумулятором - это круто.


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

Что же остаётся - только внешний вид! Это следует признать. Здесь сименс рулит.

SasaVitebsk
При всех мыслимых наворотах (а их, кстати очень мало) стоимость по кркмнию такой железки никак не должна быть больше 100.
Согласен, только производители такие деньги не за кремний берут, а за надежность. А надежность требует соответствующего тестирования каждого изделия на всех этапах производства от чипа до конечного изделия, и соответственно цена лезет вверх. Как пример - почему промышленный комп стоит в пять раз, а военный вааще в 10 раз дороже обычного компа?

Протокол к Mentor писал похоже ребёнок. Может это лучше пьяных студентов??? Ты видать не особо знаком с "шедеврами" отечественного самостроя, которые кстати стоят то-же не по децки. Например есть такой шЫдэвр программульствования как "Орион про" который в среднем стоит от 50 штукарей рублей, а я бы за такое творчество бесплатно поубивал этих программеров...

Это я объясняю только дилетанством покупающих, а также тем, что 200% заложено в виде поборов и взяток.

Конечно. Смотря с чем сравнивать.

Тем не менее с теми, с кем я связывался и вот я общаюсь на форуме - основная масса - нормальные разработчики. Надёжность выпускаемых ими изделий - даже заочно - навеняка более чем приемлемая. Тот же сименс - успешно выходит из строя. Нет ничего с надёжностью 100%.

С другой стороны для того чтобы пробить изделие - тратятся баснословные деньги и усилия. Зачем????? Пусть заказчик и выбирает! А так мы просто субсидируем зарубежных поставщиков и прибиваем своих. Бред! А потом громко кричим - что-нибудь подешевле и с русскими буквами.

А так мы просто субсидируем зарубежных поставщиков и прибиваем своих. Бред! А потом громко кричим - что-нибудь подешевле и с русскими буквами.
Это конечно мое имхо. Проблема создания законченной системы, а не только одного ПЛК лежит в области, модного щас слова, менеджемента. Проблема в отсутствии грамотных менеджеров проектов - либо чел спец но не руководитель, либо наоборот, умеет руководить коллективом но как спец в области нулл. А для нашего стада нужен очень грамотный руководитель, а то разбредутся кто куда.
Я это знаю не по наслышке побывав в недрах наших разработчиков и пообщавшись. Все хотят, знают каждый отдельный кусочек, НО НИКТО НЕ МОЖЕТ выработать стройную концепцию масштабируемой системы, а уж тем более её реализовать Простой пример - когда я начал рассказывать ребятам-программятам о нюансах реализации импульсного ПИД регулятора на контроллере они на меня смотрели как бараны на новые ворота. Т.е. ребята рубят в СИ и всяких С++ но не имеют представления о САР и естественно результат на выходе нулевой. Ну да ладно, есть выход - взяли МЭК и любой контроллер, да хотя-бы S7-200 для начала и слизали, но ведь даже этого не могут...
Для того что-бы понять как изделие и тем более комплекс изделий будет работать я читаю описание и смотрю ПО. Если описание скомкано, непоследовательно и сумбурно то и изделие такое-же. Можно смело задвигать эту железку подальше, даже если она дешевле в три раза Сименса. Можно конечно Сименс обвинять в хапужничестве, консерватизме и медлительности, но по его документации можно преподавать в колледжах. Даже извечный конкурент Митсубиси не может похвастаться такой документацией. Про наших я просто молчу... Единственным продуманным очественным продуктом я считаю РЕМИКОНТ с грамотной документацией, но надо учитывать что его в совке рожал целый НИИ, а не кучка энтузазистов...

Здается мне, что Вы набрали себе в штат студентов, платите им по $100/мес и хотите чтобы они ворочали горы.

Видите ли АндрейХ, я разделяю ваш подход. Вы очень правильно очерчиваете круг задач и ставите вопросы. Но вы их рассматриваете с точки зрения покупателя и потребителя (и это правильно). А я смотрю на это со стороны производителя.
И что я вижу?

В совковые времена - программа не была продуктом! Наш завод выпускал одно и тоже изделие - графопостроитель ЭМ 7062 и ЭМ7062а. Точнее аппаратно это было одно изделие. Но 7062 работал медленнее (минчане ПО писали) раза 3-4 и имел уникальную систему команд. А 7062А работал быстрее и имел систему команд HP GL. Это позволяло ему работать прямо из-под PCAD и др. продуктов. Тем не менее мы даже новое наименование получить не смогли, как видите. Результатом такой оценки труда явилось то, что вся отрасль по созданию МикроПО/ПО пришла в полный упадок.

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

То есть немцам надо просто продать, а нам надо создать, пробить, внести в реестр, сартифицировать, убедить заказчика ...... Короче учитывая нынешнее состоянее отрасли - немыслимые потери времени сил и денег. И за ради чего? Что даёт этот сартификат? Кто его получал - тот знает чего он стоит.

Вот и получается, что вся наша система ориентирована на внешние рынки. Фактически уничтожает своего производителя.

А технические вопросы - просто пыль морская. Это я вам говорю как есть. Я тоже слабо знаком с ПИД регуляторами. А 5 месяцев назад ни чего не знал о STL/FBD/LAD. Месяц - и я написал драйвер привода, по которому мне на симатике не смогли ответить. Литература и вперёд! Всегда когда начинаешь проект - чего-то не знаешь. Это всё ерунда.

Я ещё раз повторяю масса разработчиков на этой конфе способны создать изделие на порядок лучше и продуманнее S7. Это не голословное утверждение. Я имел счастье общаться с данным изделием. Я имею ввиду именно весь комплекс. У меня, когда я работал - роилось масса идей. Но учитывая написанное, я не думаю что в ближайшее время возникнет серьёзный конкурент у этой конторы. Даже в маленьком сегменте данного рынка.


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

Может для милениума это и не выход, но применять панель сименс 10" за 3700 euro, учитывая что аналогичные изделия с аналогичным функционалом стоят 2000, а простой корейский TFT моник 19" стоит 230$ это же немыслимый обман окружающих. Это же не в 10 - это же в 20 раз!!!

defunct
Здается мне, что Вы набрали себе в штат студентов, платите им по $100/мес и хотите чтобы они ворочали горы.
Вы не угадали, я всего лишь интегратор, а ПЛК занимает в моей работе 10-50% от общего объема работ по автоматизации.
В борьбе за соотношение цена/возможности приходится всячески извращаться, в частности максимально адаптировать дешевые nano-PLC для задач ПРАВИЛЬНОГО регулирования (в большинстве nano-PLC ПИ-ПИД регуляторы вставлены "для галочки" и как правило не работают) и управления. Почему ПЛК? Всё очень просто, только на них можно реализовать интегрированное гибкое многосвязанное регулирование&управление с оперативным изменением алгоритмов управления.
К сожалению в отечестве нет дешевых ПЛК отвечающих моим потребностям. Даже ОВЕН не отвечает этим требованиям по одной простой причине, они не решили пока комплексной задачи безгеморойного масштабирования своей системы, у них зоопарк, который замучаешься настраивать, отсель лезет куча багов. Есть еще интересный ПЛК от Сегнетикс из Питера, но у них засада с расширением входов/выходов. А мне нужно решать оперативно малые и средние задачи не задумываясь о совместимости железок. Так, если не хватает входов/выходов просто нужно добавить модуль расширения и не парится. Основные усилия должны быть направлены на решение прикладной (технологической) задачи, а не к борьбе с железками. Импортные ПЛК к сожалению то-же не полностью отвечают моим требованиям, а переходить на micro-PLC нужно только в крайних случаях потому как цена сразу подпрыгивает в 2-3 раза. Когда я представителям Mitsubishi показал реализацию регулирования и управления на ALPHA XL у них глаза стали больше чем у русских...
Вот щас вышла новая шестая версия LOGO!. Поигрался с прогой, где-то на 80-90% она обеспечивает необходимый функционал. Сименс рожал эту версию три года. Я еще в 2005г. давал им рекомендации по функциональным блокам, расписывал, разрисовывал, и всё равно трех очень нужных блоков они не вставили... Ну ничего, придется мозгами догонять, не в первой.
А ситевина выходит до ужаса смешная, если скрестить Mitsubishi ALPHA XL с CROUZET Millenium 3 и Siemens LOGO! то получится полнофункциональный nano-PLC которого хватит минимум лет на пять удовлетворять чаяния заказчиков...
Нажмите для просмотра прикрепленного файла

А разрешите пару вопросов.
1) сколько примерно стоят означенные три ПЛК
2) Сколько времени у вас в среднем уходит на средний проект
3) Как часто вам приходилось "оперативно менять" в смысле возвращаться к заказчику.
4) Что вы понимаете под расширением портов - блок расширения в сам ПЛК или выносной модуль по типу "удалённой переферии"
5) Как часто вам приходилось выдавать инфу на "стандартные сетевые протоколы" и какие именно протоколы приходилось использовать.

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

PS: Применятся скорее всего будет процессор с залитым ядром CodeSys

По вашим рассказам выходит что открыта прекрасная ниша для разработчиков-производителей. Чего не хватает чтоб занять ее ?


Оно продается или где-то скачать можно ?

SasaVitebsk
1) сколько примерно стоят означенные три ПЛК
2) Сколько времени у вас в среднем уходит на средний проект
3) Как часто вам приходилось "оперативно менять" в смысле возвращаться к заказчику.
4) Что вы понимаете под расширением портов - блок расширения в сам ПЛК или выносной модуль по типу "удалённой переферии"
5) Как часто вам приходилось выдавать инфу на "стандартные сетевые протоколы" и какие именно протоколы приходилось использовать.
Отвечаю:
1. Стоимость локальных nano-PLC лежит в пределах 5000-8500р.в зависимости от количества и типов вх./вых. Для анализа достаточно пройтись по сайтам, торгующих перечисленными постом выше ПЛК и собрать всю инфу. Для КИПиА наиболее интересны ПЛК с аналоговыми входами 0-10В.(0-20мА) (минимум 10 бит, лучше 12 бит АЦП), они же при необходимости могут выступать в роли дискретных входов, и опционально с аналоговыми выходами 0-10В. Очень замечательно если будут входа для термометров сопротивления и термопар (до 6-8 входов, от них быстродействие не требуется). В среднем для ПЛК достаточно до 6-8 аналоговых входов и до 2-х аналоговых выходов.
Практика использования ПЛК в инженерии зданий (отопление, вентиляция и т.д.) показывает что наиболее подходящим по кол-ву входов/выходов является ПЛК Millenium 3 XD26. Описание можно найти на сайте CROUZET. ПО правда у них слегка недоработано - ПИ-регулятор просто никакой.
2. Времени на проект может уйти от пары часов (если есть наработанные макросы для конкретной задачи) до нескольких дней (если есть нюансы в проекте, которые ранее не реализовывались).
3. К заказчику приходится возвращаться в зависимости от его капризности, но на практике не очень часто. Если нужно отделаться от назойливого капризного заказчика то нужно просто от него требовать официальный запрос на изменения с подписями и печатями. После этого выставлять счет. Обычно аппетит у заказчика резко снижается... Для того что-бы не было всяких казусов достаточно грамотно составить ТЗ (техзадание) и обязательно официально, потому что это ИСХОДНЫЙ ДОКУМЕНТ для дальнейшей работы с заказчиком.
4. Под расширением понимается однозначно классический шинный метод расширения, например как в S7-200. Модули расширения ставятся рядом и соединяются коротким шлейфом. Для нано-ПЛК использовать иной метод нецелесообразно, например мизанинный со слотами потому что придется делать специальную конструкцию, а не использовать простую коробку, а это сведет на нет экономию на корпусах для модулей расширения.
По поводу удаленных модулей - вещь хорошая и нужная, но без потерь в скорости работы системы, глючности и сложности настройки. Согласовывание модулей расширения с процессорным модулем должно быть наипростейшим, лучше всего по возможности Plug & Play. Какая шина должна использоваться сказать не могу, не разработчик.
Имхо я бы предпочел-бы смешанный вариант, например подключение к центральному модулю модуля удаленных расширений по типу шины ASi или подобной. Главное это надежность и быстродействие, чего сложно добится для сетевых реализаций. (ГЫ... как-то на одном объекте "привязывались" к системе Honnevell Хуневел через ихнии УСО. Млин, ну и тормоз, после имитации сигнала я до диспетчерской быстрее доходил чем сигнал... )
5. По поводу "стандартных сетевых протоколов" очень сложно сказать, всё завистит от проекта, т.е. это замкнутая система с простейшей сетью или интегрированная во что-то...
Вот например сейчас модно для инженерии зданий "цепляться" к системам ОПС, например "БОЛИД". Экономически вполне оправдано, но при условии если Болидовцы вас примут к себе, например ОВЕН и Контар они приняли. Это весьма выгодно по одной простой причине, мимо них не проскочишь, 90% объектов сидит на БОЛИДЕ и фиг ты куды денешься с подводной лодки при всей его глючности... эт-же пожарнички.... а вот в "обойме" оказаться это в сахаре кататься...
Так что по протоколам сказать сложно, но RS-485 должен быть однозначно, а сами протоколы может быть подгружать в ПЛК? но тут я не силен...
Может быть проще сделать модули-шлюзы с соответствующим ПО для перехода со своего протокола на чужой. Такие вроде Моха делает...
По поводу CoDeSys, предлагаю еще рассмотреть вариант с LabView. Правда тут вы получаете инструмент для создания инструментальной системы (непеводимая игра слов), а не готовую систему как CoDeSys, но надо еще смотреть на гибкость, надежность, сервис и стоимость.
Имхо хоть CoDeSys дэ-факто и классика МЭК, но мне не удобно с ним работать, слишком много рутинной работы, всякие таргеты заливать, отдельно каждый вход/выход конфигурировать, и т.д.
А нужно так - как только выбрал "новый проект" появился список модулей, поставил галочки и вперед в чистое поле швырять ФБД-шки...

garbuz
По вашим рассказам выходит что открыта прекрасная ниша для разработчиков-производителей. Чего не хватает чтоб занять ее ?
Оно продается или где-то скачать можно ?
Ниша нано-ПЛК открыта Сименсом в 1996 году. Но для КИПовцев она стала действительно интересна начиная с 2004г. с выпуском ALPHA XL имеющим 8 аналоговых 9-ти битовых входов. Еще лучше стало когда вышли ПЛК с 10-битовыми входами, аналоговыми выходами и необходимой 16-битовой арифметикой. На данных ПЛК можно реализовывать измерительно-регулирующие-управляющие устройства полностью заменяющие "классические" приборы КИПиА типа ОВЕНовских или МЗТАшных почти за те-же деньги но с гораздо большей гибкостью и универсальностью...
В чем выгода для обеих сторон - производитель не плодит зоопарк модификаций (а это жуткая проблема и головная боль), а у интегратора развязаны руки в меру его фантазий и способностей...

У Сегнетикса два интересных ПЛК, SMH и PIXEL. SMH без проблем расширяется по Modbus, а к Пикселю есть модули расширения. По ним еще нет информации на сайте, но их уже можно купить, см. вложение. Я не применяю эти ПЛК массово только из-за неудобной среды разработки программ (SMLogix). По своим возможностям SMH и Pixel далеко обошли близкие по классу контроллеры, даже Millenium 3. Надеюсь что SMLogix со временем доведут до ума.

У меня пожелания к идеальному nano-PLC простые - Millenium 3, но больше памяти и входов и выходов, и убрать некоторые ограничения и недоработки

Есть кстати мысль по расширению области применения Zelio и Millenium, можно написать OPC-сервер под их собственный, нестандартных протокол. Тогда можно будет вытащить из контроллера гораздо больше данных, чем сейчас доступно по Modbus. 4 входных и 4 выходных регистра хватает только для совсем примитивных задач.



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

Я так понимаю, имелось ввиду вот это:
http://www.codesys.ru/tmpl.php?content=docs/mai3/mai_053.htm

AlexG
У Сегнетикса два интересных ПЛК, SMH и PIXEL. SMH без проблем расширяется по Modbus, а к Пикселю есть модули расширения. По ним еще нет информации на сайте, но их уже можно купить, см. вложение. Я не применяю эти ПЛК массово только из-за неудобной среды разработки программ (SMLogix).
Вот он камень приткновения!!! Удобство разработки и отладки прикладных задач для ПЛК
Он включает в себя:
1. Быструю конфигурацию проекта простым выбором модулей в меню
2. Удобный интуитивно понятный настраиваемый интерфейс по типу классики жанра - МС Офис.
3. Удобное поле в двух вариантах - "коробка" с входами/выходами (Millenium 3) и свободное поле редактирования (LOGO!). Выбирается по вкусу, главное что-бы юзеру удобно было.
4. Минимально необходимый набор FBD-блоков логики и арифметики с возможностью расширения библиотек как реализовано в Millenium 3 (можно продавать библиотеки отдельно как делал CROUZET, но в последней версии с сайта скачивается бесплатно весь рабочий пакет - не демо!)
5. Поддержка создания макро-FBD, с сохранением в библиотеки, и даже желательно создания "закрытого" (черного ящика) макроса.
6. Программа должна уметь сама определять последовательность выполнения программы в соответствии с нумерацией FBD-блоков, а не так как у Сегнетикса, где надо следить за расположением блоков на поле проектирования. Так-же программа должна уметь делать грамотно перенумерацию блоков при операциях вставка/замена.
7. Поддержка рекурсии (обращение функции самой к себе - соединение выхода со входом), хотя эта возможность и не предусмотрена МЭК (и даже считается вредной). Но практически все программы от Mitsubishi, CROUZET, Siemens поддерживают эту возможность, что меня очень сильно выручало во многих ситуациях.
8. Это пока экзотика, но очень нужная. Можно сделать отдельно, и продавать как ПРО!. Это инструмент разработки низкоуровневых FBD-блоков, например на IL (можно добавить ST). Тестирование и создание законченного откомпилированного библиотечного модуля.
9. Обязательно режим эмуляции в off-Line и тестирование и отладка в on-Line (изменение констант и переменных). Желательно на максимально допустимой скорости, а то в основном все нано-ПЛК "торчат" на 9600 бодах, а надо быстрее.
10. Не менее важным является и документация, она должна быть лаконична, доходчива и показательна. Очень хорошо это сделано у Сименса, можно с них брать пример. Не плохо была составлена документация для РЕМИКОНТа. При наличии полной и грамотной документации производителю не нужно будет запариваться с техподдержкой. Она потребуется только в крайних случаях.
Как пример для подражания естественно выступают CROUZET Millenium3 и Siemens LOGO! comfort v.6
Если сделать симбиоз этих прог то получится очень интересный программный продукт.
Я думаю что найдутся еще Кулибины на просторах Родины, готовые создать действительно стоящий НАРОДНЫЙ продукт, что-бы с ним мог справиться любой не самый тупой ФЗУ-шник. Только тогда можно будет говорить о развитие продукта, когда человек со средним профобразованием и навыками работы с РС сможет взяв в руки книги типа "Автоматическое регулирование" А.А.Рульнов, "Автоматика" В.Ю.Шишмарев и документацию на данный ПЛК что-то сделать более-менее внятное по КИПиА.

Сложно не согласится, но хотелось бы уточнить:
2. МС Офис классика не того жанра Я бы сказал иначе, программа должна работать понятно и предсказуемо для человека имеющего хоть какой-то опыт работы на компьютере. (SMLogix пример того как делать не надо)
3. Выбор варианта поля определяется тем, сколько входов и выходов может быть в контроллере. Вариант с фиксированными входами/выходами по краям удобен когда этих входов/не может быть много. Когда количество входов/выходов велико и, теоретически, не ограничено, как у Сегнетикса, придется перейти к свободному полю.
7. В части рекурсии, или, точнее, обратной связи, Сегнетикс обошел Крузет. У Сегнетикса работа обратной связи документирована и предсказуема, у Крузета - нет и это один из нескольких серьезных просчетов в Crouzet Logic Software. (впрочем, просчеты есть у всех)
8. Низкоуровневые скомпилированные блоки были бы полезны, но они серьезно усложнят симуляцию контроллера. Для точной симуляции необходимо чтобы на симуляторе и в контроллере работала одна и таже программа, а значит придется симулировать контроллер целиком, вплоть до ядра процессора
В Millenium 3 сейчас блоки дублируются, отдельно *.bin для AVR и *.dll для PC. Это легко может привести к несовпадению результатов симуляции с реальностью.

PS: "сделайте прибор которым сможет пользоваться даже идиот и только идиот захочет им пользоваться"

Кстати Siemens пошёл именно путём симуляции системы команд. Причём скорее всего не системы команд проца, а низкоуровневой системы команд (базы STL). Причина её появления очевидна - развязать реальное ядро от его програмной модели. То есть нет разницы на каком проце создаётся сам ПЛК. Он уже работает в режиме исполнения псевдокода. Соответственно убито два, да нет - несколько зайцев.
1) Система команд примитивна до ужаса и легко реализуется на любом проце. Меняется только производительность.
2) Развязаны руки разработчиков ПЛК в выборе проца и в обеспечении линейки ПЛК с разной производительностью.
3) Развязаны руки у разработчиков ПО разработки и отладки. Нет необходимости обеспечивать совместимость. Она определяется базовым псевдоязыком.
4) Прога симуляции будет упрощена и работать одинаково для всех изделий.

Ну а недостатки - сам псевдокод. Примитивный и убогий. Отладка - ужасна. Короче как всегда - две стороны одной медали.


Кстати симуляция работы той или иной системы на основе симуляции самого низкого уровня (например симуляции работы команд процессора) - самый найпростейший способ симуляции. А то из вашего выссказывания можно сделать вывод что этот способ найсложнейший. Как раз наоборот. И чаще всего идут именно по нему. Сам не раз это делал. А недостаток - слишком медленный. Зато достоверность намного выше других способов.

AlexG
SasaVitebsk
Я смотрю что уже завязывается конструктивный разговор...
Я конечно не разработчик но то-же скаже пару слов по симуляции:
1. В режиме offLine на realtime можно смело забить, главное достоверность и шоб не давил на психику тормознутостью.
2. В режиме onLine отображение в realtime желательно но не критично, на сколько хватит быстродействия, на столько и расчитывать.
3. В ПЛК необходима обязательная возможность вычисления времени цикла программы (обычно двойного, потому что для правильной работы ПЛК необходимо делать два прохода программы) и его задание не ниже возможного. В Millenium 3 есть целая закладка где выдаются все данные о ПЛК и можно задать время цикла (при чем Крузет сделал грамотно. у них в меню задается Nms x 2). Все временные параметры должны быть засинхронизированы.
По поводу представления "поля" программирования я написал что именно нужно два варианта, с привязкой входов/выходов и без, а уже пользователь выберет что ему удобнее.
По поводу внешних библиотек, как они будут реализованы интегратору пофиг, а вот как их создавать и присоединять уже не пофиг.
Кстати для разнообразия, есть еще одна интересная прога для самообразования от Бауманцев, рекомендую побаловаться.
Вот ссылка на сайт по САР - http://model.exponenta.ru/bt/bt_contents.html
А здесь дистрибутивы - http://energy.power.bmstu.ru/mvtu/
Очень полезная инфа для разработчиков средств автоматики.

А MS Framework и C# не рассматривался ? Вроде бы обладает как раз необходимыми свойствами для эмуляции. Правда не для Меги.

Может будет полезно - реализация LD для AVR: http://cq.cx/ladder.pl

Вопросы эмуляции, а также реализация сисиемы на кристале это конечно существенная часть, но далеко не самая главная по объёму работы.
По моим оценкам реализация ПО на кристале займёт не более 5% времени разработки.
Симуляция тоже не будет слишком затратна.

Найболее сложная часть - написание самого пакета для IBM. Он же и будет, минимум на 60-70% определять успех изделия. Пользователь ведь 90% времени не с изделием ковыряется, а с офисным пакетом. Соответственно удобство работы с ним и будет определять предпочтения. Ну а возможности изделия это сопутствующая вещь. Выбора то много, поэтому всегда можно подобрать изделие по потребностям.

Как раз написать офисный пакет уровня STEP-7, к примеру, и является проблематичным. Отсюда и Codesys. Она на это и расчитывала.

Приветсвую Всех. Я этой темой тоже интересуюсь...есть свои наработки...
http://kazus.ru/forum/topic_15211-0-asc-80.html
Можем здесь продолжить обсуждение можем там...просто здесь я немогу загрузить фаил более 2 метров(