Страница 9 из 68 ПерваяПервая ... 78910111959 ... ПоследняяПоследняя
Показано с 81 по 90 из 677

Тема: Программирование ПЛК110 [М02] для задач реального времени

  1. #81

    По умолчанию

    Цитата Сообщение от Вольд Посмотреть сообщение
    Не понятно поведение специалистов фирмы "ОВЕН". vladimirisitnikov делает интересные, я бы даже сказал, революционные предложения. А в ответ тишина. Не говорят ни да ни нет. Владислав Филоненко, вы ведущий специалист. Может вы все таки обозначите свою позицию по тому что предлагает vladimirisitnikov.

    Может будет лучше дать vladimirisitnikov полный Carte blanche (полная свобода действий) и он махом разгребет все ваши мнимые и истинные проблемы.
    И будет всем нам счастье.
    Свежо предание, но:
    Писал Владимиру, напишу и тут. Почему мы резко против компиляции из "ST".

    Тема компилятора нами вообще не рассматривается, т.к. отладка компилятора до промуровня – это много, очень много времени на тесты, валидацию компилятора.
    И "решить наскоком" эту проблему невозможно.

    Это ненадёжно. А значит такое решение нельзя использовать в промышленности, т.к. в результате отказа (а кто за него отвечать будет?) возможны последствия.

    С другой стороны, линкер (генератор prg), работающий с набором простых ФБ (с полиморфизмом, уже поддерживается), редактор (пока есть простой от 3S), поддерживающий полиморфизм и ассемблер от TI не теряют в производительности, не имеют скрытых проблем при компиляции сложного взаимосвязанного кода и визуально гораздо удобнее для разработки ПО, чем написание на ST.

    Тестирование каждого отдельного ФБ просто в силу их простоты.

    Концепция с принудительным хранением результатов работы каждого ФБ в ОЗУ или регистровой памяти (этого вообще в компиляторе с ST нет) лишена проблем с организацией и предсказуемостью обратных связей и циклов. И при этом добавление ещё одного ФБ в программу в любом месте не нарушает работу остальных ФБ. Чего нельзя сказать о монолитном коде.

    Тем более, что ST не позволяет без ассемблерных вставок работать с периферией и особыми функциями PRU.

    Также, что чрезвычайно важно, Ваш компилятор сейчас не генерирует код с константным временем исполнения (поправьте, если я ошибаюсь). Как результат, поведение программы не соответствует стандартам программ реального времени.

    Однако, использование компилятора (а точнее транслятора на ASM) с "ST" для генерации кода отдельных ФБ перспективно. Но для генерации кода всей программы – см. вышеописанные проблемы.
    Тролль-наседка, добрый, нежный и ласковый

  2. #82

    По умолчанию

    По поводу ускорений и торможений для блока ШД.
    Все эти расчёты, по идее, должны производится основным процессором ПЛК и таблица "команд" загружаться в ФБ ШД.
    Иначе PRU будет выполнять ненужную в цикле реального времени работу, что будет тормозить остальные процессы управления.
    Тролль-наседка, добрый, нежный и ласковый

  3. #83

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    По поводу ускорений и торможений для блока ШД.
    Все эти расчёты, по идее, должны производится основным процессором ПЛК и таблица "команд" загружаться в ФБ ШД.
    Иначе PRU будет выполнять ненужную в цикле реального времени работу, что будет тормозить остальные процессы управления.
    В буржуйских ПЛК в основной программе никаких расчетов по разгону и торможению делать не надо, все делает ФБ.
    Последний раз редактировалось Newcomer; 12.09.2016 в 18:17.

  4. #84

    По умолчанию

    Цитата Сообщение от Филоненко Владислав Посмотреть сообщение
    [I][B]Свежо предание, но:
    Писал Владимиру, напишу и тут. Почему мы резко против компиляции из "ST"
    Вот тут: http://www.owen.ru/forum/showthread....l=1#post219796 я развёрнуто рассказал, почему текущий инструментарий для создания ФБ PRU неудобен. Скажу честно, я не думал, что так скоро перейду к написанию компилятора и эмулятора процессора. Честное слово, считал, что для "нехитрого" блока ШД мне хватит мозгов написать на ассемблере. Оказалось, что просто глазами отлаживать тяжело. Более того ни в коде на ассемблере, ни в коде на ST никто ошибку не увидел. Всё-таки, без автоматических тестов никуда.


    Имеющийся подход не просто неудобен, а неудобен настолько, что мне проще сделать заново (у учётом того, что наработки по Hardella IDE уже были).

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

    Я просто говорю, что, в текущих реалиях, доработка Hardella IDE для компиляции ST -> PRU ASM оказывается быстрее, и надёжнее.

    И это не просто слова, а результат опыта.
    1) Я изучил инструмент. Не просто посмотрел одним глазом, а сделал вручную блок ШД на ассемблере. Делал в текстовом редакторе и попутно много общался с Владиславом в почте. Ещё раз подчеркну, что первая версия блока была написана на ассемблере с нуля (ну, под вдохновением ST кода).
    Разумеется, в инструментарии остались непонятные для меня места, но, полагаю, они предусмотрены для более сложных случаев.

    2) Потом я сделал компилятор ST->ASM в Harderlla IDE. Это не просто слова "будет проще сделать компилятор", а я его реально взял и сделал.

    3) Мой опыт разработки Hardella IDE говорит, что тяжело сделать редактор (как ST-подобный, так и графический), делающий так, чтобы для пользователя было удобно использовать имеющийся PRU инструментарий. Тут, конечно, можно остановиться и сказать, что "я не умею делать IDE", или, что "вместо доработки общего счастья я пытаюсь пропихнуть свою Hardella IDE", но ни то ни другое не выдерживает критики. Hardella IDE существует и работает, а альтернативных IDE на горизонте не видно.

    Касательно вопросов тестирования: в имеющемся инструментарии непонятно как именно тестировать финальную программу. "линкер (генератор prg)" на вход берёт бинарный код ФБ с метаинформацией и непонятно во что его превращает.
    Как при этом тестировать финальную программу -- вообще непонятно. Правильность расстановки "служебных комментариев" вообще никак нельзя узнать. Грубо говоря, забыл указать спец комментарий и всё, один и тот же регистр запросто может использоваться в разных блоках, приводя к самым удивительным последствиям, которые _невозможно_ увидеть, если тестировать блоки отдельно.

    В эмулятор сам файл PRU0.prg не загонишь, т.к. непонятен формат файла.
    Если у ОВЕН есть инструмент для автоматического тестирования PRU0.prg, что ж, хорошо, но со мной им не делились (надо сказать, я не спрашивал).

    Как раз для тестирования, эмулятор PRU процессора оказался весьма удобным.
    Он показал, что в моей исходной реализации блока была пара ошибок.
    Да, сейчас приходится запускать эмулятор отдельно от среды разработки ФБ, но даже и это поправимо. Можно будет прямо отлаживать ST код, выполняющийся на эмуляторе. Т.е. выполнять код в Hardella IDE "построчно" и смотреть переменные, при этом в фоне будет выполняться бинарный код в эмуляторе PRU.
    Обращу внимание, что это не потребует 100500 моих человеколет. В MPS (та среда, с помощью которой я делаю Hardella IDE) уже заложена возможность отладки. Т.е. да, разработка компилятора, отладчика и т.п. это непросто, но я и не предлагаю делать всё с нуля, а я предлагаю переиспользовать опыт MPS/Java. Тут и есть колоссальная экономия времени.


    PS Постарался изложить основные моменты. Всё остальное (константное время выполнения, надёжность тестов, сложность компилятора и т.п.) я не забыл, а специально не стал обсуждать, т.к. иначе дискуссия вообще не закончится.

    PPS. Да, слова "Также, что чрезвычайно важно, Ваш компилятор сейчас не генерирует код с константным временем исполнения (поправьте, если я ошибаюсь)." были написаны до того, как я показал результаты тестов блока ШД. Но, по факту, мой блок ШД, написанный на ST, выдаёт импульсы одинаковой длительности, и эта длительность совпадает с уставкой. Поэтому, давайте сначала всё-таки основное обсудим, а потом в детали пойдём?
    Последний раз редактировалось Владимир Ситников; 13.09.2016 в 00:29.

  5. #85

    По умолчанию

    Каков порядок действий после того, как vladimirisitnikov сделает ФБ для ШД. Т.е. что надо сделать чтобы обратиться к этому ФБ из основной программы ПЛК.

  6. #86

    По умолчанию

    Цитата Сообщение от Newcomer Посмотреть сообщение
    Каков порядок действий после того, как vladimirisitnikov сделает ФБ для ШД. Т.е. что надо сделать чтобы обратиться к этому ФБ из основной программы ПЛК.
    Предположу следующее. В PruAccessLib.lib (см 1-е сообщение этой темы) есть 2 функции:

    Код:
    FUNCTION PRU_FB_SetParameter : DINT
    VAR_INPUT
            pru_num:DWORD; (*from 0 to 1*)
            index:DWORD; (*from 2 to 31*)
            value: POINTER TO DWORD;
    END_VAR
    и

    Код:
    FUNCTION PRU_FB_GetParameter : DINT
    VAR_INPUT
            pru_num:DWORD; (*from 0 to 1*)
            index:DWORD; (*from 2 to 31*)
            value: POINTER TO DWORD;
    END_VAR
    Судя по названиям параметров и комментариям к ним, эти блоки напрямую позволяют читать/писать значения PRU регистров.

    Т.е. в основной программе вызываем PRU_FB_SetParameter и передаём параметры.

    Некий минус в том, что нужно обращаться к параметрам по индексам.

    Поэтому есть 2 варианта:
    1) Рабоче-крестьянский: в PRU программе использовать абстрактные "dword_in1, dword_in2, dword_out1, dword_out2" и в ПЛК программе следить за нумерацией этих параметров
    2) Прогрессивный: при компиляции PRU программы, автоматически генерировать EXP код, который передаёт IN/OUT параметры "как надо". Ну, автоматически генерировать КДС блок-обёртку, у которого номера уже не перепутаешь.



    PS. Есть даже ненулевая вероятность, что можно вызывать PRU_FB_GetParameter в 20мкс таймере (т.е. в отрыве от основного цикла ПЛК).
    Грубо говоря, если PRU_FB_GetParameter прямо берёт и обращается к памяти PRU в момент вызова, то можно даже наблюдать актуальные значения.

  7. #87

    По умолчанию

    Сложновато как-то.

  8. #88

    По умолчанию

    Да хоть как. Сейчас основная задача -- набрать политический вес. В хорошем смысле этого слова. Вот прямо реально нужно, чтобы тот, кому нужно (или потенциально нужно), пришёл и сказал, позвонил в ОВЕН, комментарий оставил в конце концов.

    Попробую ещё с одной стороны. Аргументы "вот фотография объекта, где ПЛК плачет по ШД", "таблетки не плющатся, ведь реакция нужна в 10мкс" были бы весьма хороши.

    Сейчас выглядит так, что "никому по факту не нужно, а я только занимаю время ведущих специалистов".
    Как раз нужно показывать проекты.

    Я совсем в другой области работаю, поэтому у меня вряд ли будут задачи по быстрому управлению и т.п.



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

    Цитата Сообщение от Newcomer Посмотреть сообщение
    Сложновато как-то.
    Переведу с русского на русский: если из Hardella IDE можно будет создавать PRU0.prg, то Hardella вместе с PRU0.prg сможет создать и КДС.exp с блоком, используемым в основной программе.

    Т.е.:
    1) Берём "программу ШД" (PRU0_программа_шд.prg), заливаем в PRU.
    2) Берём блок_шд_для_управления_pru.exp, импортируем
    3) Пользуемся как обычно

    Куда уж проще-то?

    Я, вот, считаю, что реально PRU блоки будут только по праздникам делать, и 99% запросов решатся набором готовых и протестированных PRU0.prg.

    Ах, да, проще, если совсем всё делать в Hardella IDE, но это уже другой вопрос.
    Последний раз редактировалось Владимир Ситников; 14.09.2016 в 13:06.

  9. #89

    По умолчанию

    Ваша Hardella IDE - это полноценная замена CoDeSys V2.3 или некая надстройка над ней ?

  10. #90

    По умолчанию

    Цитата Сообщение от Вольд Посмотреть сообщение
    Вы все делаете на голом энтузиазме или как-то оформили свои отношения с фирмой "ОВЕН" ?
    Сейчас это энтузиазм.

    Цитата Сообщение от Вольд Посмотреть сообщение
    Ваша Hardella IDE - это полноценная замена CoDeSys V2.3 или некая надстройка над ней ?
    Если говорить про ПЛК110 в обычном понимании, то Hardella это надстройка, которая генерирует *.exp (pou, plc configuration, и т.п.)
    Для того, чтобы заменить КДС, нужно чтобы кто-то написал Ethernet/TCP/RS-232/Modbus/GPIO/файловая система/task scheduler/simulation/on-line visualization и т.п. Грубо говоря, есть голое железо, и откуда-то должен взяться код, который обслуживает файловую систему.

    На мой взгляд, неправильно начинать с этого. Я уже говорил, что правильнее делать среду для чего-то попроще (ну, чтобы ей уже можно было пользоваться), а потом уже усложнять, если реально есть смысл.

    Если же говорить про PRU-программирование, то это полноценная замена. Сейчас можно рисовать PRU программы в КДС CFC, но после этого программу нужно выгрузить в *.exp формате, и прогнать через bat файл.
    В случае Hardella IDE ничего никуда прогонять не нужно, а ошибки показываются сразу по ходу написания.
    Последний раз редактировалось Владимир Ситников; 14.09.2016 в 11:36.

Страница 9 из 68 ПерваяПервая ... 78910111959 ... ПоследняяПоследняя

Похожие темы

  1. Ответов: 38
    Последнее сообщение: 24.01.2022, 11:56
  2. Ответов: 10
    Последнее сообщение: 11.06.2021, 14:55
  3. часы реального времени
    от vetaly в разделе ПЛК1хх
    Ответов: 4
    Последнее сообщение: 28.08.2015, 16:21
  4. Таймер реального времени УТ1-РiС
    от ser10 в разделе Трёп (Курилка)
    Ответов: 0
    Последнее сообщение: 16.09.2010, 12:24

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •