Совсем не гложит ничего ))) применяйте, я ж не запрещаю, но вы же просили оценку )))
Совсем не гложит ничего ))) применяйте, я ж не запрещаю, но вы же просили оценку )))
Вполне возможно что для экономии времени. Ведь иногда приходится одновременно крутить две-четыре оси, считать несколько энкодеров, и не забывать о прерываниях по входам. Т.е. как будет Ваш 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 приходится расходовать "быстрый" выход. А реверсирование ШД в синхронном режиме возможно в следующем такте... ну да при разгонах конечно нужно понизить скорость. Кстати, при разгонах - "ступеньки" (т.е. несколько шагов на одной частоте) не имеют смысла - изменение производится с каждым шагом.вообще то почти достаточно для четырёх осей, на сигнал смены направления один фиг задержка для шаговика нужна, инерция однако.
Последний раз редактировалось Дмитрий Артюховский; 27.09.2016 в 20:17.
Нее. Норм. Всё в точку было. На grbl и ардуиновскую библиотеку AccelStepper я натыкался когда изучал "имеющиеся работы в области ШД".
Просто вас в теме не видно было, и я предположил, что сообщение #293 (про графики cpu%) и т.п. могли просто не увидеть.
Да, про "забить на правильность рампы" я понял. На рампу я смотрел, скорее из чувства прекрасного. Ну и того, что, якобы, внезапное изменение ускорения плохо сказывается на исполнительных механизмах ( рывок(кинематика) и т.п. )
Графики дельтовской рампы делал как для того, чтобы самому получше понять "как там у них", так и для того, чтобы некоторые (не будем показывать пальцем) поняли, что в документации дельта действительно косяк.
Тут тоже в точку.
У меня ШД нет, и не особо предвидится. Поэтому постановка задачи оказалась "из того, что просили".
Просили "передвижение на указанное количество импульсов" -- сделал.
"Управление несколькими осями" / "изменение плана на ходу" я отдалённо понимаю, но:
1) Пока не просили
2) Хорошо бы всё-таки видеть конкретный сценарий использования. Особенно непонятно каким образом программа поймёт, что пора менять скорость? Т.е. мы запланировали движение "на 5 см влево", а тут, фигак, и "нее, надо на 6 на самом деле было". Как так?
Я ещё могу понять случай "автоматического поиска крайних положений", но и там это должно быть не "внезапное изменение скорости", а "программа поиска крайнего положения" -- т.е. программа должна понимать "что она делает".
В общем, будет потребность -- могу сделать.
Зависит от. В том числе, и от ОВЕН. Одна из проблем -- компания ОВЕН не разрешает и не запрещает составление PRU программ (см #196).
Это какая-то печаль.
Своего не делают. Стороннее не разрешают.
На КДС сторонние программы делать разрешают, а для PRU сторонние программы делать не разрешают. Беда-печаль.
На всех применениях где имеется необходимость разгона ШД, ОБЯЗАТЕЛЬНО установлены маховик, для обеспечения необходимого момента инерции, а так же демпфирующее звено выполненное в виде регулируемого по усилию тормоза трения....Трение не может влиять на разгон. Подумайте и поймёте почему.
если ШД сорвался из режима синхронизации при разгоне - он будет стоять на месте а не выполнять редкие импульсы... обратная связь ставиться для определения этого а также для диагностики заклинивания механизма при синхронном вращениичто ШД выполняет лишь 10 шагов в секунду при условии, что на него идёт 10'000 импульсов в секнуду,
нет нисколько, просто интуиция подсказывает что где то что то идет не так
Например по поводу марсиан, так же решил построить график, результат на видео, он намного ближе к расчетам дельты, единственный вопрос к ним по поводу миллисекунд, вроде не там они знак поставили
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Всё правильно пишете, но это как-то лишь подтверждает то, что "трение не может влиять на запланированный в программе график разгона"
Тут вы путаете ШД и серво. Если есть обратная связь, то это уже серво система. У простого ШД обратной связи нет, и если он пропускает импульсы, то никто никогда не заметит.
Дмитрий, можете поделиться примером хоть какого работающего файла PRU1.prg?
ПЛК в моём случае пишет такое:
И я не пойму. То ли в прошивке дело, то ли в PRU1.prgКод:Retain init Slave Retain loaded EEPROM init PRU0 user programm loaded Dublicate PRU programm PRU1 user prg not loaded!
Там где нет жёсткой связи оси с перемещаемым материалом, металлическая полоса или пруток, перемещаемые валами.
На омроновском контроллере можно читать энкодер на полосе и много раз в секунду изменять конечную координату. Т.е. Компенсировать проскальзывания при перемещении и разгоне.
Люфты и пропуски шагов, энкодер может это поправить.
Задачи вроде "летящего ножа" с корректировкой скорости по внешнему энкодеру на материале, который режем.
Зря.У меня ШД нет
Поиск не крайнего, а исходного положения, поиск нулевой точки для работы в абсолютных координатах."автоматического поиска крайних положений"
т.е. шаговику в некоторых случаях отдают команду не на сколько переместиться, а КУДА переместиться.
Контроллер сам определяет направление и дистанцию, счётчик выхода доступен в программе.
Последний раз редактировалось BETEP; 28.09.2016 в 11:25.