Buffered, or Synchronous? - That is the question.
I use Smoothieboard with cluster fw.
Going over all settings after upgrading to 0.9.18 and I see my Transfer mode is set to Synchronous.
Since I couldn’t find any help about these two modes i decided to create a new device and this newly one created by 0.9.18 is set to Buffered.
So, which one should I be using?
Buffered is much faster.
For the record, buffered does not work for my setup. after just couple of scan lines (repeatable, ran few tests) smoothieboard halts, stays busy and i must physically disconnect and reconnect the usb cable for it to get out of busy state (right clicking devices or resetting from console does nothing). back to synchronous mode now.
0.9.18, Win10/64/i5/16gb ram.
Are you running a CNC build of Smoothieware, or something else? (LightBurn assumes the CNC build)
Running this version
version
Build version: edge-54d22942, Build date: Jun 5 2019 14:09:26, MCU: LPC1768, System Clock: 100MHz
CNC Build NOMSD Build
4 axis
mem
Unused Heap: 14044 bytes
Used Heap Size: 12324
Allocated: 10660, Free: 632
Total Free RAM: 14676 bytes
Free AHB0: 10164, AHB1: 10440
Block size: 96 bytes, Tickinfo size: 168 bytes
Please let me know if I’m using the latest and greatest firmware and how can buffered mode work for me. my wish is to always have my controller and the whole system tuned for best results/speeds/reliability possible.
That’s the same firmware I run, but mine is on the LPC1769 board, running at 120 MHZ. It’s not impossible that’s the problem - it was written and tested on the faster chip.
LPC1769 based controllers are only $21 usd and 60 sec swap to my current 1768 so if buffered is much faster and works on 1769 then i might just pull the trigger and upgrade, that is if i only knew for sure that 20% slower micro-controller is actually the culprit.
how much is “much faster”?
I am sticking with Smoothie just because it runs on LPC and there is this cluster firmware of yours.
i have asked before but never got an answer - will i gain better performance running a grbl-stm on Core4 168Mhz controller? (there are actually Core7 400mhz controller coming up soon as well). i don’t know if grbl-stm have this cluster thingie included or even without it will run much faster than cluster on 120mhz? i guess cluster, regardless which gcode interpreter is used - is more than welcome and a must have.
So I’m using a LPC1768 on a smoothieboard clone (https://www.amazon.com/gp/product/B082X5N2YS) with marlin firmware compiled in laser mode and it works great, you should be able to slap it on any smoothieboard/clone/etc to try it out.
forgive my ignorance, does Marlin supports Lightburn’s Cluster mode?
And are you saying buffered transfer mode is working for you without any issues?
Interesting.
I can’t say i love Marlin but if it works at least as fast if not faster than Smoothie’s cluster mode for fast rasterizing, then i will give it a try.
Oh sorry I’m not familiar with cluster mode, I didn’t realize this was a feature with lightburn/smoothieware, it doesn’t come up in lightburn as an option for me. I just use buffered mode with my board with both vectors and raster.
Marlin seems to be working for me with raster, but I’ve never tried anything else so I have no better/worse comparison maybe it’s terrible and I don’t realize it. Just figured marlin’s free so its worth a quick try?
Thank you. I believe this is a valuable information for Oz as it seems like Buffered mode is not related solely on the controller in use and it might just be the implementation in Lightburn.
Hi Oz,
Following my discussion here above with @rvarone, i ran a test where lightburn
Cluster mode is OFF
Transfer mode is set to Buffered
with this configuration there were no communication issues. it does look like laser head is not moving as smooth as in cluster & synchronous combo but no communication errors during 200mms/300dpi rasterizing.
Just FYI.
“Buffered” means that we send data whenever there is room for it in the receive buffer of the controller, regardless of whether the controller has sent back ‘ok’ responses or not.
“Synchronous” means that we send a single line of GCode and wait for the ‘ok’ for it before sending the next one.
All controllers will push code into a block queue for motion planning, so there is an internal buffer that holds some number of moves in advance of what’s actually being executed. The serial receive buffer is ‘unprocessed data’ - just raw GCode commands that haven’t been read yet.
If you wait for the ‘ok’ command to arrive, it takes a moment for the USB buffering system to transfer it, then a moment for my receive thread to wake up and read it, then I’ll put the next command in the send buffer, and then there’s a short lag for that to be sent via USB, and another for the other end to stream that packet from the USB buffer to the device. All of these are short, but they add up.
In buffered mode, I know how much data the target system can hold in its serial receive queue, so I just keep it as full as I can, and keep track of how big each line I sent was. When I get the first ‘ok’ reply, I know that the first line I sent was processed, so I can assume that much space is now free again in the receiver buffer. The next ‘ok’ is for the 2nd line I sent, and so on. Doing this means that the controller is never sitting idle waiting for me to send more data - it always has a few commands ready to go, buffered up.
Smoothieware uses very computationally expensive math in the motion system, much more so than GRBL, so processing a single G0 or G1 instruction is more expensive than with GRBL - Smoothieware can do about 800 to 1000 per second, whereas GRBL-LPC can handle about 2500. Cluster mode takes advantage of the fact that raster images use GCode that moves in long straight lines, but constantly changes the power over those lines. Rather than sending one GCode instruction per dot, we draw longer lines that cover multiple dots, and include multiple power settings to distribute along that line
For the purpose of motion planning it’s all a single GCode instruction, but it can represent up to 8 dots, allowing us to process up to 8x as many image dots as before. Some of that gets consumed by more overhead in the GCode parsing, and I also increased how often the laser output gets updated (4000 times per second instead of 1000) to allow it to make use of the higher speeds.
The cluster changes are specific to Smoothieware, mostly because it was the platform that needed the help the most. GRBL-LPC was already that fast.
That was a very good read.
Thanks for taking the time to submit this all at once and not sentence by sentence while waiting for me to replay with an “OK”…
I see more and more Core4 Core7 STM based gcode interpreters out there and I know there is a grbl-STM flavor that should run on these so it looks as though it’s time for me to start learning about this combo. I just need to know others are running this combo successfully with lightburn before i take the plunge.
I will start by installing grbl-lpc on my 1768.
I Was searching for grbl-lpc just to find so many branches and repositories and it’s almost impossible to know which is which. not only that , but the one i found is for 1769 so i was wondering if it will work on 1768 just to fall on this statement instead:
“SKR boards don’t work, because pin mapping is messed!”
running smoothieware so i mapped all pins by myself using the config file so i am not sure why i can’t do the same with grbl-lpc.
Too messy.
Hi Oz,
following your elaborated and hightly appreciated comment and how faster grbl is in comparison to 1768, i searched the web trying to learn as much as i can on this subject. i am considering upgrading my 1768 SKR running cluster with this board which will run the stm32 flavor of grbl.
https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=202696044294&_sacat=0
I would appreciate your insights and what you have to say about this move and what will i gain/lose in the process.
Many Thanks.
I’m not familiar with that board, or the STM version of GBRL (aside from the ‘Gerbil’ port of it). I’ve only used the C3D running GRBL-LPC.
I see, or do I?..
I thought C3D runs only smoothie. I stand corrected.
This grbl thingie is very confusing. i failed to find the configuration file to map pins to my board. it looks like this information is hidden from us humans. the more i read the more i see users are running grbl predefined for specific hardware and firmware but I would like to configure grbl for my board.
Smoothie, with all its limits, is very easy to configure.
I don’t know why anyone should get lost like I am while tying to find so basic information for how to setup grbl on 1768/1769 based controller - regardless the manufacturer. it took me couple of hours to port two printers from Makerbase MKS controllers to BTT SKR controllers - both based on LPC1768 but different layout and pin assignment and still it was so simple to edit smoothie config file.
I will never modify anything without having all information tools and electronics ready beforehand and I don’t feel that’s the case with grbl. so many branches, so many versions, so many forums and I can’t see the wood for the trees.
Care to share your setup and/or a link to how to configure grbl-lpc for specific controller/pins?
I was searching and posting about this subject in this forum’s grbl’s hardware section but did not get any reply.
cheers.
I didn’t set it up - I bought a C3D board, and it came with both options. GRBL pin configs are set at compile time, so you would have to edit the pin map in the header file, then compile it.
The pin settings are in this file: https://github.com/gnea/grbl-LPC/blob/master/grbl/cpu_map.h