cnc-club.ru

nebelnoir писал(а):Итак, друзья!
Вроде бы 5 и 6 оси заработали как надо!
Залил проект на github. Прошу, если не трудно, попробуйте кто-нибудь скачать и собрать, чтобы проверить, что всё качается и собирается
С НАСТУПАЮЩИМ ВСЕХ НОВЫМ 2019 ГОДОМ!

Попробовал, качается, собирается, прошивается. У меня правда проект в коид, я файлики синхронизировал beyond compare. Будем осваивать дальше.

Спасибо!

nebelnoir писал(а):Залил проект на github. Прошу, если не трудно, попробуйте кто-нибудь скачать и собрать, чтобы проверить, что всё качается и собирается

Это теперь будет постоянный репозиторий проекта?

P.S. Внимательно слежу за развитием. Через недельку придут STMки хочу мигрировать на эту платформу.
У меня вопросик. Как вариант на STM32 используете с точки зрения подключения? Через какую нибудь коммутирующую плату типа CNC Shield или кто во что горазд, на прямую к blue pill цепляемся?

daemon78 писал(а):Это теперь будет постоянный репозиторий проекта?

Да. Для новой версии grbl под stm32f4 сделаю отдельный, но это будет еще не скоро. В данный проект планирую добавить только backlash.

daemon78 писал(а):Как вариант на STM32 используете с точки зрения подключения? Через какую нибудь коммутирующую плату типа CNC Shield или кто во что горазд, на прямую к blue pill цепляемся?

Я планирую разработать железо (более адекватное чем на картинке в первом посте этой темы). Если получится коммерциализировать это направление наряду с другими идеями, то можно будет полностью погрузиться в разработку всех этих дел. Код, естественно, будет всегда открытый. Пока подключаюсь напрямую, но это неочень.

nebelnoir писал(а):Пока подключаюсь напрямую, но это неочень

Ага, согласен, я по этому и спросил.
Надо будет сделать что нибудь, чтобы не навесным монтажом все части между собой соединять.

nebelnoir писал(а):Да. Для новой версии grbl под stm32f4 сделаю отдельный, но это будет еще не скоро. В данный проект планирую добавить только backlash.

Здорово.
Удачи с проектом в новом году!!!

nebelnoir писал(а): Спасибо!

Всех с прошедшими и наступаюшими !

Есть моменты по теме GRBL и по контроллеру.
Так понял параметр P в команде G4 имеет размерность только в секундах и на миллисекунды не переключается или я где-то просмотрел? В целом не критично, дробные значения воспринимаются и отрабатывают нормально.

Сделал я свою утилиту (расширенный GCode сендер для ПК). Прокрутка программ по первому варианту протокола.
Небольшой предпарсер и анализатор. Теперь у меня работает код например такой:

