Comments 12
Так разработчик для веба нужен или нет?!
У меня был опыт работы с роботами-перекладчиками ABB на базе контроллера IRC5. Принципы программирования там такие же. Хотелось бы подробностей о том, какой софт используется для программирования робота оффлайн, скриншоты с пульта управления роботом, на базе чего построен контроллер (x86, arm), какая ОСРВ внутри, какие интерфейсы имеет робот (profibus, modbus, device net, can), какие функциональные модули имеются (перекладчик, сварщик, сборщик, укладка на паллеты мешков и т.д.). Или же специальных интерфейсов, в зависимости от выполняемых функций, роботы fanuc не имеют?
Я думаю, что такой принцип программирования (по точкам) у многих промышленных роботов, по крайней мере ещё у Kuka и ряда китайских производителей точно, если вообще не у всех.
Подробно рассказать, что внутри у робота не могу, т.к. банально не знаю. Fanuc раскрывает информацию преимущественно только на платных фирменных курсах, причем курсы программирования отдельно, электроники отдельно, механики отдельно и т.д. Могу рассказать лишь о том, с чем сталкивался сам: ОСРВ в контроллере у них какая-то своя, а в пульте Windows CE.
Я уверен, что практически все популярные интерфейсы должны поддерживаться, modbus есть точно (робот из примера в статье общался с внешним контроллером именно по нему).
Функциональные модули тоже есть, модуль перекладчика вроде бы является базовым, есть модуль сварщика, причем под сварку выделена отдельная серия роботов Arc Mate. Удалось пощупать одного такого при интеграции его с RCML в задачах «3д-печати» металлом.
Подробно рассказать, что внутри у робота не могу, т.к. банально не знаю. Fanuc раскрывает информацию преимущественно только на платных фирменных курсах, причем курсы программирования отдельно, электроники отдельно, механики отдельно и т.д. Могу рассказать лишь о том, с чем сталкивался сам: ОСРВ в контроллере у них какая-то своя, а в пульте Windows CE.
Я уверен, что практически все популярные интерфейсы должны поддерживаться, modbus есть точно (робот из примера в статье общался с внешним контроллером именно по нему).
Функциональные модули тоже есть, модуль перекладчика вроде бы является базовым, есть модуль сварщика, причем под сварку выделена отдельная серия роботов Arc Mate. Удалось пощупать одного такого при интеграции его с RCML в задачах «3д-печати» металлом.
Зачётное упражнение, вот только шрифт не очень красивый получился.
Имеет смысл взять какой-нибудь готовый Single Line шрифт и генерить chars.rcml автоматом (его, как я понял, вы терпеливо вручную делали).
Есть готовые программки типа StickFont, ну а распарсить G код и перевести его в относительные перемещения — там уже дело техники.
Имеет смысл взять какой-нибудь готовый Single Line шрифт и генерить chars.rcml автоматом (его, как я понял, вы терпеливо вручную делали).
Есть готовые программки типа StickFont, ну а распарсить G код и перевести его в относительные перемещения — там уже дело техники.
Шрифт действительно сделан вручную, и видно даже на видео, что все символы только из прямых линий.
Это результат обхода одного подводного камня… чтобы сделать плавную кривую или просто дугу можно пойти двумя путями:
1. Составить изгиб линии из множества маленьких прямых линий, понемногу поворачивая каждую. В этом случае, при рисовании, робот будет выполнять очень большое количество циклов разгона и торможения (до полной остановки) двигателей, что есть полноценный приход в каждую точку по заданным координатам. Причем робот крутит всеми осями, включая первую — самую нагруженную и самую медлительную, в основании робота (видно на видео, что робот чуть-чуть поворачивается целиком почти в каждом перемещении, что есть результат перемещения по первой оси). Это долго по времени, а если добавить роботу скорости, то будет ещё и дорого из-за износа (резкое ускорение и резкое торможение). Тут казалось бы можно применить инструкцию CNT для сглаживания, однако на момент записи видео проблема с CNT уже была, а решения ещё не было.
2. Можно передать роботу сразу инструкцию по рисованию дуги. Однако в этом случае робот очень часто выбрасывал ошибку, что не может выдержать заданную ориентацию инструмента. Робот не знает, что вращение его инструмента по оси Z не приводит изменению его (инструмента) ориентации, т.е. пришлось бы для каждой точки точки ещё явно высчитывать такую ориентацию маркера, при которой робот бы смог в прийти в требуемую. Это возможно и даже очень интересно реализовать, но не было столько времени на демонстрационный пример.
За идею со StickFont и G-код спасибо, возьму на вооружение.
Это результат обхода одного подводного камня… чтобы сделать плавную кривую или просто дугу можно пойти двумя путями:
1. Составить изгиб линии из множества маленьких прямых линий, понемногу поворачивая каждую. В этом случае, при рисовании, робот будет выполнять очень большое количество циклов разгона и торможения (до полной остановки) двигателей, что есть полноценный приход в каждую точку по заданным координатам. Причем робот крутит всеми осями, включая первую — самую нагруженную и самую медлительную, в основании робота (видно на видео, что робот чуть-чуть поворачивается целиком почти в каждом перемещении, что есть результат перемещения по первой оси). Это долго по времени, а если добавить роботу скорости, то будет ещё и дорого из-за износа (резкое ускорение и резкое торможение). Тут казалось бы можно применить инструкцию CNT для сглаживания, однако на момент записи видео проблема с CNT уже была, а решения ещё не было.
2. Можно передать роботу сразу инструкцию по рисованию дуги. Однако в этом случае робот очень часто выбрасывал ошибку, что не может выдержать заданную ориентацию инструмента. Робот не знает, что вращение его инструмента по оси Z не приводит изменению его (инструмента) ориентации, т.е. пришлось бы для каждой точки точки ещё явно высчитывать такую ориентацию маркера, при которой робот бы смог в прийти в требуемую. Это возможно и даже очень интересно реализовать, но не было столько времени на демонстрационный пример.
За идею со StickFont и G-код спасибо, возьму на вооружение.
draw_();
draw_();
draw_();
draw_();
draw_();
Полезная утилита. Вы планируете ее использовать для компиляции задач на уровне оператора, то есть набил текст, скомпилировал rcml — запустил робота на повтор одного задания, или для полной автоматизации, с возможностью автоматически задавать новый текст на каждый цикл работы робота?
Проблема параллельного исполнения нескольких задач должна неплохо решаться, если переключать робота только в тот момент, когда rcml программа явно завершила свою работу. То есть non-preemptive многозадачность.
P.S. Я бы еще добавил проверки на выход за границы рабочей области в питон скрипте.
Проблема параллельного исполнения нескольких задач должна неплохо решаться, если переключать робота только в тот момент, когда rcml программа явно завершила свою работу. То есть non-preemptive многозадачность.
P.S. Я бы еще добавил проверки на выход за границы рабочей области в питон скрипте.
Оба варианта возможны, однако второй более вероятен.
Параллельное исполнение возможно и средствами rcml, если бы мы написали код отрисовки каждой буквы не так:
А вот так:
И в самой rcml программе у нас был бы описан ещё какой нибудь процесс, то интерпретатор rcml, смог бы переключать робота после отрисовки каждого отдельного символа, и возвращать его (робота) в то же место программы отрисовки, не дожидаясь, для переключения, выполнения всей программы.
Я общался с разработчиками rcml, они обещают через два или три месяца реализовать функционал, по поддержке полноценного параллельного выполнения программ, о котором говорится в статье. Однако программистам на rcml придется явно указываться места, в которых робот может быть «изъят» из одной программы и направлен на выполнение другой программы.
Параллельное исполнение возможно и средствами rcml, если бы мы написали код отрисовки каждой буквы не так:
@fr = robot_fanuc;
@fr->draw_P(1, 0);
А вот так:
robot_fanuc->draw_P(1, 0);
И в самой rcml программе у нас был бы описан ещё какой нибудь процесс, то интерпретатор rcml, смог бы переключать робота после отрисовки каждого отдельного символа, и возвращать его (робота) в то же место программы отрисовки, не дожидаясь, для переключения, выполнения всей программы.
Я общался с разработчиками rcml, они обещают через два или три месяца реализовать функционал, по поддержке полноценного параллельного выполнения программ, о котором говорится в статье. Однако программистам на rcml придется явно указываться места, в которых робот может быть «изъят» из одной программы и направлен на выполнение другой программы.
Все это похоже на решение проблем которые решались в процессе написания Marlin (работа с кривыми налету, умный разгон-торможение и тд)
Ну, справедливости ради, у R30i можно писать движение до точки со смещением, таким образом определяя для буквы базовую точку и обрисовывая остальные линии со смещением к базовой. Это на случай, если нам потребуется поменять расстояние между буквами, например :)
Плюс, насколько я помню, можно писать макросы, создав для каждой буквы макрос, в котором мы определим набор действий для рисования конкретной буквы.
Но все равно, это уже из раздела ненормальное программирование, даже с учетом специфики :)
Плюс, насколько я помню, можно писать макросы, создав для каждой буквы макрос, в котором мы определим набор действий для рисования конкретной буквы.
Но все равно, это уже из раздела ненормальное программирование, даже с учетом специфики :)
Я полностью согласен с Вами, но только в том конкретном аспекте, который Вы описываете относительно смещения. R30i это имеет такой функционал и если у нас все буквы всегда неизменны по размерам, то да, может быть в таком случае внешний софт не потребуется.
Да смещение реализовать можно, но как подобный механизм применим когда нам надо изменить размеры и соотношение сторон букв? Поскольку тут уже смещение всех точек буквы (или всех точек внутри макроса) не на одну и туже величину по каждой из осей формирующих плоскость. Функция просчета смещений тут уже не поможет.
И сразу же возникает ещё один вопрос: если мы пишем каждый раз разные надписи, то получается нам придется каждый раз лезть внутрь робота, чтобы задать там программу вызова макросов, так? Либо как вариант можно повесить каждый отдельный макрос на PNS программу, однако механизм старта каждой PNS программы будет требовать почти 1 секунду времени, в итоге получим задержку в сумме равную количеству букв.
В этом случае применение макросов будет более затратно по времени, даже если все буквы неизменны.
Предложенное же решение в более общем виде позволяет нам оперировать большим числом параметров, что дает гибкость при написании очередной конкретной надписи. Например: мы можем в одном сообщении писать буквы разных размеров и с разным соотношением сторон.
Да смещение реализовать можно, но как подобный механизм применим когда нам надо изменить размеры и соотношение сторон букв? Поскольку тут уже смещение всех точек буквы (или всех точек внутри макроса) не на одну и туже величину по каждой из осей формирующих плоскость. Функция просчета смещений тут уже не поможет.
И сразу же возникает ещё один вопрос: если мы пишем каждый раз разные надписи, то получается нам придется каждый раз лезть внутрь робота, чтобы задать там программу вызова макросов, так? Либо как вариант можно повесить каждый отдельный макрос на PNS программу, однако механизм старта каждой PNS программы будет требовать почти 1 секунду времени, в итоге получим задержку в сумме равную количеству букв.
В этом случае применение макросов будет более затратно по времени, даже если все буквы неизменны.
Предложенное же решение в более общем виде позволяет нам оперировать большим числом параметров, что дает гибкость при написании очередной конкретной надписи. Например: мы можем в одном сообщении писать буквы разных размеров и с разным соотношением сторон.
Sign up to leave a comment.
Runtime программирование промышленного робота на RCML