cnc-club.ru

Сейчас есть у интекры техподдержка, а через пару лет все это накроется (разорится, продадут бизнес, да мало ли) и останется только надеяться что в прошивке и в ПО нет ошибок.
Пользуются люди, конечно, и maxh3 13-летней давности, но о поддержке там речи нет.
А Lcnc развивается сообществом энтузиастов и релизы выходят каждый год. Тут вероятность исчезнования проекта существенно поменьше.

Сам перешел год назад с win+мач на lcnc. Переход занял 3 дня. Это при том что это был мой первый linux в жизни. И два из этих трех дней я как раз usb-wifi прилаживал)

alex_sar писал(а): ↑ заточен на сервоцикл в компьютере, программный.

зачем это если станком управляет контроллер

vtgmfg писал(а): ↑ зачем это если станком управляет контроллер

ты не можешь поменять логику по которой работает контроллер. она в него жёстко прошита.

ту же самую кинематику хитрую, то как будут концевики отрабатывать, как touch probe работает. (да, какие то настройки есть наверное, но только те которые автор прошивки предусмотрел, а вариантов то бесконечное количество)

если тебя всё устраивает, то тебе повезло.

а если нет, ставишь linuxcnc и делаешь именно так как тебе надо.

alex_sar писал(а): ↑ ты не можешь поменять логику по которой работает контроллер. она в него жёстко прошита.

почему обязательно жестко? если комп может конфигурить то что работает в контроллере, какая то оперативка там есть.

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

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

я думаю жестко. в теории сделать можно по-всякому, но это ОЧЕНЬ сложно и пока о таком чёто не слышно.

автор по wlmill писал что туда передается g-code с компа. получается вообще там (имхо) какой то доработанный grbl внутри получается и всё или аналог того. так что в том контроллере будет только то что предусмотрено кодером.

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

скоростью отличается. mesa свежая может вроде на частотах до 10 мгц работать. Это step/dir и чтение энкодеров.
плюс есть например такие платки http://yurtaev.com/ которые напрямую с сервами Mitsubishi работают по цифровым протоколам, есть другие варианты которые ethercat поддерживают.

вот нашёл пару видюшек для иллюстрации гибкости
https://www.youtube.com/watch?v=rZoLP0v50rw
https://www.youtube.com/watch?v=jZWbWyFfRZ0
https://www.youtube.com/watch?v=fd949uLlW3w
https://www.youtube.com/watch?v=eZvrxjzJkSE
https://www.youtube.com/watch?v=hPE3Qr-ECtQ

такая экзотика конечно редко нужна, но приятно что все можно делать на одной системе (если осилить ее однажды).

alex_sar писал(а): ↑ такая экзотика конечно редко нужна, но приятно что все можно делать на одной системе (если осилить ее однажды).

ещё бы свободное сообщество КАМ под это всё родило когда нибудь...

alex_sar писал(а): ↑ автор по wlmill писал что туда передается g-code с компа. получается вообще там (имхо) какой то доработанный grbl внутри получается и всё или аналог того. так что в том контроллере будет только то что предусмотрено кодером.

Интересно где такое было написано?

"автор по wlmill писал что туда передается g-code с компа." - это неверно.

Ну неверно так неверно.

wldev писал(а): ↑ "автор по wlmill писал что туда передается g-code с компа." - это неверно.

Возможно читал про "распарсенный g-code"=траекторию. Честно говоря сути дела не меняет.

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

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

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

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

насколько я понимаю Гкод для того и создан чтобы формализовать всевозможные движения. и если МК в состоянии переварить допустим подготовленный Гкод+всякие перенастройки+ручные перемещения, то в чем МК отличается от компа?
Да - на компе ресурсов больше. но вот если комп выполняет сервоциклы то ему и спецОС подавай и играть параллельно в вольфенштейн - уже будет стремно, если вообще получится ибо реалтайм.

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

vtgmfg писал(а): ↑ Фокусы наверное нет, а оно может и не надо.

не надо так и не надо.
на 3д принтере работает marlin, мне и в голову не придёт туда ставить linuxcnc.

а вот для станка мне нравится и мне важно что могу поменять как хочу пользовательский интерфейс. причем не плагином а глядя в полные исходники. и не надо никого за рукав дёргать - "дядя, ну сделай пожалуйста"
никакая платная система такого не позволит сделать.

vtgmfg писал(а): ↑ и если МК в состоянии переварить допустим подготовленный Гкод+всякие перенастройки+ручные перемещения, то в чем МК отличается от компа?

Простенький G-код, по тупому, и неспешно, да, может переварить. У 3d принтеров буфер в 16 строк кода. Просто чтобы исключить задержки при передаче данных. Им хватает. Полагаю, и у Инектры - так же. Но если у тебя траектория под высокоскоростную обработку, эти 16 строк за несколько миллисекунд вылетят. И что дальше? Резкая остановка со срывом моторов?
Но главное отличие не в этом, а в том, что имея в буфере лишь несколько строк, ты не можешь рассчитать с какой скоростью можно двигаться по траектории. Что там будет в следующей строке? Остановка? Резкое изменение направления, или плавная траектория? А может изменение скорости подачи, и нужно лишь слегка притормозить? Комп способен все это предусмотреть, а у МК памяти недостаточно, и производительности маловато для тригонометрии. Могу ошибаться, но думаю что у Инектры предпросмотр, если и есть хоть какой-то примитивный, то лишь на одну строку.
Вот это, реальные вопросы, как в 48 КБ оперативки запихнуть несколько гигабайт данных для расчетов. И когда их решаешь меньше всего беспокоит то, как пользователь в Вольфэнштейн играть будет.

