Странные шестерни, прогу бы или плагин

[Семён]

Передаточное число наверное будет пропорциональна площадям фигур, приведенных к площадям окружностей. Т.е вычисляем площадь фигур, приводим в эквивалентные площади окружностей, вычисляем периметр приведенных окружностей и передаточное число. Таким образом можно вычислить и элементарные пути, скорости и ускорения в периоде оборота.
Можно ведь нарисовать второй контур зубьев (на мастер контуре) и вписать в него любые зубья с неотрицательными углами. После этого на втором контуре отобразить по пятнам контакта ответные зубья.

[Nick]

А что делать если в ведущей шестеренке будет большое углубление, которое не будет участвовать в зацеплении, но будет влиять на площадь?

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

[Семён]

Ситуация с отсутствием зацепления подразумевает отсутствие зубьев у обеих шестеренок, так что условие на межцентровое равенство все равно должно выполняться, иначе систему заклинит.
Формализовать можно только получение второй шестерни по заданной. А первая это уже дело фантазии.
Да и формализовать особо ничего не надо. Просто вращать вектор радиуса по линии межцентровой прямой и определять точку контакта на второй шестерне.

[MrPG]

т.к. иначе придется долго подбирать это расстояние, чтобы получить хотя бы более менее сходящиеся циклы.

Не-а, не придется Мы же _принудительно_ провернем ведомую шестеренку на нужное количество оборотов. Но при этом внутри этого поворота углы между соседними копиями ведущей будут пропорциональны локальным радиусам. То есть, если мы промазали по расстоянию между центрами - это не фатально, просто получится "примерно как сейчас" - слишком далеко торчащие выступы начнут описывать круглые выемки в теле второй шестерни. А это не особо страшно. Да, если получится радиус уточнять как-то в коде - конечно, результат станет лучше. Но и без этого - на глаз - должно быть достаточно хорошо.

[Nick]

.....Блин, третий день об этом думаю, но никак все в мозг не укладывается .

Сейчас все выгдялит так:
Перемещаем ведущую шестеренку по окружности, и поворачиваем ее на нужный угол. Шаг перемещения и угол - равномерны на всем протяжении.

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

[MrPG]

(огорченно) Я же 17 Mar 2011, 04:18 привел вполне разумное описание простенького алгоритма. Именно для того, чтобы все сошлось Если что-то криво описал - готов пояснить.

[Nick]

Теперь более менее начал понимать...

А оптимизировать будем начальную скорость вращения?

[Семён]

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

Да, похоже на то. Наверное надо определять период , а это подразумевает только целочисленные коэффициенты передачи.

[Nick]

Не обязательно, будем оптимизировать стремление к заданной величине, как и сейчас.

[Nick]

Я тут вот что придумал: нам даже оптимизировать ничего не придется.
Сначала делаем все также, как и в равномерном перемещении, но смещаем на величину зависящую от радиуса. Потом смотрим сумму перемещений и из нее впрямую находим нужный коэффициент:

во формула:

CodeCogsEqn.png (1.13 КБ) 3444 просмотра

(для просмотра содержимого нажмите на ссылку)

L = 2\pi \sum_{i} l_i \newline\newline

k = D*2pi/L

Завтра попробую реализовать .

[MrPG]

Гм... А точно не надо оптимизировать? Ведь при изменении коэффициента все углы изменятся, попадут (внимание!) в другие радиусы, и сумма новых углов уже не обязательно сойдется, вроде...

[Nick]

Хмммм сделал....

Но все равно в ведомой шестеренке "фасолевость" наблюдается, хотя, уже заметно меньше.

Наверное не правильно рассчитываю коэффициент:

1. Находим на ведущей шестеренке ближайшую точку к центру ведомой (P).
2. Коэффициент отношения скоростей вращения беру равным k= r2/r1.

Вот код самого расширения. Для включения неравномерного вращения нужно поставить Turning speed depends on local radius.

PS в конце работы выдает значение параметра K. В идеальном случае K должен быть равен 1.

[MrPG]

