cnc-club.ru

michael-yurov писал(а): ↑ добавлю возможность переопределить настройки для ручных перемещений, и/или для G0

А что ,G1 не может двигаться со скоростью G0? Тогда при большем ускорении для G1 может быть затык.

Эксперимент с разгоном и антиразгоном на малом андронном измельчителе провел. Величина антиразгона в 1.8 раза выше, чем антиторможения. Не так много, как я ожидал.
Подопытная ось швп 2505 была дополнительно нагружена маховиком диаметра 90мм на 30толщины. Эквивалент линейной массы под тонну

В s разгоне не понимаю зачем нужен нижний прогиб. К верхнему вопросов нет

vtgmfg писал(а): ↑ для щупа возможно нужно уметь задавать ускорения исходя из того что за щуп

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

vtgmfg писал(а): ↑ ну это как раз от алгоритма зависит - он же может видеть ситуацию что там впереди.

При сохранении одной и той же скорости обработки это будет всегдатак как гипотенуза постоянна ,то уменьшив один катет другой всегда увеличивается.

Mamont писал(а): ↑ Эксперимент с разгоном и антиразгоном на малом андронном измельчителе провел. Величина антиразгона в 1.8 раза выше, чем антиторможения. Не так много, как я ожидал.

Чем управляется? Что за контроллер?

Mamont писал(а): ↑ В s разгоне не понимаю зачем нужен нижний прогиб. К верхнему вопросов нет

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

michael-yurov писал(а): ↑31 янв 2024, 20:33

Mamont писал(а): ↑ Эксперимент с разгоном и антиразгоном на малом андронном измельчителе провел. Величина антиразгона в 1.8 раза выше, чем антиторможения. Не так много, как я ожидал.

Чем управляется? Что за контроллер?

Mamont писал(а): ↑ В s разгоне не понимаю зачем нужен нижний прогиб. К верхнему вопросов нет

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

Управление от мач3, лпт.
Про снижение нагрузки я понимаю. Но на мой взгляд не обязательно. Если конечно это не подвижный стол электронного микроскопа.
Верхний загиб кривой разгона как раз и даст возможность выжать больше с приводов. В вначале более резкие разгоны, и выполаживание вконце

Mamont писал(а): ↑Эксперимент с разгоном и антиразгоном на малом андронном измельчителе провел. Величина антиразгона в 1.8 раза выше, чем антиторможения.

Mamont писал(а): ↑Управление от мач3, лпт.

В нем и причина. Если бы mach3 генерировал чистый сигнал, разницы в разгоне и замедлении не было бы.
Установка СтепМастера позволяет повысить ускорение в 2 - 4 раза, и при этом получить заметно большую стабильность в работе.

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

Про ступенчатый разгон в маче, я в курсе. Про фризы, их не замечал на осцилографе

michael-yurov писал(а): ↑ Чтобы поставить свой логотип?

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

Mamont писал(а): ↑ Верхний загиб кривой разгона как раз и даст возможность выжать больше с приводов.

можно делать его отдельно настраивамым как ускорение торможения или в какой то зависимости от ускорения

Mamont писал(а): ↑ Практика критерий истинны.

нет. если теория верна - надо искать проблему в практике. практика это говно по сравнению с теорией.

frezeryga писал(а): ↑ что дают то и жрите

frezeryga писал(а): ↑ отсекается жирная часть возможно жирных клиентво

тут какая то странная ситуация. не относящаяся к теме и к задуманной ТС программе. но связанное с первым постом где обозначены цели.
в другой теме производитель считаю просто убивает свой бизнес пытаясь объять необъятное попутно оставляя недоведенными хорошие начинания. а начинания то были хорошие, я просто не вижу им альтернативы. но все типа черновики. загорелся, в принципе получилось, самореализовался и бросил. и 12345 как хотите с этим - я пошел дальше. в принципе конечно имеет право. но это не бизнес.

frezeryga писал(а): ↑ чпу станков кучу разных и нужно под каждый тип кастомизировать софт и интерфейс, а если будет очередное решение что дают то и жрите то отсекается жирная часть возможно жирных клиентво в том числе производителей станков которые будут брать много а трахать мозг мало и останутся хоббисты которые будут брать мало и трахать мозг много.

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

Да, понимаю, что производители станков будут не в восторге. Но, по факту производители уже начали трахать мозг, при том, что покупать, скорее всего, не будут. Чтобы интерфейс можно было как у тебя настраивать нужна и сама ЧПУ, которую можно гибко настраивать под любые станки. Тот же LinuxCNC. Я на такое пока не способен. Я даже не представляю, что с многоосевой обработкой делать. Как станок настраивать, как в 3d окне траекторию показывать, и с планировщиком не представляю как быть с многоосевой обработкой. Так что тебе моя прога не подойдет, а портить ради этого интерфейс - не хочу.
Ты вот нарисовал интерфейс под свой размер монитора, и все отлично. А мне нужно учесть, и тех, кто с квадратными, и тех, у кого dpi нестандартный. Что будет с твоим интерфейсом, если его на квадратном мониторе открыть? Он превратится в тыкву. А мне пришлось всякие панели изменяемого размера делать, привязки размеров кнопок, и т.п. Да и разбит интерфейс уже на блоки, которые я постарался аккуратно скомпоновать, и теперь уже сложно разделить на элементы. т.к. многое взаимосвязано.

Я подумаю над возможностью создать пользовательский интерфейс. Но это будет отдельный другой интерфейс, не связанный с основным. Там где все будет собираться из кнопок, надписей, и картинок. Редактировать основной нереально.

frezeryga писал(а): ↑ элементарно я хочу приделать например кнопку включения пылесоса или вакуума, или кнопку запуска какого либо макроса

