Buffered vs Synchronous mode

LightBurn Hardware Compatibility
1

I have been having communication problems with a Creality Falcon2 22W laser, and it turns out the problem was the Transfer mode setting. It was set to Buffered, and I have many instances of buffer overrun. When I changed it to Synchronous, all worked perfectly.

There is an explanation of Buffered vs Synchronous mode in topic [What is Buffered vs Synchronous Transfer Mode] but it leaves many questions unanswered. By my reading of it, my engraver should work in either Buffered or Synchronous mode. It doesn’t. It only works in Synchronous mode. Am I missing some other setting that would allow it to function in Buffered mode?

2

You might have interference on your USB cable or a bad cable itself
Synchronous works, but will slow down your engraving by a full order of magnitude.
Try swapping the USB cable or, just to be sure is not environmental, try a dfferent location in your house

3

I do not believe it is interference for several reasons.

  1. When I have buffer overflow, it is always EXACTLY in the same place. Random interference would not behave this way.
  2. I believe the USB cable is heavily shielded. It is very stiff to bend because of aluminium shielding.
  3. I have put large ferrites on either end of the USB cable with several turns of USB cable through the ferrite.

I have not noticed any slowdown of engraving in synchronous mode. The mechanical movements of the engraver are WAY slower than the serial data stream.

4

Unfortunately, consumer-grade cables are more likely to be stiff due to thicker PVC insulation (cheap), rather than internal material quality (expensive). This seems particularly true of the USB cables packed with laser machines, where unit cost pushes all other criteria out of consideration.

A few examples of what goes on inside good-looking cables:

Also, USB communications can crash due to failing connectors on the cables or PCBs on either end. The fact that it crashes dependably means the same circumstances happen during the same sequence in the same collection of G-Code.

AFAICT, Creality uses a modified version of Marlin, which diverged from GRBL long ago, back in the early days of 3D printing, when machines were slow and G-Code senders primitive. It’s possible the Creality firmware version in your machine has an error buried deep inside the serial handler, which wouldn’t be at all surprising.

What we think is happening probably isn’t and the way we expect things to work is never how they behave.

Bottom line: if it hurts when you do that, don’t do that. :grin:

Also: good callsign! :satellite:

5

It should be. Buffer Overflow means the memory storage space (buffer) in the controller board was sent data bytes faster than it could process them out (think circular buffer) The controller has to act on each command before it can retrieve the next from the buffer. Synchronous means the controller tells the source when it is okay to send more data. This is basically a full bi-directional handshake. A little slower yes, but the buffer is happy.

The real description should say Asynchronous vs Synchronous, meaning I can process it as fast as you can send it vs I cannot.

Ditto on the call sign. kv0oom here.

6

I understand the mechanism of buffer overflow. The question is - why is it happening? With buffered operation there needs to be some sort of flow control. This could be xon/xoff or DTR. My question really is - how do I configure Lightburn for correct operation in buffered mode, with a Creality Falcon2 laser?

7

you were told to try a couple things to eliminate some variables

Many users been using creality without any particular special configuration
so you have a envoriomental/OS/Machine issue that you need to figure out by eliminating - with tests - each variable own.

8

The GRBL doc gives a good overview of how those modes should work:

The “flow control” in both cases is the OK response from the GRBL firmware indicating it yoinked another command from the buffer.

As far as hardware handshaking goes, the DTR signal has the amusing effect of hard-resetting classic Arduino-based microcontrollers.

The conservative flow-control approach sends one command, waits until GRBL processes it and burps up an OK, then sends the next command. This leaves the buffer mostly empty and works well.

The aggressive flow-control approach keeps the buffer essentially full by tracking the number of characters freed when GRBL processes the command sent dozens / hundreds / thousands of characters earlier. This works really well when it works, but (in addition to the caveats mentioned in the doc) programmers have been writing off-by-one errors since about a day after programming languages were invented.

Perhaps Creality has one of those that only shows up when the buffer gets really full. Or maybe they report the size of the buffer as being one character larger than it really is. Or they screwed up the ring buffer code. Or whatever.

Evidently, you can’t, because it doesn’t work.

Use Synchronous mode and move on.

In practical terms, the USB interface is fast enough to keep up with the laser hardware in all but the most absurdly over-dense grayscale images, for which reason G-Code clustering was invented. If you ever notice the laser lagging due to the serial command speed, it’s an indication you’re probably doing something wrong.

Honest, that’s how it works. :person_shrugging:

9

I think I will use Synchronous mode and move on. It’s very disappointing that Creality doesn’t seem to support buffered mode.

Of note, Creality doesn’t use GRBL (apparently), but it uses Marlin. Operation may be slightly different. I tried DTR enabled, but it makes no difference. GCode clustering only seems to be of benefit for dense graphics. I might turn it on anyway, but all these experiments are burning through my plywood at a great rate.

At least I can now go to Creality with a specific question - do you support buffered mode?

10

IMO, Marlin suffers from its history as 3D printer firmware, with many compromises and optimizations that make it … suboptimal … as general-purpose CNC control firmware. If you plan to dive into G-Code, you should use their definitions:

https://reprap.org/wiki/G-code

GRBL implements the more standardized LinuxCNC G-Code dialect, with comprehensive documentation:

https://linuxcnc.org/docs/stable/html/

In general, unless you know an option is supported, turning it on tends to cause heartache & confusion.

AFAICT, G-Code clustering is only in Smoothieware and a few other 32-bit microcontroller dialects.

Practice on cardboard until you know what happens.

I use cardboard until I know how both the machine and my layout will behave. This tends to reduce the number of expensive surprises, with the side benefit of making them even more surprising.

That dialog should be amusing.

Having watched this play out a few times, I expect the answer will run along the lines of “Sure!”, with any & all problems blamed on LightBurn, until you prove otherwise, at which point they’ll (say they will) pass it on to their tech staff and you’ll experience a complete signal dropout.

You could determine whether Creality makes the complete firmware source code for your machine available, as they should under terms of the GPL:

Then you can recompile it and do your own fault analysis!

:grin:

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.