Я что-то, похоже, не так делаю - но сколько ни пытался, вообще ничего хорошего не получается
Открываю Inkscape 0.48, рисую в левом нижнем углу пустого листа вертикальный эллипс. Ставлю ему размеры 70*140 px. Запускаю Unordinary gears, на второй вкладке ввожу: 1, 1, 100, 105, ставлю галку Turning speed depends on local radius, и Units - px. 105 - это половина от горизонтальной оси (70/2=35) + половина от вертикальной (140/2=70). Жму apply - получаю коэффициент 0.913460894688 и картинку, где оно вращается в начале супер-быстро, а движется супер-медленно (что похоже на правду - но слишком сильно, вроде: видно начало рисования "почти горизонтального эллипса", но явно заваленного). И непонятно, что происходит в конце - вроде, эллипс приходит в исходную точку не в той же ориентации, которая ожидалась (вертикально), а наоборот - горизонтально. Ощущение, что где-то что-то считается не из 360 градусов, а из какого-то другого угла Я насчитал то ли 7, то ли 8 поворотов исходной шестерни на 90 градусов - а их, вроде бы, не должно быть больше 4... Один оборот - в один оборот задан...
При попытке задать 2:1 видно, что моя шестеренка облетает круг дважды - еще страннее

[Nick]

Там может быть небольшая проблемка с трансформациями. Иногда, когда двигаешь поворачиваешь или изменяешь размер контура, эти изменения к контуру не применяются, а вместо этого изменяется параметр transform - матрица аффинного преобразования.
А расширение берет за основу контур без трансформаций...
В общем, пока я это не исправил лучше экспериментировать с только что отрисованными контурами.

И на всякий случай скинь svg, может там еще какой глюк есть ...

[MrPG]

Да, очень похоже, что проблема именно в этом. И это очень здорово. Попробовал не менять размеры - просто от руки сделать эллипс похожих на правду размеров - и реально очень неплохо выходит, хотя и чуток фасолево по непонятной причине. Попробовал взять квадрат, и на нем вытянуть "зубцы" разного размера и формы штуки по три-четыре на сторону - и да, невероятно мощно улучшается результат. Оно, собственно, начинает всерьез зацепляться, в отличие от предыдущего, и более того - шестеренки начинают становиться очень похожими по форме зубцов друг на друга (раньше ведомая была вся из характерных "круглых вмятин"). K в районе "разумно выглядящих" расстояний и зацеплений для таких зубастых квадратов получается где-то 0.75-0.85.

Оптимизировать все-таки, вероятно, надо - как уже написал, похоже, что из-за движения радиусов по сложному профилю шестеренки сумма меняется довольно сильно, и вполне может не соответствовать в итоге нужному значению.

И да - оно настолько лучше по виду (еще не резал, но и так видно), что уже явно имеет смысл подумать на тему поиска оптимального расстояния между центрами И по дефолту, наверное, начинать его придумывать надо тупо со среднего радиуса ведущей шестеренки (либо посчитанного по равномерным углам, либо уже с учетом неравномерности поворота). Дальше мы ее признаем "якобы круглой", и считаем потребный по передаточному отношению радиус второй шестерни, опять же, из предположения, что она "тоже круглая". То есть цель простейшая - размазать ошибки и проскальзывания примерно поровну на обе шестерни, без серьезной оптимизации этого дела. А дальше вот этот, уже написанный, алгоритм даст результат, вполне достаточный по качеству. Для самых сложных случаев - на грани разумного - оставить человеку возможность менять это самое расстояние.

[Nick]

Да, я думаю нужно поставить checkbox на включение оптимизации.

Попробую сегодня сделать и разобраться с трансформациями.

[Nick]

Сделал автоматический поиск оптимального расстояния.
Правда работает не быстро, т.к. рассчетов много. У меня шестеренку из 355 узлов с 400 копиями считал около 4 минут...

Вот результаты, слева с изменяемой скоростью и автоматическим вычислением растояния между центрами шестеренок, справа с тем же расстоянием, но с постоянной угловой скоростью:

И, соответственно, само расширение:

[Nick]

Сделал генерацию рейки для шестеренки. Для нее пока нет неравномерного движения, из локальных радиусов. Но основная задача - делать рейки для нормальных, равномерных шестеренок.

Чтобы сделать рейку выбираем Linear Gear и задаем количество оборотов.
Внимание, если количество оборотов большое, то лучше сначала сделать небольшой кусок рейки и затем его размножить. Если создавать всю рейку стразу, Inkscape может начать тормозить из-за большого количества объектов, которое равно (количество копий)*(количество оборотов).

Вот пример создания рейки для шестеренки из подшипников:

А вот и само расширение:

[Nick]

Оформил красивую шапку : http://cnc-club.ru/forum/viewtopic.php?f=15&t=287

[Unikus]

Ага,Колюня,то что надо !!! Если бы ещё небольшой мануальчик по построению...Кстати,было бы очень неплохо для народа юзающего Инкскейп,сделать мануалы по расширениям.Или может я не нашёл здесь?