(проверка параметров)
N250 #1001 = 101.01 (значение)
N251 #1002 = 110.10 (значение)
N252 #1003 = 103.03 (значение)
N253 #1004 = 104.04 (значение)
N254 #1006 = 02.01 (значение)
N255 #1002 = 102.02 (изменение параметра при выполнении)
N256 #1005 = #1001 ; присвоение параметра
N557 #1004 = #1001 / 2 ; выражения в присвоении параметру
;yeb
N260 G92 X00.01 Y0.02 (установим значения в текущей позиции)
N550 G0 X#1001 Y#1002 Z#1006 (подстановка параметров)
N560 G00 X[0+#1003] Y[0-#1004] Z[#1006/2] (парковка)
N900 M30

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

Электроника в разработке, в начале оптоизолятор usb, потом сама платка.

Есть последний момент. Я этот порт не смотрел, как-то давно пытался оригинал смотреть. Насколько я помню, там не увидел никаких симафорных механизмов для "обработки тика". Как обстоят дела здесь? Если обработка очередного тика (интерполяция по Брэзенхему) задерживается и наступает очередной "тик" - что будет, как в оригинале - пропуски?
Тема муссируется на буржуйских форумах. Поиск границ возможностей контроллера по тактовой частоте у народа в почете. В идеале, для серьезности всего этого дела лучше иметь два варианта - предварительный расчет и ограничение в параметрах с привязкой к ошибке например 12 и 22 и реальная фиксация такого наложения во время выполнения программ (какую здесь ошибку привязать даж не знаю). Тогда будет возможность подправлять/тюнить систему по необходимости.

Микола писал(а): Если обработка очередного тика (интерполяция по Брэзенхему) задерживается и наступает очередной "тик" - что будет, как в оригинале - пропуски?

Поясни пожалуйста, несовсем понятно. Что значит задерживается? Обратотка происходит в высокоприоритетном (насколько помню) прерывании по таймеру через фиксированное время. Всё успевает выполниться до наступления следующего прерывания. Если поставить слишком высокую частоту (например более 100кГц для 4х очей), то работа контроллера становится непредсказуемой, всё может упасть в любой момент, а может и не упасть. В любом случае так делать не надо. Вообще конечно хорошо бы обработку сделать, чтоб вылетала ошибка при попытке выставить запредельные параметры.

nebelnoir писал(а):Что значит задерживается?

траектории разные и разброс значений велик + коррективы планера - в каждом случае свое время арифметических вычислений. интерполяция по 4 измерениям или по 2 в разы по времени отличается.

nebelnoir писал(а):Если поставить слишком высокую частоту (например более 100кГц для 4х очей), то работа контроллера становится непредсказуемой, всё может упасть в любой момент, а может и не упасть. В любом случае так делать не надо.

О том и реч - как не надо делать и где эта граница? У пром. контроллеров имперические тесты + 10-50% закладка на резевр(зависит от периферии) при вводе параметров с жестким контролем.

С данным контроллером неплохо бы иметь такую диагностику и на стадии параметров и во время выполнения. Вещ классная и универсальная получилась - у кого 3 оси у кого 6 ситуация совсем не понятная в этом разрезе.

nebelnoir писал(а): Я планирую разработать железо (более адекватное чем на картинке в первом посте этой темы). Если получится коммерциализировать это направление наряду с другими идеями, то можно будет полностью погрузиться в разработку всех этих дел. Код, естественно, будет всегда открытый. Пока подключаюсь напрямую, но это неочень.

Как продвигается разработка железа? Мне стоит начинать рисовать свою плату? И так же, что выйдет раньше - железо на текущую версию или порт на F4? А то мож мне уже рисовать плату для F4 сразу и как раз они будут готовы одновременно )

Я планирую сделать универсальное железо на 4 оси, поскольку на моей отладке F4 (см. первый пост) выводы совпадают с bluepill. Ориентируюсь на конец апреля.
С портом пока не понятно. См. тему тут: https://github.com/gnea/grbl/issues/67

nebelnoir писал(а):Я планирую сделать универсальное железо на 4 оси, поскольку на моей отладке F4 (см. первый пост) выводы совпадают с bluepill. Ориентируюсь на конец апреля.

Ну уже неплохо. Мне как раз подойдет на мой раскладчик ) Там, кстати, будет возможность подключения какой-нибудь периферии по какому-нибудь интерфейсу UART/SPI/I2C?

nebelnoir писал(а):С портом пока не понятно. См. тему тут: https://github.com/gnea/grbl/issues/67

Только что оттуда. Поэтому и решил здесь уточнить ). Там как-то и правда непонятно. Этот Schildkroet сказал, что в текущем своем порте он только багфиксами занимается, а новые фичи (и оси) добавит, когда допилят порт на арм. И он, в свою очередь, портирует на F4.

продублирую собщение и тут, т.к. как я понял что этот контроллер сделан по большому счету аналогично.

Пощупал осцилографом Grbl1.1f. разочарование в нем.
$11 отвечает за точность на стыках. Я думал это будет радиусное сглаживание. По факту если =0 (близко к 0), то чистый старт-стоповый режим. Одна ось плавно остановилась, потом вторая плавно разгоняется.
Но.... если поставить значение достаточно большое, допустим 1, то будет вот что- одна ось РЕЗКО останавливается, вторая резко полетела (что на практике вызывает срыв ШД)

Руки-ноги не дошли сделать плату на STM32 и проверить осцилографом, поэтому интересуюсь как тут это сделано

atomichammer писал(а):Там, кстати, будет возможность подключения какой-нибудь периферии по какому-нибудь интерфейсу UART/SPI/I2C?

В железе будет.

