Страница 2 из 2

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 10 мар 2021, 20:40
Leha_
shura2 писал(а): 10 мар 2021, 18:14 А что с буфером? как идет контроль его переполнения?
Последовательный порт, если про него идет речь, в стандартных 64 байта в полне хватает, по крайней мере лично я, с его переполнением при обычной работе программы (с отрисовкой каких-либо служебных данных, графики, т. е. с попутным выполнением кода на который необходимо затратить некоторое время контроллера) не сталкивался.

Однако, если тупо заваливать командами одну за другой GRBL на Arduino UNO, то через некоторое время UNO не успевает их отрабатывать, и выводит в ответ "ERROR" (при этом станок сходит с ума, начинает чудить, едет куда попало ... и тому подобное), похоже тут и появляются проблемы с буфером.
Стандартный режим отправляем команду --> ждем ответ --> отправляем следующую --> ждем, и так в цикле, почему то не работает (ломал долго голову, вроде алгоритм правильный, код нормальный, и все должно работать, но нет). Выход нашел примитивный - установка паузы delay(X), после каждой оправленной в буфер строки с командами, где X не мене чем 40 мск. Проблема сразу ушла, ошибок не выдает.

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 12 мар 2021, 01:05
shura2
Leha_ писал(а): Стандартный режим отправляем команду --> ждем ответ --> отправляем следующую --> ждем, и так в цикле, почему то не работает (ломал долго голову, вроде алгоритм правильный, код нормальный, и все должно работать, но нет). Выход нашел примитивный - установка паузы delay(X), после каждой оправленной в буфер строки с командами, где X не мене чем 40 мск. Проблема сразу ушла, ошибок не выдает.

т.е. "ок" приходит сразу, выполнена предыдущая строка или нет? мне задержка не подходит - строка может выполнятся 5-20 секунд.

я поставил условие, отправлять строку, только если статус idle и ждать, если Run. но периодически заметны подтупливания - пока считает статус, потом строку с флешки, пока отправит. вообщем нет плавности. надо подгружать в буфер по несколько строк к текущей, пока туплю как это сделать.

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 12 мар 2021, 07:37
Leha_
shura2 писал(а): 12 мар 2021, 01:05 т.е. "ок" приходит сразу, выполнена предыдущая строка или нет?
Всегда считал, что ответ приходит после выполнения команды... Ваш вопрос заставил задуматься.
Сегодня вечером проверю, как происходит на самом деле.

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 12 мар 2021, 21:46
Leha_
shura2 писал(а): 12 мар 2021, 01:05 т.е. "ок" приходит сразу, выполнена предыдущая строка или нет?
Проверил .. ответ "ок" приходит сразу после получения команды... GRBL проверяет синтаксис команды, если все нормально выводит "ок", не зависимо закончилось выполнение или нет.

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 12 мар 2021, 22:09
Leha_
shura2 писал(а): 12 мар 2021, 01:05 я поставил условие, отправлять строку, только если статус idle и ждать, если Run. но периодически заметны подтупливания - пока считает статус, потом строку с флешки, пока отправит. вообщем нет плавности. надо подгружать в буфер по несколько строк к текущей, пока туплю как это сделать.
Может поможет проверять условие в статусе не после каждой строки, а например через 5, 10, 20 и т.д. строк (оправить пакет строк и ждать статус idle). По идее должно сработать.

Re: Управление самодельным лазерным гравером посредством Arduino Mega с TFT дисплеем

Добавлено: 13 мар 2021, 11:34
yurayerz

Написание интерфейса для Grbl
гуглоперевод писал(а):Здесь мы опишем два разных метода потоковой передачи для графических интерфейсов Grbl. Одна из основных проблем со стримингом в Grbl - это сам USB-порт. Arduinos и большинство микроконтроллеров используют микросхему преобразователя USB-to-serial, которая иногда ведет себя странно и не совсем так, как вы ожидаете, например, буферизация пакетов USB и задержки, которые могут нанести ущерб протоколу потоковой передачи. Другая проблема заключается в том, как справиться с некоторыми задержками и странностями самих ПК, потому что ни один из них не работает в реальном времени и всегда создает микрозадержки при выполнении других задач. Несмотря на это, мы придумали способы обеспечить надежность и простоту потока G-кода.

Следующие ниже протоколы потоковой передачи требуют отслеживания ответных сообщений, чтобы определить, когда отправлять следующую строку g-кода. Все push-сообщения не учитываются в протоколе потоковой передачи и должны обрабатываться отдельно. Все символы команд реального времени могут быть отправлены в любое время и никогда не помещаются в последовательный буфер RX Grbl. Они перехватываются по мере их поступления и просто устанавливают флаги для Grbl, чтобы их выполнить.