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

Мы наблюдаем общество, которое все больше зависит от машин, но при этом использует их все неэффективнее. (с) Дуглас Рашкофф

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

Опубликовано
Комментарии 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.
На скринах представлены небольшие программы, которые демонстрируют работу с данным набором классов.

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