Mamont писал(а):Но.... если поставить значение достаточно большое, допустим 1, то будет вот что- одна ось РЕЗКО останавливается, вторая резко полетела (что на практике вызывает срыв ШД)

Очень странно. Будем смотреть.

nebelnoir писал(а):Итак

xenon-alien писал(а):А есть ли возможность какой-то дисплей с управлением подключить к нему и чтение с карты памяти кода?

А у меня другой вопрос к автору: Есть ли возможность подключить пульт, который будет работать вместе с компом, а не вместо него?
Дело в том, что все пульты под ГРБЛ, что я видел в продаже, предназначены для воспроизведения Г-кода с карты памяти и управления движением инструмента/шпинделем с кнопок. НО! Только при отключенном компе.
Это меня не устраивает - хочется иметь пульт, который управляет инструментом и при этом и ГРБЛ-контроллер и управляющая программа компьютера точно отслеживали местоположение инструмента.
Спасибо!

Доброго здравия, господа.

Контроллер запущен в эксплуатацию на реальном автомате с 5 осями, пока все ок.
Есть еще интересный результат. Рещил поменять выводы и собрать под 6 осей. При этом в запасе остается интерфейс I2C или UART.

Что сделано:
поменял группу выводов для охладителей.
collant_mist_bit (B3) -> С14
collant_flood_bit (B4) -> С15
в даташите предупреждение, но все относительно, обычная логика и этого может не давать. В общем светодиод (vs оптрон) по схеме "с открытым коллектором" и тем более какой-нить шинный повторитель - не проблема.
На освободившиеся выводы концевики C и B
b_limit_bit (B11) -> B4
c_limit_bit (B10) -> B3
Таким образом освобождаются выводы B10 B11 для дополнительных интерфейсов USART3 или I2C2.

Неудобство по поводу SWD программирования решил так.
Перенес сигналы оси B.
b_step_bit (A9) -> A11
b_direction_bit (A10) -> A12
теряем USB порт, но приобретаем USART1, а это не только интерфейс для управляющей программы но и возможность пользовательского обновления прошивки. Правда придется оснастить usb serial переходником. Я работаю через CP2102.

Попробовал еще одну такую-же платку использовать в качестве usb serial моста вместо CP2102 - работает, надо еще отладить. Можно будет обновлять прошивку пользователем из управляющей ПО ибо такой переходник/управляющий контроллер может переключать режимы прошивки или работы, сбрасывать. В общем у меня на тесте пирог из двух платок.

Изменения прошивки минимальны - отключить использование USB и поменять некоторые пины и порты в cpu_map.h
Надо подумать как использовать освободившийся USART3/I2C2.

В общем - потестировал такую схему - работает. Как вариант на усмотрение.

Как дополнение. Оценил использование команды $J. В управляющем ПО при нажатии кнопок работает таймер.
Cлежением за количеством блоков в планировщиеке (у меня не больше 2), при установленных скоростью подачи, дистанцией подачи и таймером отлично настраивается непрерывное перемещение при удержании кнопки Jog.
Инерционность минимальна - X 1 или X 2 дистанции подачи. У меня при 5мм и при 1000мм в мин плавно едет.

Курдль писал(а):Есть ли возможность подключить пульт, который будет работать вместе с компом, а не вместо него?

GRBL - это только контроллер ЧПУ, функцию работы с пультом должна на себя брать интерфейсная часть. Например это реализовано в UGS. Там в качестве пульта используется веб интерфейс например смартфона, который подключается по ссылке сгенерированной UGS. В нашем коммерческом проекте мы использовали пульт whb04b-4, подключаемый по USB (беспроводной свисток) и взаимодействующий с написанным нами интерфейсом.

nebelnoir писал(а):GRBL - это только контроллер ЧПУ, функцию работы с пультом должна на себя брать интерфейсная часть

Спасибо!
Но на мой взгляд - это вопрос архитектуры, которая должна обеспечивать заданную функциональность.
Кто провел такие границы "GRBL - только контроллер"? И почему, например, кнопки "stop/cycle/resume" контролирует GRBL а кнопки "влево/вправо/вперед/назад" - компьютер?
Возможно ардуино не хотят обременять лишней нагрузкой? Или тупо не хватает портов для подключения кнопок?..

