
В таком случае разбор бы заканчивался либо вызовом подпрограммы расчета движения согласно типу действия и затем выходом из обработки строки,либо непосредственно выити уже сделав соответствующие установки системы.
Я больше всего работал с промышленными стойками, там, за исключением какого-нибудь совсем древнего Фанук 6м (у которого буфер на один кадр) предпросмотр (и сооьветственно, синтаксический разбор) на десятки кадров. например, у Heidenhain 426, если не ошибаюсь, предпросмотр 80кадров, и это очень важно, например, при ВСО, где опорожнился буфер и встала фреза- деталь на выброс. А стойке, на которой я работал черверть века стукнуло, и пашет до сих пор. А разрабатывали её, естественно, ещё раньше.
Конечно, можно. Но получится монолитное решение. А в монолит отдельные доп. модули уже не внедрить. Я, к примеру, сейчас добавляю код разбора параметров внутри строки. И вижу, что разбор параметров это задача, которую можно сделать полностью отдельной функцией. И разбор комментариев надо сделать отдельной функцией, т.к. в комментариях могут быть команды, не связанные с G кодом. Всё это даст системе возможность выбора. А в монолитном подходе выбора нет, все параметры и комментарии будут разобраны в любом случае, надо это или не надо.
Если под фразой "устаревшие подходы" подразумевается использование С/С++ в критичных по времени задачах, я, пожалуй, буду придерживаться устаревших
Не понятно почему.Потом ,зачем внедрять доп модули,парсер всетаки достаточно стандартное решение.А простые расширения ввиде различных новых G и M кодов легко дописываются и вставляются а текст.У меня для расширения и обработки сложных циклов сделано так,что после просмотра всех возможных g кодов и при отсутствии кода в готовых идет поиск дополнительных кодов,которые выполнены в виде подпрограмм находящегося на флешке в файле functions.ini и при включении системы перегружаются с флешки в озу системы при этом для ускорения обработки расчитываются адреса начала каждой подпрограммы.Подпрограммы именуются номерами кодов (например подпрограмма с О500 будет вызываться кодом g500.Таким оьразом можно создавать G кода для сложной обработки например многопроходной резьбы или проточки .Точно также устроена обработка смены инструмента так как в подпрограмме можно написать условия по опросу портов и их установки.
Такой подход как раз и противоречит модульному подходу (из Unix Way). В итоге может получиться огромный комбайн в виде одной функции, которая делает всё - и играет, и пляшет, и поёт, и ещё немного вышивает крестиком.
Я с этим не спорю.Просто на выходе хотелось бы получить не перемолоченный код , а вызов определенной функции движения (g0,g1...)по окончании обработки строки и внутри обработки вызов установочных функций(g90,g91,g42,...) .Какой смысл перелопачивать код для получения его в более удобном для обработки виде,если все равно придется снова затратить время для его обработки и в итоге на выходе все равно получим вызов функции (g1,g2....)?Не оптимально,да и не вижу удобств для работы в команде.Чем первый вариант менее удобен?
https://aliexpress.ru/item/1005004607691148.htmla321 писал(а): ↑ Наверняка сочтете, что не в тему, но поднимать новую не стоит -
https://habr.com/ru/company/timeweb/blog/707410/
плата со 128 входами и выходами, опторазвязанными
Так и будет, но этими вызовами заниматься должен не парсер G кода, а планировщик. А если мы используем парсер G кода для визуализации, то вызовами функций будет заниматься визуализатор. При этом они оба используют один и тот же модуль разбора G кода, но каждый - для своих задач. Вот здесь выигрыш и будет.
Код: Выделить всё
// setup buffers
from = str1; to = str2;
// parse and replace parameter values, #n and #<NAME>
parameters_cnt = gcode_parse_parameters(from, to, &gdata);
if ( parameters_cnt > 0 ) { from = str2; to = str1; }
// parse and remove comments, (...) and ;
comments_cnt = gcode_parse_comments(from, to, &gdata);
if ( comments_cnt > 0 ) { from = str1; to = str2; }
// parse, calculate and replace expressions, [any math]
expressions_cnt = gcode_parse_expressions(from, to, &gdata);
if ( expressions_cnt > 0 ) { from = str2; to = str1; }
// parse and remove parameters setup, #n=n and #<NAME>=n
parameters_setup_cnt = gcode_parse_parameters_setup(from, to, &gdata);
if ( parameters_setup_cnt > 0 ) { from = str1; to = str2; }
// parse words, Gn Mn Xn Yn ...
words_cnt = gcode_parse_words(from, &gdata);
Я никогда не использовал планировщик,поэтому не очень представляю ,как он работает.А разве нельзя запускать планировщик при вызове функции (например G1)непосредственно внутри подпрограммы G1?
А разве визуализатор не использует те же функции,просто при движении не только делая шаги,но и ставя точки на экран?
У меня рисовалка просто отображает текущую координату движения в трехмерном пространстве.Но это работает только наполный стол станка и без перерисовки т.к отображается прямо на экране и не имеет буфера в озу.Если надо быстро предварительно просмотреть программу,то программа выполняется полностью за изелючением того,что шаги делаются не по прерыванию таймера ,а подряд насколько позволяет скорость процессора.Ну и шагов на драйвера не поступает,только виртуальные.Но это пока иногда глючит.Пользуюсь редко.
В данном случае, это он и есть. Просто, его функционал не так велик, как в других системах.
Есть такая вероятность. Но работы еще много. Примерно половина.
Платы, сервопривод который кушает многое из датчиков видел? Ты наверно не в курсе что делает DP Lab.