Здравствуйте。

1. Пробовали ли сборку из可视化不工作 #64？
2. Попробуйте увеличить период опроса состояния GRBL。

только что попробовал 64 и 64.1。как минимум при закрытии вылетают обе при обращении по 14h адресу гдето в ig4icd32.dll

mov eax,dword ptr [eax+14h] ; eax == 0

не могли бы вы выложить дебуг сборку актуальной версии для посмотреть где сбоит？на вин машине у меня нет qt，она перегружена и если есть возможность не ставить это будет лучше。

Отладочная версия: https://drive.google.com/file/d/0B4vTX7JEeIAYWFp0cnRmeklBOEk/view?usp=sharing

#64 идет стабильнее за последний день ни разу не вылетела при работе。хотя, с нераспознанными гкодами надо чтото делать. приостанавливаться и показывать этоткод в редакторе чтоб поправить и продолжить или просто продолжить?

еще интересна возможность запускать гкод с произвольного места, скажем, с курсора в редакторе (например, при сбое чтоб не гонять шпиндель вхолостую).

отладочнуюзавтрауже。

дебуг версия тоже не вылетает в середине отправки。возможно, дело в оптимизаторе? чтото лишнего удаляет?

возможно, дело в оптимизаторе

Сложно сказать без локализации ошибки. Проблема то видео-драйвере от Intel。Обновлен?

с нераспознанными гкодами надо чтото делать

Ответил здесь: #69（评论）

еще интересна возможность запускать гкод с произвольного места

Согласен，хорошо бы реализовать。

Сложно сказать без локализации ошибки。Проблема то видео-драйвере от Intel。Обновлен?
драйвер последний с сайта леново。посмотрю более новые, но есть 2 соображения。

1. вылетает только во время отправки команд。
2. дебуговая версия не вылетает при работе уже несколько дней。только при выходе из сендера, что не так важно。

насчет локализации ошибки – случайное время возникновения лично мне напоминает ошибки динамической памяти。

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

ловить такие ошибки непросто。
для ловли выделения памяти под линем есть волгринд, но под моим арм-линем этого сбоя нет。еще можно разбить программу на куски и запускать в разных комбинациях, особенно удобно если делать изтри. не надо перекомпилировать каждый раз。

оптимизация -О2 элиминирует заголовки функций и более агрессивно переменные。может，попробовать -О1？у вас не используеся самоотладка? ей нужны заголовки。

чувствую，я и сам гадаю и вам голову морочу。надо или ставить qt и смотреть самому или успокоиться, что дебуг версия болемене работает。

Согласен，хорошо бы реализовать。
еще можно с произвольного места и произвольные участки。еще можно доп датчики。например, не остановился ли шпиндель (сбой питания, завяз в материале итд)?
токо делать это уже когда будет скрипт энжин。почему？- потому что скорость, цена и сложность написания-отладки на скрипте на 3 порядка меньше。

почему луа а не жс (лично для меня)？

• хотя это скрипты примерно одного порядка
• луа очень прост как сам синтаксис, так и его исходник, так и техника его ембеда екстенда。
• достаточно мощен。там есть таблицы и хэши и обьекты с наследованием и перегрузкой операций。故事。лямбда функции。
• диктует более строгий и читаемый стиль。хотя, конечно, не питон.
• есть модуль встроенного дебуггера。
• при встраивании можно подцепиться из С к любому типу данных, операции, вызову. причем，делается это просто。
• весьма неплохой гц。можно указывать области видимости гц, можно запускать гц вручную (например, при простое)
• имеет одну из самых быстрых вм (не классическую стековую)。есть жит компилирующий вариант (luajit)。причем, сама вм как и весь сорец небольшие и написаны хорошо и читабельно。
• это основной скрипт для игр。те он отлажен тысячами игрушек начиная с 90х。e l°仑。
• еще 1 предпочтение для меня – опыт. опыт написания скриптов, встраивания, изменения сорцов самого языка. такчто я немного предвзят。жс не люблю изза веба。потому трудно судить。
• широкая известность жс и преподаваемость в школах как + так и -. с одной стороны, это привлечет людей, с другой стороны, сильно либеральный синтаксис простимулирует небрежное, нечитаемое и неотлаживаемое программирование.
  синтаксис луа похож на жс, но имеет небольшой шаг в сторону паскаля и не разрешает безалаберный стиль жс。
  дока по луа изучается за полчаса。
• структура с плугинами:
• вначале это просто замена конфигу (сами плугины будут просто модулями луа. как на луа, так и на с/с++)。
• ближе к концу – прослойка между интерфейсом и С(++) обработчиками。это позволит упростить и отладку и добавление функционала по мелочи。например – останавливать или не останавливать по ошибке? какие команды посылать при нач инициализации? алгоритм управления с клавы (или джойстика)。итд
• еще ближе к концу – в машкоде остаются только части требующие скорости。например, парсер гкода, визуализатор, еще что будет тормозить.
• опционально, не знаю как оно счас, парсер гкода переписан под парсергенератор. гкод счас развивается。так будет проще дополнять парсер。

сам код программы, особенно поначалу, менять не надо。интерфейс к скрипт энжину это отдельный файл с дергалками уже имеющихся функций

Поддержка скриптов была-бы не лишняя, т.к. я планирую сделать контроллер на stm32, с таким-же протоколом grbl, только с расширенным функционалом и опциями, и использовать этот сендер, а не переписывать свой, т.к. времени свободно сейчас мало。

луа

Есть ли примеры интеграции в Qt-проект? Работаютлисниммеханизмсигналов/слотов？

замена конфигу

Боюсь, что конфигов сейчас нет。

вмашкодеостаютсятолькочаститребующиескорости

Что-то питоном да ктквиком пахнуло。Не очень нравится этот подход, рано или поздно приводит к переписыванию всего и вся на машкод。

дергалками уже имеющихся функций

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

В целом, с оглядкой на список желаний (таких как: модульность, дополнительные функции, различные режимы (лазер, 3d-принтер, фрезер и т.д.), поддержка различных прошивок), нужно сперва разработать и реализовать подходящую архитектуру ПО. Впротивномслучаебудетмучительнобольнодвигатьсядальше。

По вопросам, не относящимся к изначально описываемой проблеме, предлагаю переехать в #69。