Совместная разработка системы ЧПУ.

[MX_Master]

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

Общий алгоритм работы любого модуля:

Список основных модулей:

1. НАСТРОЙКИ. Получение и сохранение настроек из указанного файла. Путь к файлу и формат файла настраиваются командами.
2. ФИЛЬТР управляющего кода. Убирает из кода комментарии и все ненужные данные. Разбивает составные команды (например, G2/G3/циклы) на более простые согласно указанной точности. Точность можно указать соответствующей командой.
3. КОНВЕРТЕР управляющего кода. Модуль конвертирует каждую строку в бинарный формат кадра. Каждый кадр содержит всю информацию о состоянии управляющих команд на текущий момент.
4. ПЛАНИРОВЩИК. Распределяет управляющие бинарные кадры согласно заданным формулам ускорения, минимальным и максимальным значениям. Каждый новый кадр выполнен согласно времени сервопериода. Формулы, ускорения, мин./макс. значения и время сервопериода задаются соответствующими командами.
5. ИНТЕРФЕЙС. Визуальное взаимодействие системы с пользователем.
6. КОНТРОЛЛЕР. Обеспечивает взаимосвязь между модулями. Управляет процессами запуска и остановки выполнения бинарных кадров.

Общий алгоритм работы системы:

Открыть схемы можно в этом редакторе - https://programforyou.ru/block-diagram-redactor. В архиве исходники

Совместная разработка системы ЧПУ.zip

(57.51 КБ) 45 скачиваний

[AAN]

Может это поможет, если кто не видел:
https://portal.tpu.ru/SHARED/g/GUSEV/Pu ... /PCNC3.pdf

Также интересную статью прикладываю

[MX_Master]

Если на минуту задуматься, чем по сути занимается система числового программного управления, можно обнаружить, что это обычный интерпретатор и исполнитель скриптового языка (например, G кода, Python, JavaScript, Lua). В идеале, как в коде указано, так и должно быть исполнено. Единственное, что даётся на откуп системе - скорость выполнения этого кода. А заниматься интерполяцией и расчётом траектории должна другая система - CAM

[sidor094]

А заниматься интерполяцией и расчётом траектории должна другая система - CAM

