[SapegoAL 0]

SasaVitebsk

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

 

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

 

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

 

Мой бы подход был следующим (с точки зрения AVR)

1) Я бы реализовал интерпретатор элементарный и описал бы хранение/передачу параметров.

2) Реализовал бы необходимые интерфейсы связи.

3) Я реализовал бы максимально возможное число вылизанных функций разного уровня. Вплоть до самых низкоуровневых. Чем забил бы флэш до предела.

 

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

 

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

 

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

[АндрейХ 0]

SasaVitebsk

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

 

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

[SapegoAL 0]

SasaVitebsk

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

 

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

 

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

Поясню почему.

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

2) Надо отслеживать исполнения. Так как конечный адрес может находится в произвольном месте.

3) Необходимо предусмотреть переход на ваши блоки или их вызов из основной программы, при этом не зная их адреса на момент написания.

 

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

 

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

 

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

 

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

[AlexG_changed 0]

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

Поясню почему.

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

2) Надо отслеживать исполнения. Так как конечный адрес может находится в произвольном месте.

3) Необходимо предусмотреть переход на ваши блоки или их вызов из основной программы, при этом не зная их адреса на момент написания.

 

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

 

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

func.zipfirmware.zip

Изменено 10 декабря, 2007 пользователем AlexG

[khach 35]

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

[AlexG_changed 0]

Работы будет несколько больше, каждый плагин имееют еще и PC-шную часть.

Мегу перепаивать скорей всего не придется, надо вывести JTAG и разъем программирования, если его нет.

С JTAGом изучение прошивки должно вообще весело пойти.

[mse 0]

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

Поясню почему.

1) Вы плохо себе представляете ассемблер

...

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

Ну и вызывайте сколько угодно раз, ессно.

[АндрейХ 0]

Господа, а зачем гадать на кофейной гуще

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

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

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

Из недостатков Миллениум3 вижу три - есть ряд ненужных ФБД в основной библиотеке, которые я бы заменил на 5 нужных, нет поддержки кириллицы в дисплее, и желательно иметь хотя-бы простенький менеджер меню дисплея по подобию АЛЬФовского. Такого ПЛК точно хватило бы на 2...3 года до появления более продвинутых систем за те-же деньги.

[SapegoAL 0]

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

 

В таком случае из этого проистекает следующее:

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

[khach 35]

Господа, а зачем гадать на кофейной гуще

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

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

По поводу JTAG- ну надо быть совсем тупым, чтобы продавать устройство с незалоченным интерфейсом отладки. Часто бутлоадер с залоченной Атмеги вычитать вообще неудается, и приходиться писать свой, функционально аналогичный.

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

[AlexG_changed 0]

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

По поводу JTAG- ну надо быть совсем тупым, чтобы продавать устройство с незалоченным интерфейсом отладки.

 

1. Предупреждаю, скорость скачивания очень низкая. У меня получилось докачать только с третьей попытки

2. Судя по всему эмулятор именно функциональный, в режиме эмуляции используется dll, а не код для АТмеги. (надо будет проверить, это просто)

3. Залоченный или незалоченный интерфейс не имеет значения когда прошивка лежит в открытом виде, можно самостоятельно все что угодно разлочить. Другое дело что JTAG на платах часто не разведен.

Изменено 10 декабря, 2007 пользователем AlexG

[АндрейХ 0]

khach

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

 

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

[AlexG_changed 0]

АндрейХ

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

[АндрейХ 0]

AlexG

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

[Denisvak 0]

АндрейХ

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

 

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