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

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

Вот через pruaccesslib.lib и работает. Другим способом получить синхронизацию без остановки PRU и без неопределённого по времени доступа из PRU в основное ОЗУ (от десятков до тысяч тактов, если крайне не повезёт с моментом обмена) нельзя.

Но, конечно, всегда есть путь Илона Маска.

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

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

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

Шайтан. Это же вообще огонь-технология!
Если надо синхронность, то просто делаем WHILE COUNT_DUBL_POINT^ ... END_WHILE; и всего делов.

Может, ещё и структуру/массив можно разместить по адресу PRU_DRAM?
Если такое применить, то вообще огонь будет. Не то, чтобы "немного не по правилам", а "вообще не по правилам" )

Ну и нужно будет к Вольду обратиться. Он очень метко эпитеты подбирает.

[Newcomer]

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

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

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

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

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

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

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

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

[Вольд]

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

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

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

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

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

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

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

COUNT_DUBL_POINT := PRU_DRAM + OFFSET;
COUNT_DUBL_POINT^ := 16#01020304;

>>>>
LBCO &R28, CONST_PRUDRAM, 128, 4 // временно - считать 4 байта и положить в 28 рег дл_ тестирования проброса - работает
>>>>

понятно что не синхронно, но для некоторых применений прокатит...

Это крайне медленно и внутренняя шина может быть в этот момент занята обменом с чем-нибудь другим => непредсказуемая задержка.

[Вольд]

На текущий момент 4 (ЧЕТЫРЕ) человека вообще проявили какой-либо интерес к технологии и соизвоили хотя бы письмо мне написать, чтобы получить пакет тестировщика. Четыре, Карл!

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

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

Ну и я не понял мысль из поста 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 под предлогом "в логике работы замечена ошибка, мы перевели выходы в безопасное состояние".
Не хотелось бы играть с разработчиками ОВЕН в Бой в памяти