search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.08k stars 1.61k forks source link

A question about usage of planner buffer #1019

Open e-zeki opened 3 years ago

e-zeki commented 3 years ago

Hello, I'm fairly new in GRBL world. I've made a 3 Axis machine for myself with this ARM build here https://github.com/robomechs/6-AXIS-USBCNC-GRBL I've implement a streaming GCode routine in order to fill both RX buffer and Planner buffer efficiently and make it run smooth, it works great most of the cases. I look how many bytes are available in RX buffer than I look Planner buffer how many moves I can send then I both substract line bytes and 1 movement from planner buffer as well. But I run into some faulty movements especially after an arc or a curved carve moves. I realized while linear Gcode lines are consuming 1 planner buffer spot, Arc movements or circle lines consumes more than one spot when I stream. Is it random how much spot a line can consume in planner buffer or is there a consistent number here? Any clarificatioun would be great Best regards Zeki

langwadt commented 3 years ago

why don't you just keep the RX buffer full?

e-zeki commented 3 years ago

I know RXbuffer doesnt freed up until planner looks inside and lets it ok to be queued, I experienced some weird behaviour when I only check RX buffer status. Like I said before, especially curved movements (when GCode meets IJK ) it skips some parts of the moves. for example 3/4 of a circle is good and suddenly it crosses a line through starting point of the circle. so I added planner buffer in to consideration too. I realized planner buffer cosumes variable spots for curved moves. I limited my buffer fillnes up to 25 spots (default is 35) let 10 spot free all the time, I saw response message returns Bf:0,254 sometimes even I let 10 buffer space freed it still fulls it some how and RX buffer comes empty so I send some lines with it but it skips a line or wrongly execute some weird line and continues to work correctly. I raised the free spots to 25 and it stopped wrong movements but still sends Bf:3,254 or even Bf:0,254 again. I thought if I knew how many buffer spaces require for a certain movement type I'd keep track of the projected buffer spots to be used so I can manage to control the line flow better.

langwadt commented 3 years ago

just keep the RX buffer full and the planner will happily consume as needed, if that doesn't work there must be something else wrong in the communication