САМ вроде не занимается интерполяцией.Да и рассчет траектории можно считать условным ,может только при микроперемещениях.То есть например чпу контроллер может не иметь круговой интерполяции, а дуги делать на САМ за счет микроперемещений.Может такой вариант и приемлем,но это будет достаточно убогая система чпу опирающая исключительно на достаточно развитую САМ систему.А без костыля САМ не могущая ничего сделать.Например в токарке многое пишу вручную да и при фрезеровке такое бывает.Кроме того на таком станке вручную вообще работать будет невозможно.На мой взгляд оптимальных два варианта.1- по типу ардуины.Где на чпу передаются отдельные команды,и в контроллере происходит обработка только простых команд.В этом случае на компе можно запрограммировать коррекцию на радиус,поддержку параметрического программирования и использовать достаточно простые контроллеры.Основной недостаток такой системы это большая зависимость от пк.И при зависании пк зависнет и программа в станке.Вторая - это типа как я предлагал.Вся обработка на контроллере,а пк используется в качестве графической консоли.В этом случае основная проблема - это быстрая перекачка больших файлов с компа на контроллер.Так как например редактировать лучше на компе ,да и для рисования графики желательно иметь файл программы и на контроллере и на компе.Основное достоинство ПК - изначально поддерживаемая системой загрузка с различных внешних устройств ,И поддержка системой графики и обработки файлов.Все остальные преимущества за контроллером.Все расчеты контроллер может делать не хуже пк.Кроме того программа написанная на С легко переносима с одного контроллера на другой.Вот и надо использовать пк толлько для загрузки и обработки файла ,и как устройство отображения.При такой конфигурации основная проблема- скоростная связь ,и желательно через наиболее простой и распространенный интерфейс.Поэтому я и предложил компромиссный вариант - основная через ком порт(передаются команды с клавиатуры или мыши на контроллер и данные для отображения от контроллера.И например усб для перекачки кода в контроллер.Этого интерфейса может и не быть так как контроллер можно грузить например с флешки.

[sidor094]

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

[sidor094]

Не очень умею рисовать алгоритмы.Если что непонятно,спрашивайте.

[MX_Master]

САМ вроде не занимается интерполяцией.Да и рассчет траектории можно считать условным ,может только при микроперемещениях.

Конечно, занимается. Если для расчётов используется фреза, то траектория пройдёт интерполировано над поверхностью детали. Это, в общем-то, основная функция САМ систем - расчёт траекторий и интерполяция. Современные ЧПУ системы тоже этим занимаются. G2, G3, всё это мы знаем. Также стоит вспомнить про G64, который настраивает зализывание острых углов траектории согласно указанной точности. Как доп. функция G64, конечно, хороша. Но на мой взгляд ЧПУ должна отработать код так, как он был задуман изначально САМ системой.

На мой взгляд оптимальных два варианта.1- по типу ардуины.

Вторая - это типа как я предлагал.Вся обработка на контроллере

Что касается реализации под конкретные платформы.. Я тоже думаю, что расчёты внутри микроконтроллера будут работать не хуже, чем на настолках. Но, всё равно, надо сохранять возможность переноса расчётных модулей между платформами. Например, мой вариант контроллера включает в себя копеечный мини ПК + несколько микроконтроллеров. Расчётные модули я планирую размещать именно на мини ПК, т.к. работать с файлами там быстрее и проще.

алгоритм линейного разгона

Из моего опыта, числовой и, одновременно, визуальный расчёт скоростей можно делать прямо в электронных таблицах (Excel, LibreOffice Calc). Оно будет намного понятнее и для себя, и для других. Кроме того, разгоны бывают и нелинейные Для них тоже желательно что-то придумать. Ну а, чтобы суть была понятна всем, лучше не использовать микроконтроллерные термины, типа "прерывание" и т.п. Я-то прекрасно пойму. А вот человек, который с этим не знаком, но желающий помочь в разработке, будет испытывать трудности. Ну и от степдира лучше пока отойти. Виды управления приводами есть разные, в том числе и аналоговые.

[sidor094]

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

Данный метод позволяет получить любую форму разгона.Только для сложнах форм алгоритм существенно усложняется.Для получения сложных форм нужен перерасчет суммы каждый такт по всему озу с различными весовыми коэффициентами для разных участков.Для линейного разгона озу используется только как линия задержки.И нужна только последняя вывходная ячейка для вычитания в сумматоре.поэтому алгоритм не затратный для процессора.Но конечно затратный для озу.так как озу требуется для всего времени разгона.С учетом максимальной частоты шагов в 200кгц и например времени разгона в 500мс требуется 100000 32 разрядных ячеек.

[MX_Master]

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

[sidor094]

Поэтому я (ещё разок) предлагаю отойти от реализации вывода сигналов для конкретных платформ.

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

[MX_Master]

Платформа - это место выполнения машинного кода. У каждой платформы свои общие и частные возможности. У ARM платформы STM32 есть частная возможность делать/выводить/считать сигналы/прерывания аппаратно. Но программа, запущенная под какой-то ОС на ПК таких частных возможностей может не иметь. Поэтому модули ввода/вывода и транспортировки данных для каждой платформы будут разные. А мы пока ещё на стадии планирования общих модулей, которые должны одинаково хорошо работать в любом месте (на любой платформе, на любом железе).

ЗЫ между микроконтроллерами и настольными ПК пока ничего лучше USB/Ethernet не придумано. COM порт, как и LPT порт, это в современных ПК, скорее, для совместимости с чем-то из прошлого. Так что, я бы сильно на них не рассчитывал. А для связи микроконтроллеров с мини ПК вполне подойдёт UART/SPI. Я, к примеру, использую стандартный SPI драйвер ядра Linux для связи с двумя STM32.

[sidor094]

У ARM платформы STM32 есть частная возможность делать/выводить/считать сигналы/прерывания аппаратно.

Я для движения использую SysTic таймер.Он одинаковый не только для STM32 ,но и для всех контроллерах на ядре Cortex.В остальном ,конечно Вы правы,но для человека знакомого с микроконтроллерами проблема переноса кода минимальна.Я перевел программу с Филипса на STM32 в течении двух-трех дней,и в основном время ушло на графический контроллер и динамическое ОЗУ.

COM порт, как и LPT порт, это в современных ПК, скорее, для совместимости с чем-то из прошлого. Так что, я бы сильно на них не рассчитывал.

Не согласен насчет компорта .В том или ином (485,422)наверно наиболее часто используемый порт во многих промышленных разработках.Этим объясняется большое количество продаваемых переходников усб-ком.Наверно самый простой и надежный интерфейс.Хотя конечно,по современным меркам очень медленный.

Я, к примеру, использую стандартный SPI драйвер ядра Linux для связи с двумя STM32.

SPI конечно не плохой и достаточно шустрый интерфейс,Но основными его недостатками является малая дальность,и распространенность в ПК.С малой дальностью еще можно бороться (например применив диффиренциальный каскад и витую пару) ,но вот с отсутствием данного интерфейса на многих(большинстве а точнее я вообще не встречал) ПК уже проблема.

[MX_Master]

Какой формат управляющего кода возьмём за основу? Удобнее, конечно, от одной из существующих систем. Типа G кода от LinuxCNC/Mach3/Mach4. Этот формат знают все. Будем ли использовать в коде какие-то новые управляющие команды (кроме стандартных G/M/O/..)?

[MGG]

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

RTCP
Нарезание резьбы с изменением оборотов шпинделя.

Забавно, давайте сделаем свою чпу!
Да давайте!
Она должна быть сразу в топе, как системы в закупе за миллионы и никак иначе

[sidor094]

Я пытался Фанук.Но можно любой.У меня расширенные коды выполняются как функции..Пишутся на флешке в файле functions.ini

[MX_Master]

Я пытался Фанук.Но можно любой.У меня расширенные коды выполняются как функции..Пишутся на флешке в файле functions.ini

Может, вызывать доп. функции/макросы как М-коды (с параметрами)? Чтобы не выбиваться из общего формата файла. А непосредственно код функций/макросов - на С (в виде модуля) или в виде того же G кода.

Я, кстати, ничего не имею против кода управления для Фанук. Но не все слайсеры и CAM софт содержат постпроцессоры для Фанука. Нельзя исключать, что наш софт будет использоваться не только в ЧПУ станках, но и в принтерах, ПЛК и прочих контроллерах.

[sidor094]

help.h

(30.76 КБ) 40 скачиваний

Это краткий файл помощи по системе.Его можно вывести на экран ,нажав кнопку print screen.В нем описано каке можно использовать параметрическое программирование и приведены примеры функций которые помогают расширить возможности станка.

[sidor094]

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

[MX_Master]

Просто решил,что писать отдельную пдфку в качестве руководства по системе чпу лень.Решил включить помощь непосредственно в систему чпу.Его можно всегда вывести на экран.

Я думаю, надо сделать доки в текстовом формате. А рядом надо положить "генератор" (скрипт/модуль) для получения популярных форматов (PDF, HTML).

[MX_Master]

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