Всем доброго времени суток!
Подскажите возможно ли в прошивке grbl v1.1 запараллелить выводы Y и Z ??? У меня ось Y на двух моторах, подключать их хочу соответственно к выводам Y и Z на плате мега2560. Может это где уже разжевывалось, подскажите где посмотреть.
Спасибо.

Приветствую, всех.

В предыдущем посте упомянул про переходник usb2usart на базе такой-же платки. В целом ничего особенного, но при отладке выявились моменты по коммуникациям, которые могут быть интегрированы в этот порт grbl или последующие, ибо софт переходника это наследие grbl.
Как уже сказал - я долго не мучился и взял из grbl часть для usb и такую-же часть зеркальную для usart2. Такой обрезок получился.
1. Маленькие приемные буферы. Я сделал и для usb и для usart2 по 1024 байта (память и производительность контроллера позволяет, зачем ужиматься). Соответственно надо аккуратно изменить тип указателей(это не термин языка си, это индексы массива) головы и хвоста на uint16. Глобальные переменные ...head, ...tail, а также локальные смежные переменные head, tail и т.д. По исходящему буферу usb наверное тож можно сделать, тока быть аккуратнее (поинтерная работа непосильная для меня) ибо передатчик берет из этого буфера пакеты не более 64 байт и других ограничений не увидел.
2. В переходнике не использую, но оставил вместе с индикатором строки(моргалка диодом) Ярослава. Маленький буфер входящей строки. Можно довести до стандарта G-code и ставить 256 символов вместо 90. Я для страховки счетчик символов строки - "char_counter" тож перевел в uint16.
3. При программировании через uart (использовал стандартную утилиту от ST) выяснил что на одном из начальных шагов идет посылка символа 0xFF. В grbl этот символ идет для обозначения отсутствия данных. Не знаю для чего это было сделано, в общем - убрал его и функция чтения данных имеет вид uint8_t serial_read(uint8_t *data), где возврат 0-нет данных, 1-есть данные, а по указателю заполняю символ.
4. Утилита программирования от ST не хочет работать если не указать четность = EVEN. Это-же замечание есть и в описании протокола, хотя в том же документе (в другом месте) написано что контроллер в начале прошивки ждет 0x7f и сам определяет скорость, четность и т.д. И по факту контроллер работает и без четности (проверял на своей утилите). В общем для поддержки такого режима и стандартной утилиты изобразил следующее в самом начале функции OnUsbDataRx:
vcp_lc = Virtual_Com_Port_SetLineCoding(sizeof(LINE_CODING));
vcp_paritytype = (vcp_lc)->paritytype;
if (vcp_paritytype_prev != vcp_paritytype) {
vcp_paritytype_prev = vcp_paritytype;
// перестроим порт usart2
if (vcp_paritytype_prev == 0) {
USART2->CR1 &= ~USART_CR1_M; // 8 bit
USART2->CR1 &= ~USART_CR1_PCE; // disable parity
}
else {
USART2->CR1 |= USART_CR1_M; // 9 bit
USART2->CR1 |= USART_CR1_PCE; // enable parity
if (vcp_paritytype_prev == 1) {USART2->CR1 |= USART_CR1_PS;} // ODD
else {USART2->CR1 &= ~USART_CR1_PS;} // == 2 EVEN
}
}

В описании:
uint8_t vcp_paritytype;
uint8_t vcp_paritytype_prev;
LINE_CODING* vcp_lc;

Гуру могут меня поправить если криво, думаю мысль понятна.
Такая функция сработает один раз после первого принятого пакета от usb после соединения и настройки usart2 можно менять на лету не боясь потерь.

Возможно что-то из этого будет полезно для этого grbl порта.
Вообще жду новой версии GRBL и новых портов . Недочеты есть и чего-то не хватает.
Например сделал кнопку EStop в управляющей программе. По фукционалу самый раз команда двери безопасности, но в статусе видим - DOOR. Т.Е. все прекрасно работает - чисто эргономика, гадай потом или у меня палец на мышке дрогнул или реальный датчик сработал. Не понравилось триггерное отображение шпинделя в строке отчета. Мало ли я чего пропустил или чего-то нажал - хочется видеть постоянный статус, ведь у пробников нормально сделано.
Оно мелочи но хочется по человечески.
Ну как-то так. Всем удачи.

здравствуйте. проект жив? развиваться будет? когда продолжение?