Hardella IDE

[Владимир Ситников]

а где лежат шаблоны создания экспортных файлов и есть ли возможность их править

Про какие шаблоны речь?
PRU шаблоны или "шаблон экспорта обычных ФБ/программ в exp"?

Зачем их менять?

Cделать-то можно (в том числе, можно менять шаблоны даже без перекомпиляции Hardella -- там расширяемость ого го какая). Но сложность составления шаблонов, конечно, повыше, чем сложность написания ST кода.
Поэтому я, скорее, не за возможность редактирования сырых шаблонов, а за расширение пользовательского интерфейса, чтобы можно было галочками или ещё как выбрать нужное.

Сами ФБ выгружаются "1 к одному" (ну, program выгружается как program). Чего там менять?
Описываются так (всё это можно прямо в Hardella открыть и посмотреть):
Снимок экрана 2016-12-28 в 12.34.33.png

Шаблоны выгрузки PRU программ описываются так:
Снимок экрана 2016-12-28 в 12.31.06.png

[capzap]

зачем менять вариантов на самом деле много, например формировать файлы для тиапортала,а не КДС или использовать директивы,не думаю что их работа как то учитывается в черепахе,а писать ручками в КДС, тогда зачем переходить на внешний редактор

[Владимир Ситников]

зачем менять вариантов на самом деле много, например формировать файлы для тиапортала

Так, может, и сделать поддержку этого самого tia portal'а?

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


Например, на добавление PRU ушло меньше месяца.
Из наиболее заметного -- для поддержки PRU в сам ST язык добавлены директивы, которыми обозначается приём-передача данных между "основным циклом ПЛК" и PRU сопроцессором. Уже из этих директив и собирается как сама PRU программа, так и ответная часть в КДС программе.

Обновление среды занимают меньше мегабайта. Проблем вообще не вижу.

Добавляем формат, выпускаем обновление и всего делов. Самое сложное -- формализовать какой именно формат реально нужен. Разумеется, я не предлагаю использовать Hardella вместо текстового редактора.

директивы,не думаю что их работа как то учитывается в черепахе

Если нужны, то их можно добавить в синтаксис черепахи. Либо прямо директивами (ну, чтобы не опечатываться), либо просто текстовое поле типа комментария (так, конечно, делать на порядок проще, но лучше уж по-нормальному делать, ведь директивы КДС без пол-литра не напишешь).

тогда зачем переходить на внешний редактор

Причины могут быть разные:
1) Проверка ошибок на ходу. Тут и банальное "несовпадение типов данных", так и более сложное. Например, "в case рассмотрены не все случаи enum'а", или "у двух веток IF одинаковое условие". Или "условие всегда ложно".

2) Hardella упрощает поддержку проекта (ту часть, когда идёт доработка, или выяснение "а почему тут так"). Навигация по коду, поиск использований, переименование переменных. В КДС переменную не переименуешь и т.п.
Поддержка git/svn. Можно прямо в среде посмотреть историю, посмотреть когда менялась конкретная строка и т.п.

3) Для PRU программирования, например, вообще альтернатив нет. Тут не стоит вопрос "зачем мне использовать Hardella, если есть CoDeSys". Выбора вообще нет. Либо Hardella, либо никак.

4) Расширяемость в конце концов. Ждать от КДС интеграцию с чем-либо вряд ли стоит. А тут можно сделать, и интеграция будет не из запуска 100500 утилит, а в общем редакторе.


Возможен как экспорт данных (например, разнообразные форматы выгрузки, списки переменных, ну фиг знает что нужно), так и импорт данных.

Например, был умелец, который предлагал программировать в Visio. Видели?

С одной стороны он говорит, что "КДС редактор не всегда удобен" (тут, наверное, можно его понять, иногда в visio можно "красивее" нарисовать), но с другой, я не считаю, что использование Visio как стороннего редактора жизнеспособно. По-моему, Visio это тупиковый путь. Оно решает какую-то одну узкую задачу, никак не помогает в других, и никак не расширяется.

В этом плане, у редактора на базе Hardella потенциал развития гораздо выше: без проблем можно добавлять и текстовые языки, и таблицы, и графику. Как пример, я могу загружать описания КДС таргетов и показывать их (дерево компонент, таблицы параметров и т.п.)

5) Возможно, когда-нибудь и без КДС можно будет работать. Про ОВЕН не будем загадывать, но, например, приборы МЗТА работают без КДС. У них свой runtime, и в ПЛК заливаются программы на C. Особых проблем генерировать C-код из Hardella нет (да и сам производитель с радостью рассказывает как оно устроено), и вполне можно замкнуть цикл. Т.е. разработка, заливка в ПЛК, online. Это, конечно, не дело ближайших месяцев, но почему бы и нет?

6) Автоматическое тестирование. Т.е. возможность указать "вот при таких входах должны быть такие значения на выходах". Так, чтобы во-первых программа реально работала так, как ожидается, а во-вторых, чтобы при доработках старое поведение не ломалось.

