cnc-club.ru

В принципе получается есть небольшое количество ячеек, в которых храниться положение X,Y,Z,A, скорость движения, обороты шпинделя, и др..
И с каждой из строк G-кода меняется одна или несколько ячеек, ну а после <LF> собственно выполнение.
Сам в начале впал в ступор, когда только этим увлекся, а потом всё оказалось куда проще и интереснее.

Странно что в компьютерную эру не сделали другой способ интерпретации. Можно же было сделать что-то типа
move(,100,10) (аналог G0 Y100 Z10)
feed(1000) (аналог F1000)
line(100, 100, 100) (G1 X100 Y100 Z100)
for($i=0; $i < 10; $i += 2) //проход по контуру несколько раз
$contour_kakoito($i)
end

$contour_kakoito($z) //определение функции прохода по контуру
line(100, 100,$z) //квадрат, например
line(1,100,)
line(1,1,)
line(100,1,)
line(100,100,)
end

а вместо этого начали затычки лепить типа O-кодов.

На многосимвольные команды требуется больше памяти в станке для хранения прогрммы...

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

все придумано до нас...
http://www.vagrearg.org/content/gcmc

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

Крафтер писал(а):Хоббийщикам думаю до лампочки на размер программ.

Ну если они желают "вариться в собственном соку" и не пользоваться плодами прогресса, то конечно до лампочки...

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

Крафтер писал(а):

самопал.zip

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

Все равно спасибо! т.к. тоже начал делать на STM32F429ZIT6, будет с чем сравнить

selenur писал(а): Все равно спасибо! т.к. тоже начал делать на STM32F429ZIT6, будет с чем сравнить

Для компиляции нужен Qt 5 и библиотека GLM. Для мк - Keil uVision 5.
Я уже от текущего подхода отказался. Легче всё интерполировать отрезками (хоть кривые Безье), а по ним рассчитывать расстояние до конца линии. Тогда можно сделать сопряжение кусков траектории без торможений при переходах, а также легко менять скорость подачи из интерфейса или по аппаратному сигналу. Плюс можно будет сделать поворот системы координат и увеличить число осей до 5.

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

sidor094 - может вам такой вариант рассмотреть http://habrahabr.ru/post/208026/ ?

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

Протокол обмена простой и очевидный.
От компа пакеты идут гарантированно, назад - нет.
На компе есть очередь исходящих пакетов, на мк есть очередь входящих пакетов. За счёт этого обеспечивается непрерывный поток команд.
Управляющие команды складываются в очередь пронумерованными пакетами.
На каждой итерации берётся пакет из очереди и шлётся устройству.
При приёме устройство оповещает комп о том, что принят пакет с таким-то номером.
Если оно не успело оповестить, комп шлёт опять тот же пакет, иначе выкидывает его из очереди.
Если пакет принят повторно, то не запоминаем его, а просто оповещаем о приёме.
Комп не парится с тем, что на мк кончилось место, и постоянно пытается послать ещё. А мк, если места нет, просто не принимает.

В принципе я весь код стараюсь писать так, чтобы при потере связи не случилась катастрофа.

Например в контроллере mk1 от planet-cnc, есть буфер, состоит из 14 ячеек по 64 байта, в этот буфер с компьютера посылаются данные, а контроллер компьютеру постоянно шлет пакет из 64 байт, в котором есть информация о том на сколько наполнен буфер, текущие координаты, и ещё кое какие режимы. В результате чего удается добиться такого обмена, что контроллер не уходит в аут, от избытка информации, т.к. компьютер следит за размером буфера, и необходимостью посылать новые данные.

Крафтер писал(а):Комп не парится с тем, что на мк кончилось место, и постоянно пытается послать ещё. А мк, если места нет, просто не принимает.

RS232 имеет встроенные средства контроля потока, аппаратные - сигналы DTR/DSR и RTS/CTS, и программные - байты XON/XOFF, используйте их.

Не хотел использовать длинный буфер т.к компьютер должен показывать текущую команду,да и не хотел слишком усложнять протокол отвечая номером в буфере .А DTR RTS не получилось использовать на компе,хотя это был бы наилучший вариант. Сейчас у меня контроллер сам выводит на дисплей и принимает с клавиатуры ,но планирую разделить функции.Была мысль СОМ использовать только для отображения координат и ввода команд с клавиатуры загрузка пока с microcd.В дальнейшем для загрузки загрузки программ в память контроллера думаю отдельный интерфейс типа ETHERNET или что нить другое .Есть ли у кого нибудь опыт работы на компе с СОМ с помощью DTR RTS ?
Не хотелось бы использовать USB да и ЕТНЕRNЕТ не лучший вариант.Слишком подвязаны к аппаратуре (конкретного микроконтроллера).

sidor094 писал(а):Есть ли у кого нибудь опыт работы на компе с СОМ с помощью DTR RTS ?

А какой там опыт нужен? Просто настраивается соотв. режим порта, в программе выделяется память под буфер, системному драйверу порта сообщается адрес этого буфера и всё. Потом только пихаешь байты в этот буфер и следишь, чтобы он не переполнялся, а драйвер и чип порта сами будут всё передавать/принимать отслеживая управляющие сигналы.

sidor094 писал(а):да и ЕТНЕRNЕТ не лучший вариант

ЕТНЕRNЕТ наилучший вариант: большие скорости, минимальные задержки, "встроенная" гальваническая развязка.

sidor094 писал(а):USB да и ЕТНЕRNЕТ не лучший вариант.Слишком подвязаны к аппаратуре (конкретного микроконтроллера)

И то и другое вполне нормальные варианты. И почему так пугает подвязка к конкретному контроллеру? Продумали задачу, выбрали подходящее железо и делаете на нем

Сейчас в процессе изучения МК STM32F429 нашел в нем DSP модуль, который по идее должен ещё ускорить алгоритм интерпретатора, правда ещё не разобрался как...
Кто нибудь имел возможность с этим модулем работать?

UAVpilot писал(а):Просто настраивается соотв. режим порта, в программе выделяется память под буфер, системному драйверу порта сообщается адрес этого буфера и всё. Потом только пихаешь байты в этот буфер и следишь, чтобы он не переполнялся, а драйвер и чип порта сами будут всё передавать/принимать отслеживая управляющие сигналы.

Все кроме настройки режима с DTR RTS работает.Не получилось настроить СОМ с синхронизацией.