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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можете посмотреть сами, вот одна из дополнительных функций и одна из прошивок контроллера:
Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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...

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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



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

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

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

Давайте по пунктам.
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

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

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

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

Вот еще 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 и пр.)

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

ГЫ... Как время летит, а ведь в конце 80-х годов работал вот с такими гробами...
Нажмите для просмотра прикрепленного файла
страшно сказать, но за такое чудище даже щас просят 7500 убитых енотов...
Я за такие бабки десяток ноутов купить могу.

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

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