Сейчас и в КДС и в ОЛ для тестирования нужно "прощёлкивать" вручную. В Hardella же есть план как сделать автоматическое "прощёлкивание" и проверку значений.

[Sulfur]

Здесь пример "как обращаться из plc_prg"

Правильно ли я понимаю, что инициализацию PRU в PLC_PRG можно сделать так:

var
init:BOOL; (*Флаг инициализации*)
end_var

IF NOT init THEN
<<<вызов хххх_Pru0Init() и хххх_Pru1Init() с пустыми параметрами>>>
init:=TRUE;
END_IF;
<<<обращение к POU ххх_Pru0(1)MemoryTransfer с разными параметрами>>>

[Владимир Ситников]

Правильно ли я понимаю, что инициализацию PRU в PLC_PRG можно сделать так:

var
init:BOOL; (*Флаг инициализации*)
end_var

IF NOT init THEN
<<<вызов хххх_Pru0Init() и хххх_Pru1Init() с пустыми параметрами>>>
init:=TRUE;
END_IF;
<<<обращение к POU ххх_Pru0(1)MemoryTransfer с разными параметрами>>>

Да, так можно.

А можно и без if not init (внутри хххх_Pru0Init тоже есть аналогичная переменная).

Если точнее, то хххх_Pru0Init принимает аргумент enable:BOOL и по переднему фронту проводит сброс PRU ядра и заливку программы. Так можно менять PRU программы на ходу.

[Sulfur]

Владимир Ситников
Вопрос по ххх_Pru0(1)MemoryTransfer.
Могу ли я в основном проекте в начале PLC_PRG (в начале цикла) обратиться к ххх_Pru0(1)MemoryTransfer только с чтением переменных обмена (чтение из PRU), а в конце PLC_PRG (в конце цикла) к этой же ххх_Pru0(1)MemoryTransfer, но только к записи переменных обмена (запись в PRU)?
Или будет достаточно просто один раз прописать сопоставление переменным ххх_Pru0(1)MemoryTransfer с переменными PLC_PRG в начале цикла?

[Владимир Ситников]

Сейчас MemoryTransfer производит обмен всех переменных.
Потому вызывать MemoryTransfer нужно согласно купленным билетам, т.е. согласно тому, как необходимо по логике.

Просто стоит учитывать, что между вызовами MemoryTransfer (даже в рамках одного цилка ПЛК) PRU программа может успеть выполнить несколько итераций.

обратиться к ххх_Pru0(1)MemoryTransfer только с чтением переменных обмена (чтение из PRU), а в конце PLC_PRG (в конце цикла) к этой же ххх_Pru0(1)MemoryTransfer, но только к записи переменных обмена (запись в PRU)?

Да, так можно.
Фактически тут будет "запись тех же самых значений, что записывались ранее".
Вообще, мысль разделить чтение и запись интересная.

Если хотите, можно использовать такой синтаксис:

MemoryTransfer.motor_enable := TRUE;
MemoryTransfer.fast := TRUE;

MemoryTransfer(); (* собственно, обмен *)

motorState := MemoryTransfer.motorState; (* чтение *)

Или будет достаточно просто один раз прописать сопоставление переменным ххх_Pru0(1)MemoryTransfer с переменными PLC_PRG в начале цикла?

Зависит от того, какая логика нужна. Вызывать MemoryTransfer можно много раз внутри одного цикла ПЛК, и каждый раз можно получать "более новые" значения.

[Sulfur]

Зависит от того, какая логика нужна.

Логика простая - в начале цикла опрашиваем всё, что опрашивается, делаем вычисление, и пишем результаты во всё, что пишется. В данном случае фазы "опрашивается" и "пишется" объединены в одном модуле.

Просто стоит учитывать, что между вызовами MemoryTransfer (даже в рамках одного цилка ПЛК) PRU программа может успеть выполнить несколько итераций.

Я это понимаю. Именно из этих соображений критичные ко времени действия организованы в PRU-части. В ПЛЦ_ПРГ остается только "обслуга", либо медленные процессы\счетчики.

[Владимир Ситников]

Логика простая - в начале цикла опрашиваем всё, что опрашивается, делаем вычисление, и пишем результаты во всё, что пишется. В данном случае фазы "опрашивается" и "пишется" объединены в одном модуле.

Получается, если вместо одной текущей программы memorytransfer сделать две (для опроса и для записи), то будет понятнее?

В остальном работает?

[Newcomer]

Добрый день.

Зашел на сайт https://hardella.com/ и обнаружил, что подробности Крути ШД без забот (Узнать больше) изложены на английском.

Это какой-то косяк ?

Хочу попробовать использовать технологию PRU для работы с быстрыми входами/выходами ПЛК110[М02]. К первым двум быстрым входам подключен энкодер. К четырем быстрым выходам два драйвера ШД.

Теперь вопрос - есть ли готовая библиотека, разработанная посредством Hardella или надо скачивать, запускать Hardella и генерировать эти блоки.

Еще один вопрос - оставшиеся 2 быстрых входа можно будет как-то использовать.