Повесь их на кнопки Air M07, Flood M08, или на пользовательские кнопки внизу.

frezeryga писал(а): ↑ и 3д щупа на лапе а это требует своих макросов и доп кнопок.

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

я уже писал и вряд ли был услышан.
вот что касается буферов, предпрсмотров, перемещений, скруглений и тп, поддержки стандартов Гкода - тут бессмысленно чтото советовать ибо ты просто не понимаешь так как не пробовал вникнуть. тут разработчик рулит.
но в плане интерфейса можно послушать уже и юзера.
разработчик программы не в силах предусмотреть всё и не надо. но он может дать механизм это реализовать самостоятельно
как пример что должна сделать программа при потере связи с контроллером? нифига неоднозначно - но вызвав в этот момент пустой скрипт(макрос как тут принято хотя это убого) эта дыра затыкается без особого напряга для разработчика. плюс если эти скрипты разработанные юзерами накапливаются в багаже программы - это же здорово, не?

michael-yurov писал(а): ↑ Для работы с щупом, скорее всего, целое окно дополнительное понадобится.

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

vtgmfg писал(а): ↑ вот что касается буферов, предпрсмотров, перемещений, скруглений и тп, поддержки стандартов Гкода - тут бессмысленно чтото советовать ибо ты просто не понимаешь так как не пробовал вникнуть. тут разработчик рулит.

Да, тут, на самом деле, сложные вопросы. Это по отдельности, в отрыве от реальности, кажется что можно было бы здесь настроить, или тут подправить. А на самом деле каждое подобное изменение тянет за собой необъятное количество последствий. И ради чего все? Ради возможности один раз побаловаться, и забыть? Нельзя просто так взять и задать разные параметры для рабочих и холостых перемещений, т.к. их невозможно будет изменить на лету, и придется останавливаться между G1 и G0. Представьте, что вы на автомобиле движетесь по дороге, и на трассе на приличной скорости на очередном повороте вам подменяют автомобиль, у которого совсем другие характеристики. Вот весело то будет! Да, наверное, все это можно было бы учесть и рассчитать заранее, но все это дико усложняет математику в контроллере. Я уже выкладывал траекторию из PowerMill (еще 11 лет назад). Там рабочая подача переходит в быстрые переходы, и затупы в этот момент неприемлемы. И это простейший случай, где траектория трехмерная, и переход происходит на прямой при движении только по одной оси.

vtgmfg писал(а): ↑ но в плане интерфейса можно послушать уже и юзера.

Я слушаю, и думаю, как учесть важное. Тот интерфейс, что нарисовал нужен был как отправная точка, как основа, с которой можно работать. Чтобы увидеть проблемы, недостатки, недоработки. Подумать, какие возможности есть для изменения или улучшения, и чем за это придется расплачиваться. Главная проблема изменений не в сложности реализации, а в том, что все это повлечет за собой какие-то последствия и придется чем-то расплачиваться.

vtgmfg писал(а): ↑ как пример что должна сделать программа при потере связи с контроллером? нифига неоднозначно - но вызвав в этот момент пустой скрипт(макрос как тут принято хотя это убого) эта дыра затыкается без особого напряга для разработчика.

Отличный план! Надежный, как швейцарские часы!
Учитывая, что пользователь и исполнение макросов находятся на стороне компа. А с контроллером уже потеряна связь. И что этот макрос сделает, когда все проблемы свалились на контроллер, которому теперь нужно как-то остановить, или приостановить обработку?

vtgmfg писал(а): ↑ мне нужен вообще другой интерфейс, вы его видите каждый день и одновременно не видите. и это не виндовс. просто крик души

Со смартфона что ли?

michael-yurov писал(а): ↑ Представьте, что вы на автомобиле движетесь по дороге, и на трассе на приличной скорости на очередном повороте вам подменяют автомобиль, у которого совсем другие характеристики.

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

michael-yurov писал(а): ↑ Тот интерфейс, что нарисовал нужен был как отправная точка, как основа, с которой можно работать.

наверное. но я с километра вижу что это не тот интерфейс что мне бы хотелось. почему? я захожу со стороны задачи. а все эти интерфейсы - набор инструментов. и как ни верти - они все схожи в этом.

michael-yurov писал(а): ↑ Отличный план! Надежный, как швейцарские часы!
Учитывая, что пользователь и исполнение макросов находятся на стороне компа. А с контроллером уже потеряна связь.

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

michael-yurov писал(а): ↑ Со смартфона что ли?

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

michael-yurov писал(а): ↑ Что будет с твоим интерфейсом, если его на квадратном мониторе открыть? Он превратится в тыкву.

он растянется просто,да будет некрасиво и квадратные кнопки станут не квадратными но в тыкву не превратится.

michael-yurov писал(а): ↑ Для работы с щупом, скорее всего, целое окно дополнительное понадобится. Но какие-то функции может и в основной интерфейс запихну. Посмотрим, как пойдет.

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

вот еще пример вкладочного интерфейса https://youtu.be/MLLEPYfzlwQ?si=szQOshDRR9r8aEQz сам под вертикальный экран тоже делаю.

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

Mamont писал(а): ↑ При потере связи не паниковать и сохранять прямолинейное движение.

а если было движение по кругу?
на самом деле потеря связи с контроллером ситуация несколько надуманная. просто как вариант ситуации которую разработчик мог бы переложить на юзера через пустой скрипт

Mamont писал(а): ↑ Через него осуществляется и плавное и аварийное торможение.

аварийное я бы не стал на контроллер осуществлять

frezeryga писал(а): ↑ чтобы запихать в 15 дюймов в нормальном пальцезаточенном размере весь функционал нужны вкладки.

мне 10-11" достаточно.

что там за десять квадратиков на скрине с системами координат?