ПОМОГИТЕ Постпроцессор для платы woodpecker cnc camxtool v3.4

[SnakeKVC]

Ну так ГРБЛ работает не само по себе, а через какой-то софт.

ГРБЛ не волнуют проблемы другого софта.
По Вашей логике, если глючит холодильник то не надо телевизор смотреть.
Программист ГРБЛ и программист Candle друг за друга не отвечают.

 

[val013]

ГРБЛ не волнуют проблемы другого софта.
По Вашей логике, если глючит холодильник то не надо телевизор смотреть.
Программист ГРБЛ и программист Candle друг за друга не отвечают.

А как вообще в прошивке организован обмен по порту? Там JSON или что то другое? Просто интересно.

 

[SnakeKVC]

А как вообще в прошивке организован обмен по порту? Там JSON или что то другое? Просто интересно.

Всё написано на С++
Исходники открыты, смотрите изучайте.

 

[val013]

Всё написано на С++
Исходники открыты, смотрите изучайте.

Изучить, конечно можно. Но здесь речь зашла о тормозах при больших файлах. Хотел было тоже подумать за возможные звенья таких тормозов, но для этого заняться изучением чужих исходников пока не готов - думал мож кто уже изучил и сможет на простой вопрос ответить.

 

[SnakeKVC]

Изучить, конечно можно. Но здесь речь зашла о тормозах при больших файлах. Хотел было тоже подумать за возможные звенья таких тормозов, но для этого заняться изучением чужих исходников пока не готов - думал мож кто уже изучил и сможет на простой вопрос ответить.

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

// Serial send and receive buffer size. The receive buffer is often used as another streaming
// buffer to store incoming blocks to be processed by Grbl when its ready. Most streaming
// interfaces will character count and track each block send to each block response. So,
// increase the receive buffer if a deeper receive buffer is needed for streaming and avaiable
// memory allows. The send buffer primarily handles messages in Grbl. Only increase if large
// messages are sent and Grbl begins to stall, waiting to send the rest of the message.
// NOTE: Grbl generates an average status report in about 0.5msec, but the serial TX stream at
// 115200 baud will take 5 msec to transmit a typical 55 character report. Worst case reports are
// around 90-100 characters. As long as the serial TX buffer doesn't get continually maxed, Grbl
// will continue operating efficiently. Size the TX buffer around the size of a worst-case report.

//#define RX_BUFFER_SIZE 128 // (1-254) Uncomment to override defaults in serial.h
//#define TX_BUFFER_SIZE 100 // (1-254)

 

[extrimus]

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

// Serial send and receive buffer size. The receive buffer is often used as another streaming
// buffer to store incoming blocks to be processed by Grbl when its ready. Most streaming
// interfaces will character count and track each block send to each block response. So,
// increase the receive buffer if a deeper receive buffer is needed for streaming and avaiable
// memory allows. The send buffer primarily handles messages in Grbl. Only increase if large
// messages are sent and Grbl begins to stall, waiting to send the rest of the message.
// NOTE: Grbl generates an average status report in about 0.5msec, but the serial TX stream at
// 115200 baud will take 5 msec to transmit a typical 55 character report. Worst case reports are
// around 90-100 characters. As long as the serial TX buffer doesn't get continually maxed, Grbl
// will continue operating efficiently. Size the TX buffer around the size of a worst-case report.

//#define RX_BUFFER_SIZE 128 // (1-254) Uncomment to override defaults in serial.h
//#define TX_BUFFER_SIZE 100 // (1-254)

Но ведь этот буфер пополняется наверно с одной скоростью что при малом размере УП, что при огромном? Где-то кто-то помню тут писал, что УП передается куда он должен передаваться не весь сразу, а порциями. Т. е тупить не должно, а большие УП тупят.
А по большому счету большинству по барабану вся эта кибенематика пополнения буферов. Большинство больше интересует почему тупит при большой размере УП.

 

[SnakeKVC]

Но ведь этот буфер пополняется наверно с одной скоростью что при малом размере УП, что при огромном? Где-то кто-то помню тут писал, что УП передается куда он должен передаваться не весь сразу, а порциями. Т. е тупить не должно, а большие УП тупят.
А по большому счету большинству по барабану вся эта кибенематика пополнения буферов. Большинство больше интересует почему тупит при большой размере УП.

Тупят не большие УП а софт который с УП работает. Если например Candle пытается отрисовать поверхность очень сложную для визуализации и у него мозги съезжают, то ГРБЛ тут ни при чём.

 

[demyuri]

Большинство больше интересует почему тупит при большой размере УП.

Это уже для отдельной темы вопрос. Постпроцессор здесь ни при чем. ГРБЛ, как мне кажется, не может тупить, скорее всего тупит софт на компе или сам комп.

 

[OlegK]

Как работает прошивка GRBL.
УП передаётся построчно через UART контроллеру. Контроллер имеет буфер на 128 символов (буфер UART) и буфер планировщика на 16 линейных команд перемещения. При разборе корректной команды, контроллер помещает её в планировщик и отправляет управляющему софту ответ ОК. Или error с кодом ошибки, если команда некорректна.
Управляющий софт может выполнять отправку строк двумя способами:
1. Отправил строку-ждёт ответа. При этом буфер UART задействован лишь на короткое время, до разбора содержимого и помещения команд в планировщик. При таком способе, если УП содержит много коротких и быстровыполняемых станком команд, любой затык передающего софта может вызвать работу станка рывками из-за опустошения планировщика. Поэтому, есть способ 2.
2. Этот способ основан на подсчёте количества символов, передаваемых станку и призван поддерживать буфер UART всегда наполненным. Таким образом, планировщику всегда есть, чем заняться. Т.е. отправили строку, смотрим, влезет ли следующая и отправляем, если влазит. И.т.д.

В своём оффлайн контроллере я пробовал оба способа передачи, но остановился на первом. Учитывая, что контроллер всё успевает и не выполняет иных задач, то ни голодания планировщика, ни подтормаживания отмечено не было, а со вторым способом, при паузе с отключением станка, приходилось ждать, пока опустеет и буфер UART и буфер планировщика. Иногда это может быть довольно долго.

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

 

[DDE-f]

Ну, или рубить УП с миллионами строк на части.

энсистудия пару лет назад спокойно переварила уп-эшку почти под гигабайт, около 900 мегабайт было на чистовой, станок пилил панно 2х3 метра с мелким рельефом более двое суток, не поперхнулся ни разу! правда это была NcStuio 10 Lambda , около 300 тыс-руб за платку...

 

[DDE-f]

правда это была NcStuio 10 Lambda , около 300 тыс-руб за платку...

справедливости ради должен отметить, что и древняя, как каки мамонта энсистудия 5.6 спокойно переваривает 300-400 мегабайт уп-эшку!
по теме топика - после внедрения в постпроцессор круговой интерполяции свечка задурила и вместо правильной гравировки пошли кракозябры... к свечке есть ещё много предъяв, но это позже выложу.
а слегка выправленный постпроцессор (уменьшил форматы до 1,2 - то есть координата описывается, к примеру, вот так Х1.11) выложу не в этом посте, здесь не подшить... кому будет интересно по различиям - "вес" уп в зависимости от стратегии обработки падает в 2-3 раза, ну как то так, примерно.