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

[АндрейХ]

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

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

[AlexG_changed]

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

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

[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