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

[Дмитрий Артюховский]

Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".

Если PRU*.prg не залиты, то входы-выходы работают как обычно.
Если PRU*.prg залиты, то входы-выходы работают согласно залитой программе. В текущей моей "программе ШД" входы никак не обрабатываются, поэтому Дима и пишет, что "перестают работать входы".


Другое дело, что всем нужно одновременно и ШД крутить, и со входов информацию получать.
Для этого есть 2 варианта:
1) Звонить в ОВЕН
2) Просить меня, чтобы расширить "программу ШД" и добавить туда какую-нибудь обработку входов

ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))

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

ну или делать на совместимость с блоками овена - тогда любой может нарисовать нужную ему картинку )))

Во-первых, я уже писал почему это сделать невозможно.

А во вторых, ещё причина: блоки ОВЕН поддерживают _только_ байтовые входы-выходы. Хотите WORD/DWORD -- уже никак.
И как с этим работать?

[Филоненко Владислав]

Во-первых, я уже писал почему это сделать невозможно.

А во вторых, ещё причина: блоки ОВЕН поддерживают _только_ байтовые входы-выходы. Хотите WORD/DWORD -- уже никак.
И как с этим работать?

Это не так. Вам ли, как имеющему расширенный пакет с исходниками ФБ это не знать.
Конкретная реализация библиотеки сейчас имеет только байтовый I/O.
Полноценный редактор будет иметь полиморфизм I/O (выбор типа по необходимости)

[capzap]

Тем, что в "конфигуратор" быстрые входы попадают через "программу PRU по умолчанию".

на скрине и со слов автора скрина влияние программа ПРУ оказывает и на два обычных входа или же четыре входа, четыре выхода, не зависимо от того какой у них тип

[Newcomer]

Тут было сообщение, что при заливке ФБ для управления ШД в PRU перестают работать 2 быстрых и 2 обычных дискретных входа ПЛК110[М02]. Это косяк, который будет исправлен или все так и останется ?

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

Тут было сообщение, что при заливке ФБ для управления ШД в PRU перестают работать 2 быстрых и 2 обычных дискретных входа ПЛК110[М02]. Это косяк, который будет исправлен или все так и останется ?

Основной вопрос -- "останется ли вообще хоть что-нибудь от PRU0.prg".

[Дмитрий Артюховский]

Господа из фирмы "ОВЕН" ведут себя как-то по детски - удаляют посты на злобу дня, упорно игнорируют свершившиеся факты.

Повторю вопрос к В.Филоненко и К. Какова дальнейшая судьба ФБ для управления ШД и сервомотором, разработанного В.Ситниковым, которому (ФБ) на сегодня нет альтернативы ? Я думаю, форум будет удовлетворен если представители "ОВЕН" публично возьмут на себя обязательства не строить козни и не препятствовать использованию этого ФБ.

а кто вам мешает его использовать? ... вот только вопросов не задавайте овеновцам почему с этим блоком у нас не работает то-то и то-то и вообще контроллер чудит )))
Сторонние разработчики, скажем за сертификат "windows compatible" денег платят, ну а второй способ распространения - выкладывание открытого кода.... ну и напомню, что блок Ситникова не соответствует концепции ПЛК (в принципе, а не только овеновским хотелкам) на стабильное время цикла выполнения...
кстати! ничто в этом мире не мешает нашему уважаемому разработчику переписать блок на соответствие стандартам овена и тогда я не вижу никаких проблем с включением данного блока в библиотеку, распространяемую овеном )))

[Вольд]

а кто вам мешает его использовать?

Спецы из "ОВЕН" могут сделать так, что этот ФБ в один прекрасный, нет ужасный, день перестанет загружаться в PRU. Читай пост #456.

[Дмитрий Артюховский]

Спецы из "ОВЕН" могут сделать так, что этот ФБ в один прекрасный, нет ужасный, день перестанет загружаться в PRU. Читай пост #456.

Для этого они должны будут закрыть этот проект в принципе, и кстати, поменять процессор, переразвести плату и пр. )))) потому что если этот чип останется в составе ПЛК - никто не может помешать загрузить свою программу в ПРУ и выполнить ее )))) Понятно что нужно выбирать либо функции конфигуратора - либо самописные решения.

Ну и я не понял мысль из поста 456.

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

Ну и я не понял мысль из поста 456.

Мысль была всё-таки про цивилизованные методы. Если честно, я и не думал, что настолько просто стенки поднимаются.
Честное слово, мыслил исключительно в добропорядочном направлении, поэтому и долбился как баран в стенку PRUx.prg и pruAccessLib.lib.

Расшифрую: сейчас всё держится на том факте, что прошивка ПЛК110 загружает PRU0.prg и PRU1.prg файлы, если считает их "правильно оформленными".
Предстоит, например, Newcomer'у проект с ШД. У него есть выбор: PRU0.prg или ардуино/дельта/далее по списку.

Если он сейчас в проект заложит, что "управлять ШД будет через PRU0.prg", а через полгода ОВЕН обновит прошивку ПЛК и перестанет загружать файл PRU0.prg, то управление ШД у Newcomer'а накроется веткой сакуры.

Тут не вопрос того, чтобы ОВЕН кровью подписались, что никогда ни при каких условиях PRU0.prg не сломается. Разумеется, таких подписей никто не требует.
Вопрос в том, могут ли они публично заявить, что специально ломать поддержку PRU0.prg программ не будут.

никто не может помешать загрузить свою программу в ПРУ и выполнить ее ))))

Если имеется ввиду подход "остановить PRU, залить новую программу через 0x01C3, запустить", это, конечно, интересно, и даже может работать первое время.
И, похоже, этот подход может даже обойти ограничение 2048 байт в PRU0.prg.

Но, повторюсь, может выйти обновление HOST прошивки, которое станет периодически проверять "содержимое PRU instruction ram", и, если увидит "вражескую программу", то остановит PRU под предлогом "в логике работы замечена ошибка, мы перевели выходы в безопасное состояние".
Не хотелось бы играть с разработчиками ОВЕН в Бой в памяти