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

[BETEP]

vladimirisitnikov я не пытаюсь Вас критиковать, скорее даю совет забить на правильность рампы и думать дальше.
Пытаюсь намекнуть что одной оси недостаточно.

В этом самом ПЛК110 М02 быстрых выходов всего 4 штуки

вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.

Т.е. управление одним ШД, это только начало.

Вычисление рампы на частоте выхода 100кГц занимает примерно 2-3% времени PRU ядра. Всё остальное время процессор и делает, что "опрашивает входы".

А если дойдёте до варианта со сменой скорости и координат "на лету" одновременно для двух осей?

Может Вы себе задачу не правильно поставили?

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

vladimirisitnikov я не пытаюсь Вас критиковать, скорее даю совет забить на правильность рампы и думать дальше.

Нее. Норм. Всё в точку было. На grbl и ардуиновскую библиотеку AccelStepper я натыкался когда изучал "имеющиеся работы в области ШД".
Просто вас в теме не видно было, и я предположил, что сообщение #293 (про графики cpu%) и т.п. могли просто не увидеть.

Да, про "забить на правильность рампы" я понял. На рампу я смотрел, скорее из чувства прекрасного. Ну и того, что, якобы, внезапное изменение ускорения плохо сказывается на исполнительных механизмах ( рывок(кинематика) и т.п. )

Графики дельтовской рампы делал как для того, чтобы самому получше понять "как там у них", так и для того, чтобы некоторые (не будем показывать пальцем) поняли, что в документации дельта действительно косяк.

Может Вы себе задачу не правильно поставили?

Тут тоже в точку.
У меня ШД нет, и не особо предвидится. Поэтому постановка задачи оказалась "из того, что просили".
Просили "передвижение на указанное количество импульсов" -- сделал.

"Управление несколькими осями" / "изменение плана на ходу" я отдалённо понимаю, но:
1) Пока не просили
2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?

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

В общем, будет потребность -- могу сделать.

Т.е. управление одним ШД, это только начало.
А если дойдёте до варианта со сменой скорости и координат "на лету" одновременно для двух осей?

Зависит от. В том числе, и от ОВЕН. Одна из проблем -- компания ОВЕН не разрешает и не запрещает составление PRU программ (см #196).
Это какая-то печаль.
Своего не делают. Стороннее не разрешают.

На КДС сторонние программы делать разрешают, а для PRU сторонние программы делать не разрешают. Беда-печаль.

[BETEP]

2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?

Там где нет жёсткой связи оси с перемещаемым материалом, металлическая полоса или пруток, перемещаемые валами.
На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.

Люфты и пропуски шагов, энкодер может это поправить.

Задачи вроде "летящего ножа" с корректировкой скорости по внешнему энкодеру на материале, который режем.

У меня ШД нет

Зря.

"автоматического поиска крайних положений"

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

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

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

Да, логично.

На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.

Т.е. мы заводим шарманку "переместить на 10 метров", потом по ходу видим, что "было проскальзывание на 0.5м" и правим программу "на самом деле, нужно 10.5м" чтобы в итоге полоса-таки на 10 переместилась?

Да, выглядит забавным.