КОТ++
Прикладное программирование
Системное программирование
Программирование микроконтроллеров

Если вы дадите человеку программу, то займете его на один день. Если вы научите человека программировать, то займете его на всю жизнь. (с) Васим Латиф

Поиск по тегам

Опубликовано
Комментарии 0

Не так давно мне поступил заказ на написание программы для windows, которая будет управлять по Ethernet ЧПУ контроллером PLCM от purelogic. Нужно было сделать не готовый софт, а все основные модули для работы с контроллером. Обязательно на Borland Delphi 7, что меня не могло не расстроить – это же старьё, ну так как человек, который после будет работать с моим кодом ничего другого не знает, то куда деваться то.

Протокол для работы с устройством был предоставлен. Связь по UDP, соответственно отслеживание потери пакетов перекладывается на мои плечи, для этого в протоколе предусмотрена нумерация каждого пакета, контроллер периодически говорит какой номер у последнего принятого пакета. Первые и последние байты – длина пакета, второй – нумерация, остальное – команда и данные.

Научив программу считать контрольную сумму (CRC16), уже удалось убедиться что контроллер принимает и понимает отправленные ему пакеты. Но, конечно, не обошлось без Wireshark, так как документация по протоколу не была полной, пришлось смотреть некоторые каверзные моменты протокола вживую, я изучал то что шлёт программа Mach3. Были реализованы команды: управление пинами, сброс (для обозначения начала связи), ручное перемещение осей, поиск базы, остановка, авария, траекторные данные, установка текущих координат, настройка ограничений перемещений, настройка портов ввода-вывода, умножитель скорости.

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

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

Итог в этой публикации.

В заключении хотел сказать, что на рынке сейчас очень много различных ЧПУ контроллеров и ПО к ним, о чём я раньше не знал. Из этого можно сделать вывод, что всевозможные бесплатные решения на arduino, raspberry pi с grbl, LinuxCNC не покрывают все требования к ЧПУ.
И ещё: LPT порт пережиток прошлого (на мой взгляд), но всё равно от него есть следы в современных контроллерах ЧПУ. Как я понимаю раньше драйверы шаговых двигателей подключали к компьютеру через LPT порт, и теперь когда люди подключают драйверы уже в отдельный контроллер, то видимо всем удобней, чтобы входы-выходы на этих контроллерах повторяли LPT порты.

Теги , , ,
Автор

Опубликовано
Комментарии 0

Классы были написаны на Delphi 7. Имеют в функционале: интерпретацию G-кода, расчёт траекторий для совместного движения осей (траектории строятся с учётом ускорений и торможений), низкоуровневый обмен пакетами с контроллером PLCM через UDP.

Основные классы в проекте:
TPLCM – обмен пакетами с контроллером
TMathTrajectory – расчёт траекторий
TCRC – вспомогательный класс для расчёта контрольной суммы пакета
TGCodeInterpreter – класс, который интерпретирует G-код
TPackageBuffer – буфер пакетов
TTrajBuffer – буфер траекторий

Так как расчёт траекторий процесс довольно не простой, то для класса, который считает траектории были написаны unit тесты, а также дополнительная программа для визуального отображения траекторий на графиках.
Так как связь по UDP, то было реализовано отслеживание потери пакетов и повторная отправка в случае потери. Документация протокола от разработчика контроллера не включала всех деталей, поэтому некоторые детали протокола были выяснены самостоятельно через программу Wireshark. С помощью Wireshark был пронализирован трафик, который шлёт ПО Mach3.
На скринах представлены небольшие программы, которые демонстрируют работу с данным набором классов.

Теги , , ,
Автор