Совсем не гложит ничего ))) применяйте, я ж не запрещаю, но вы же просили оценку )))
Вид для печати
Совсем не гложит ничего ))) применяйте, я ж не запрещаю, но вы же просили оценку )))
Вполне возможно что для экономии времени. Ведь иногда приходится одновременно крутить две-четыре оси, считать несколько энкодеров, и не забывать о прерываниях по входам. Т.е. как будет Ваш FB сочетаться с другими подобными?
-------------
ИМХО, покрутить несколькими осями шаговиков можно и через rs232 и ардуину, причём даже с интерполяцией.
(Если думаете что ардуина не надёжна, спорте с секреткой в моей машине)
Вычисление рампы на частоте выхода 100кГц занимает примерно 2-3% времени PRU ядра. Всё остальное время процессор и делает, что "опрашивает входы".
В ПЛК110 М02 этих ядер два.
В этом самом ПЛК110 М02 быстрых выходов всего 4 штуки. И быстрых входа тоже всего 4.
Т.е. ресурсов хоть отбавляй. Наверняка можно управлять и 4мя ШД от текущего ПЛК110. По 2 ШД на ядро не является большой проблемой.
Ещё раз повторюсь: кроме отработки быстрых входов/выходов эти PRU ядра вообще ничем больше не занимаются.
Вот если бы ОВЕН распаяли все 60 быстрых выходов, которыми могут рулить PRU ядра, тогда совсем другой разговор был бы. А так как выходов всего 4 штуки, то не вижу смысла заморачиваться с оптимизацией чего бы то ни было.
Мы же не рассматриваем случай использования какого-нибудь мультиплексирования для того, чтобы по одному-двум проводам передавать команды на десяток ШД?
В ПЛК110 заявлена поддержка 100кГц. Поэтому, использование ПЛК110 как для простой автоматики, так и для управления ШД/энкодерами может вполне неплохо смотреться.
Конечно, сейчас ПЛК110 сам по себе не умеет управлять ШД. Т.е. если ШД нужен, то, возможно, и ПЛК110 в проекте не возникнет.
С другой стороны, если в ПЛК110 будет возможность управлять ШД, то это вполне может склонить чашу весов в пользу ПЛК110, т.к. для конечного пользователя снимется вопрос "как скрещивать, программировать и т.п. ардуину".
Про "использования ардуины в промышленности" меня спрашивать бесполезно, но лично я бы не стал делать смешанную "ПЛК110+ардуино" систему себе (в квартиру). Для меня ПЛК110 проще в установке/настройке, чем обвешивание конденсаторами и прочей хренью. Ну, реально. Я могу понять конденсаторы, но это не моё.
vladimirisitnikov я не пытаюсь Вас критиковать, скорее даю совет забить на правильность рампы и думать дальше.
Пытаюсь намекнуть что одной оси недостаточно.
вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.Цитата:
В этом самом ПЛК110 М02 быстрых выходов всего 4 штуки
Т.е. управление одним ШД, это только начало.
А если дойдёте до варианта со сменой скорости и координат "на лету" одновременно для двух осей?Цитата:
Вычисление рампы на частоте выхода 100кГц занимает примерно 2-3% времени PRU ядра. Всё остальное время процессор и делает, что "опрашивает входы".
Может Вы себе задачу не правильно поставили?
он не "нехороший" - он просто не отвечает концепции промышленного контроллера вообще и предложенному овеном формату, поэтому какой смысл в играх с этим "черным ящиком"? а для собственного применения у меня есть блоки
способ реализации остальных "небыстрых" выходов ПЛК110 у овена такой, что установленное значение появится на выводе с не прогнозируемой задержкой, достигающей в максимуме 50 мс, поэтому на DIR приходится расходовать "быстрый" выход. А реверсирование ШД в синхронном режиме возможно в следующем такте... ну да при разгонах конечно нужно понизить скорость. Кстати, при разгонах - "ступеньки" (т.е. несколько шагов на одной частоте) не имеют смысла - изменение производится с каждым шагом.Цитата:
вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.
Нее. Норм. Всё в точку было. На grbl и ардуиновскую библиотеку AccelStepper я натыкался когда изучал "имеющиеся работы в области ШД".
Просто вас в теме не видно было, и я предположил, что сообщение #293 (про графики cpu%) и т.п. могли просто не увидеть.
Да, про "забить на правильность рампы" я понял. На рампу я смотрел, скорее из чувства прекрасного. Ну и того, что, якобы, внезапное изменение ускорения плохо сказывается на исполнительных механизмах ( рывок(кинематика) и т.п. )
Графики дельтовской рампы делал как для того, чтобы самому получше понять "как там у них", так и для того, чтобы некоторые (не будем показывать пальцем) поняли, что в документации дельта действительно косяк.
Тут тоже в точку.
У меня ШД нет, и не особо предвидится. Поэтому постановка задачи оказалась "из того, что просили".
Просили "передвижение на указанное количество импульсов" -- сделал.
"Управление несколькими осями" / "изменение плана на ходу" я отдалённо понимаю, но:
1) Пока не просили
2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?
Я ещё могу понять случай "автоматического поиска крайних положений", но и там это должно быть не "внезапное изменение скорости", а "программа поиска крайнего положения" -- т.е. программа должна понимать "что она делает".
В общем, будет потребность -- могу сделать.
Зависит от. В том числе, и от ОВЕН. Одна из проблем -- компания ОВЕН не разрешает и не запрещает составление PRU программ (см #196).
Это какая-то печаль.
Своего не делают. Стороннее не разрешают.
На КДС сторонние программы делать разрешают, а для PRU сторонние программы делать не разрешают. Беда-печаль.
На всех применениях где имеется необходимость разгона ШД, ОБЯЗАТЕЛЬНО установлены маховик, для обеспечения необходимого момента инерции, а так же демпфирующее звено выполненное в виде регулируемого по усилию тормоза трения....Цитата:
Трение не может влиять на разгон. Подумайте и поймёте почему.
если ШД сорвался из режима синхронизации при разгоне - он будет стоять на месте а не выполнять редкие импульсы... обратная связь ставиться для определения этого а также для диагностики заклинивания механизма при синхронном вращенииЦитата:
что ШД выполняет лишь 10 шагов в секунду при условии, что на него идёт 10'000 импульсов в секнуду,
нет нисколько, просто интуиция подсказывает что где то что то идет не так
Например по поводу марсиан, так же решил построить график, результат на видео, он намного ближе к расчетам дельты, единственный вопрос к ним по поводу миллисекунд, вроде не там они знак поставили
Всё правильно пишете, но это как-то лишь подтверждает то, что "трение не может влиять на запланированный в программе график разгона"
Тут вы путаете ШД и серво. Если есть обратная связь, то это уже серво система. У простого ШД обратной связи нет, и если он пропускает импульсы, то никто никогда не заметит.
Дмитрий, можете поделиться примером хоть какого работающего файла PRU1.prg?
ПЛК в моём случае пишет такое:
И я не пойму. То ли в прошивке дело, то ли в PRU1.prgКод:Retain init
Slave Retain loaded
EEPROM init
PRU0 user programm loaded
Dublicate PRU programm
PRU1 user prg not loaded!
Там где нет жёсткой связи оси с перемещаемым материалом, металлическая полоса или пруток, перемещаемые валами.
На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.
Люфты и пропуски шагов, энкодер может это поправить.
Задачи вроде "летящего ножа" с корректировкой скорости по внешнему энкодеру на материале, который режем.
Зря.Цитата:
У меня ШД нет
Поиск не крайнего, а исходного положения, поиск нулевой точки для работы в абсолютных координатах.Цитата:
"автоматического поиска крайних положений"
т.е. шаговику в некоторых случаях отдают команду не на сколько переместиться, а КУДА переместиться.
Контроллер сам определяет направление и дистанцию, счётчик выхода доступен в программе.