cnc-club.ru

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

Начало разговора было здесь - viewtopic.php?p=640609#p640609

На мой взгляд, если подойти к вопросу в лоб, мы сделаем что-то вроде ещё одной копии GRBL/Marlin/RepRap/LinuxCNC или чего-то подобного. Все эти прекрасные проекты имеют тонну всяких возможностей, за исключением одного главного минуса. Их код не универсален и перенос его с платформы на платформу - тот ещё геморрой. Даже если код будет успешно портирован, автор оригинала его поддерживать не будет. Вся совместимость будет висеть на плечах программиста, который портировал код на новую платформу. И если этот программист куда-то исчезнет, то всё, сушите вёсла. Поэтому я думаю, что разные части проекта надо делать так, чтобы код работал практически на любой платформе. Что-то на подобии простых библиотек, по возможности, без зависимостей.

Второй момент - модульность и общение между компонентами. Желание собрать всё необходимое сразу в одном месте понятно. Использовать общие переменные (общую память) для связи между компонентами и функциями - это тоже быстро и просто. В рамках небольшого проекта, конечно. Но что, если нам нужно разнести какие-то большие функции и компоненты по разным процессам или устройствам? Общие переменные и общая память станут нам недоступны. Значит, никакой общей памяти между разными компонентами быть и не должно. Каждый компонент (модуль) должен иметь свой кусок памяти и его общение с другими компонентами должно быть максимально примитивным (ввод/вывод). Ну и, чем проще будет функционал каждого модуля, тем легче будет находить ошибки, исправлять и оптимизировать.

Ещё один момент - абстракция и свобода выбора средств управления. Если мы возьмём какой-то стандарт G кода за основу и станем привязывать его напрямую к каким-то функциям и компонентам, то мы утратим свободу выбора средств управления. По факту не должно быть никакой жесткой привязки между строками какого-то текста (G кода) и функциями системы. Система должна использовать свой внутренний формат управления. А разные модули-конвертеры (из текста во внутренний формат) дадут возможность использовать любые виды управляющего кода (в том числе и G код).

это всё хорошо.
один вопрос. чем linuxcnc то не устраивает?

планировщик плохой? так его всё равно переделывать, вот и переделать там.
настраивается сложно? так сделать мастер настройки.

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

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

alex_sar писал(а): ↑ один вопрос. чем linuxcnc то не устраивает?

Один ответ. Попробуй перенести linuxcnc на другую платформу. Например, на винду. Или в микроконтроллер.

MX_Master писал(а): ↑24 окт 2022, 14:58

alex_sar писал(а): ↑ один вопрос. чем linuxcnc то не устраивает?

Один ответ. Попробуй перенести linuxcnc на другую платформу. Например, на винду. Или в микроконтроллер.

вот зачем её переносить в винду? чтобы что?

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

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

alex_sar писал(а): ↑24 окт 2022, 15:03
вот зачем её переносить в винду? чтобы что?

Солидворкс, фьюжин360 и др. работают в линуксе?

alex_sar писал(а): ↑ чем linuxcnc то не устраивает?

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

Cvazist писал(а): ↑24 окт 2022, 15:13

alex_sar писал(а): ↑24 окт 2022, 15:03
вот зачем её переносить в винду? чтобы что?

Солидворкс, фьюжин360 и др. работают в линуксе?

А при чем здесь солидворкс и фьюжн? Речь о станочной стойке. Совмещать это не разумно ни разу

Cvazist писал(а): ↑24 окт 2022, 15:13
Солидворкс, фьюжин360 и др. работают в линуксе?

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

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

sidor094 писал(а): ↑24 окт 2022, 15:15

alex_sar писал(а): ↑ чем linuxcnc то не устраивает?

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

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

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

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

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

Cvazist писал(а): ↑24 окт 2022, 15:32 На промышленном производстве , у некоторых форумчан, работают вместо стоек компы с мач3.
Видимо это не просто смелые духом , а супер умельцы.
Но есть и те кто не может с супер системой линукс снс справиться.

mach3 всё таки мноооого лет делают.

но я не об этом, я о другом. эти промышленники прям сидят в fusion рисуют пока станок пилит? смело...

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

Сейчас делаю новую версию своей программы, кроме генерации g-кода, планируется и управление некоторыми контроллерами, визуальную часть делаю на собственном 3д движке wpf (.net), но многие из алгоритмов могу легко выделить в отдельные библиотеки написанные например на С++, которыми могу поделиться, но вопрос в том не всем будет удобно использовать, я например использую тип decimal, а кто-то float, и значит ему нужно реализовывать перевод значений, некоторые функции например реализованы только для 2х осей, а кому-то нужна поддержка 3х осей, значит ему нужно будет самому дописывать, а значит добиться некого единообразия не получиться, или вообще делать некую базу знаний с алгоритмами. Вот пока в текущей идее не вижу реального смысла, или ошибаюсь???

Cvazist писал(а): ↑ Солидворкс, фьюжин360 и др. работают в линуксе?

В стойках Сименс, Фанук нет этих программ. А люди работают

Cvazist писал(а): ↑ На промышленном производстве , у некоторых форумчан, работают вместо стоек компы с мач3.
Видимо это не просто смелые духом , а супер умельцы.

Видимо у них денег нет на стойку или жаба душит

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

А почему grbl?Что в ней такого,что если автономка ,то только её?У меня система делает тоже самое,плюс скорость выше,плюс редактор,плюс коррекция на радиус,плюс параметрическое программирование.Например можно написать свой новый ж-код .Так например на токарнике как свои жкоды используются функции загружающиеся автоматически с флешки.Например многопроходная проточка,расточка,в том числе конусов,
нарезание многопроходной резьбы,ступенчатая проточка дуг.Все это можно превратить в одну команду.Но например вывод на экран занимает много ресурсов,при попытке поднять частоту шагов начинает тормозиться вывод на экран соответственно максимальная частота н превышает 170 кгц.Если интерфейс пользователя сделать на компе или например апельсинке ,тол можно значительно поднять тактовую или увеличить число осей,или воткнуть рассчет поддержания постоянной скорости при пятиосевой обработке.Я не очень владею программированием на компе и под операционками.а вот редактирование ,загрузку и отображение можно скинуть на что нибудь под операционкой,где например редактирование сводится лишь к созданию окна с определеннными свойствами ,а не требует написания сложного кода,так же автоматическая поддержка многих устройств (усб,едернет,вайфай )уже на уровне системных драйверов.

sidor094 писал(а): ↑ У меня система делает тоже самое,плюс скорость выше,плюс редактор,плюс коррекция на радиус,плюс параметрическое программирование

Где эту систему найти?

selenur писал(а): ↑ но многие из алгоритмов могу легко выделить в отдельные библиотеки написанные например на С++, которыми могу поделиться, но вопрос в том не всем будет удобно использовать, я например использую тип decimal, а кто-то float, и значит ему нужно реализовывать перевод значений, некоторые функции например реализованы только для 2х осей, а кому-то нужна поддержка 3х осей, значит ему нужно будет самому дописывать, а значит добиться некого единообразия не получиться, или вообще делать некую базу знаний с алгоритмами. Вот пока в текущей идее не вижу реального смысла, или ошибаюсь???

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

Какие например алгоритмы нужны?