alex_sar писал(а): ↑ а вот для станка мне нравится и мне важно что могу поменять как хочу пользовательский интерфейс. причем не плагином а глядя в полные исходники. и не надо никого за рукав дёргать - "дядя, ну сделай пожалуйста"

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

michael-yurov писал(а): ↑ о главное отличие не в этом, а в том, что имея в буфере лишь несколько строк, ты не можешь рассчитать с какой скоростью можно двигаться по траектории. Что там будет в следующей строке? Остановка? Резкое изменение направления, или плавная траектория? А может изменение скорости подачи, и нужно лишь слегка притормозить? Комп способен все это предусмотреть, а у МК памяти недостаточно, и производительности маловато для тригонометрии. Могу ошибаться, но думаю что у Инектры предпросмотр, если и есть хоть какой-то примитивный, то лишь на одну строку.

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

alex_sar писал(а): ↑ чисто теоретически вроде нет проблемы предпросмотр ускорения и прочее считать на компе а результат выносить на контроллер. особенно если нет обратной связи от линеек и т.д.

Тогда ты уже не можешь передавать в контроллер G-код в исходном виде. Придется дописывать какие-то свои команды. И это очень непростая задача. Например, у тебя строка с циклом сверления. Что там куда дописывать? Или одной строкой в программе команда движения по спирали с переменным радиусом, где скорость должна постоянно изменяться. Тогда как? А если пользователь в процессе работы изменил скорость подачи - что должен делать комп со своими предварительно рассчитанными значениями? Быстренько все пересчитать, сгенерировать новый псевдо g-код, и моментально передать его в контроллер с заменой данных в буфере так, чтобы движение не прервалось? Еще и с учетном равномерного перехода с текущей скорости подачи на новую? Какой смысл тогда передавать в контроллер G-код в текстовом виде, если все равно приходится все заранее обрабатывать, просчитывать и еще и свой собственный G-код генерировать?
Ну и даже чисто теоретически, чтобы все это передавать с дополнительными служебными командами нужно больше памяти в контроллере, а где ее взять то? За счет чего освободить?
А вот обратная связь, как раз, контроллером без проблем обсчитывается. Но тогда нельзя буферизировать данные для генерации Step/Dir, как это в контроллерах mach3 сделано. Поэтому у них и нет обратной связи. Ну, т.е. можно, конечно... но опять же, все усложняется.

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

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

michael-yurov писал(а): ↑ Какой смысл тогда передавать в контроллер G-код в текстовом виде, если все равно приходится все заранее обрабатывать, просчитывать и еще и свой собственный G-код генерировать?

ну про wlmill g-code я погорячился. там вроде про траекторию речь шла действительно.

вот в инектре точно g-code передается и вообще это клон grbl с дружелюбным виндовским интерфейсом. они об этом честно сами писали.

Быстренько все пересчитать, сгенерировать новый псевдо g-код, и моментально передать его в контроллер с заменой данных в буфере так, чтобы движение не прервалось?

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

michael-yurov писал(а): ↑ Ну и даже чисто теоретически, чтобы все это передавать с дополнительными служебными командами нужно больше памяти в контроллере, а где ее взять то? За счет чего освободить?

да не так уж и мало памяти в современных stm а если что можно и внешний чип зацепить.

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

А вот обратная связь, как раз, контроллером без проблем обсчитывается.

я бы так не сказал. один какой то конкретный use case можно сделать да.

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

Так я к тому и веду, что не может МК полноценно заменить комп. Только со значительными упрощениями и ограничениями.

alex_sar писал(а): ↑ вот в инектре точно g-code передается и вообще это клон grbl с дружелюбным виндовским интерфейсом. они об этом честно сами писали.

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

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

Опять же, дополнительный расход памяти на служебные данные.
Я тут на днях про синхронный доступ к кольцевому буферу данных читал. Человек много лет потратил, чтобы написать надежную реализацию, которая без сбоев с прерываниями работает. А подсовывать контроллеру новые данные в последний момент - очень плохая идея. Ну либо нужно два буфера, чтобы можно было моментально переключиться. Про расход памяти я же уже писал, да?

alex_sar писал(а): ↑ да не так уж и мало памяти в современных stm а если что можно и внешний чип зацепить.

Искал я внешний чип. Либо там объем смешной, либо с наличием и покупкой проблемы. Еще и доступ через параллельный интерфейс, который половину ног микроконтроллера сожрет.

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

alex_sar писал(а): ↑ тем более держать нужно не такой и огромный буфер по длине.

А какой нужно? Есть траектории, где размер сегментов в микронах измеряется. А скорость подачи несколько метров в минуту. Т.е. до 100 000 сегментов в секунду! Понятно, что у пользователей Инектры числа намного скромнее, но все же.
Даже у mach3 для нормальной работы нужен буфер в пару секунд, при чем там не сегменты, а данные для каждого сервоцикла. Т.е. в буфер должно поместиться хотя бы 2000 блоков данных. И это древний mach3, у которого частота сервоцикла всего 1 кГц. А у меня, например, 10 кГц, и уже получается нужно 20000 блоков данных, например по 48 байт (навскидку, для 6 осей + служебная информация). Т.е. мегабайт! А если еще второй такой же буфер держать для подмены, если данные обновились, уже два мегабайта получается. Такими объемами оперативки у STM32 даже не пахло.

michael-yurov писал(а): ↑ И это древний mach3, у которого частота сервоцикла всего 1 кГц.

а зачем больше? вроде linuxcnc тоже нормально штатно работает с 1Khz
тогда всего 2000 блоков )

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