<p>If your printer doesn't have an SD card then the whole communication between computer and arduino is performed "live". There is kinda buffer of data which arduino can swallow. Then it needs to process it (and then can send some reports to your app) and then arduino is ready to get new "set" of instructions to work on.</p>

<p>Now. If a baudrate is to low then there could be a situation when arduino finishes its job and has to wait for new bite of data. In such a situation you can see the printer pauses printing as it waits for signals from arduino as it waits for data from computer. That's more or less a downside of a low baudrate.</p>

<p>If you have a SD card then the data is sucked from it but reports are still send by port to show results on screen. In such situation you can see sligtly late screen update.</p>

<p>A screen means just a fun of live preview but breaking printing process (caused by late data send) means your hot nozzle stays over the same position which can destruct a surface or even fry up a plastic a bit. It also oozes and therefore creates lasting artifacts.</p>

<p>Resuming - low baudrate is evil ;)</p>

CC BY-SA 3.0
2016-07-12T21:19:34.243Z
So this depends mainly on instructions/time. ist there a general rule of thumb, lets say, 'if your mordel is with lots of directional changes, you can only go to speed xx mm/s', or single cases which have been documented?
kamuro
CC BY-SA 3.0
2016-07-13T05:41:22.233Z
Of course if your slicer will cut a curve into too many pieces then it could appear but... if you don't tune up (or rather derange) slicer/firmware/baudrate too much then I think it will not come up. I cannot find an article I've read :(
darth pixel
CC BY-SA 3.0
2016-07-12T12:06:49.697Z
2016-07-12T18:44:49.853Z
2016-07-12T18:44:49.853Z
darth pixel
<p>If a GCODE line is about 30 characters (which is about the norm), you can send at most 420 of them per second at 115200 bps.</p>
<p>If each GCODE prints 0.15 mm (for example in arcs), you would be limited to 63 mm/s in arcs/circles (straight lines are not an issue).</p>
<p>If that's limiting for you, then you should find a way to set 250 kbps.</p>
<p>You don't mention the firmware you use, but if you use Klipper, which compresses data over the serial line, connection speed is not an issue.</p>

CC BY-SA 4.0
2020-11-30T17:34:14.497Z
I was hoping to see a quantitative answer for this. Great! Keep in mind the slicer may generate gcode lines shorter than 0.25 mm in order to avoid exceeding max deviation. Anywhere in the range 0.1 to 0.5 mm is typical depending on a mix of model resolution and slicer settings, so this really could be a limiting factor at significantly lower speeds than 64 mm/s.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-11-30T19:18:27.670Z
50 bytes is also quite a long line: G01 X247.951560 Y11.817060 Z-1.000000 F400.000000
FarO
CC BY-SA 4.0
2020-11-30T19:22:12.027Z
The Z is excessive (in practice there won't be any appreciable Z movement except in vase mode) but you forgot the E component. In my experience print (extrude-and-move) lines are about 30 characters each, so I'd say apply a factor of 3/5. They're of the form `G1 Xxxx.xxx Yyyy.yyy Eee.eeeee`.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-11-30T11:02:40.630Z
2020-11-30T20:34:00.030Z
2020-11-30T20:34:00.030Z
FarO
<p><a href="https://learn.sparkfun.com/tutorials/serial-communication/rules-of-serial" rel="nofollow noreferrer">Baud rate</a> is the rate at which information is transferred in a communication channel, given as a number of bits per second (bps). So a baud rate of 250000 is capable of transferring a <em>maximum</em> of 250000 bits per second (31250 bytes/s). When working with serial ports, both ends of the communication line will have to &quot;talk&quot; with the <a href="https://www.quora.com/How-do-we-connect-two-devices-with-different-baud-rates" rel="nofollow noreferrer">same speed</a> - the same baud rate - to understand each other.</p>
<p>So when using a baud rate of 11520 you will theoretically be limited to transfer data with about half the speed of 25000. If you are transferring large amounts of data, this might be a limiting factor for your application, but if you are not pushing the limits of your serial port, it probably won't matter at all.</p>

CC BY-SA 3.0
2016-07-12T12:08:04.330Z
it looks like i was writing an answer a bit too long :)
darth pixel
CC BY-SA 3.0
2016-07-12T12:13:20.633Z
@darthpixel, I think you bring up some good points on the effect of low baud rate, though! :)
Tormod Haugene
CC BY-SA 3.0
2016-07-12T20:56:45.810Z
Whoever -1 this, please comment why...
Tormod Haugene
CC BY-SA 3.0
2016-07-12T21:19:41.167Z
So this depends mainly on instructions/time. ist there a general rule of thumb, lets say, 'if your mordel is with lots of directional changes, you can only go to speed xx mm/s', or single cases which have been documented? (I'd also be interested in the downvote reasons, - this is an excellent answer)
kamuro
CC BY-SA 3.0
2016-07-12T22:55:17.200Z
I don't think you're likely to lower the baud rate to the point where it's slower than the actual machine. Lower baud rates can be a good thing if there's a lot of noise in the signal, such as can happen with cheap cables. It's like talking more slowly to help someone understand you. I prefer to simply use the SD card on my printer and take my PC out of the equation.
John Sensebe
CC BY-SA 3.0
2016-07-13T05:45:36.510Z
@kamuro, on some delta printers you will notice a significant lag if you try to navigate the menus while the printer is doing calculation intensive moves, in my case due to a limited CPU. :) John, the increased S/N-ratio is very interesting! Thanks for sharing. I also stopped printing from USB as you don't need additional variables with 3D printers at the moment.. :)
Tormod Haugene
CC BY-SA 3.0
2016-07-13T09:13:10.843Z
Thanks for the insight. Delta printers and sloggish LCD response is a known issue with non-32bit Arduino processors. Quintessentially I take that I don't need to worry about the lower BAUDrate if I stay under 200mm/s and super complicated models I guess ;)
kamuro
CC BY-SA 3.0
2016-07-13T09:51:40.923Z
hey guys - delta calculations and lag of LCD has nothing to low baudrate I suppose, hasn't it? It's a result of managing everything by small cpu. Or - more precisely - it's a result of slow cpu and wrong (or lack of) interrupts processing I would say.
darth pixel
CC BY-SA 3.0
2016-07-13T11:40:33.427Z
@darthpixel, that is true, although some might suspect it is related if one does not know what baud rate is! ;-)
Tormod Haugene
CC BY-SA 3.0
2016-07-13T11:45:47.190Z
@kamuro, I doubt you will ever have to worry about the baud rate if it just is related to streaming gcode over USB: the calculations for moving the printhead are performed by the printers hardware and not your computer (the gcode is interpreted differently by each individual printer/firmware)!
Tormod Haugene
CC BY-SA 3.0
2016-07-13T11:52:23.167Z
...and that's why we have to choose a firmware for which the gcode will be generated
darth pixel
CC BY-SA 3.0
2016-07-13T12:36:52.943Z
@TormodHaugene: I know, it's only for transmitting the gcode. But if we never need to worry about it, why was a non-standard BAUDrate chosen to begin with and not the standard 115200?
kamuro
CC BY-SA 3.0
2016-07-13T13:09:54.943Z
@kamuro, that is a good question. Apparently you can squeeze out [baud 2000000 from 16MHz Arduinos](http://forum.arduino.cc/index.php?topic=21497.0) (note the hack in the last post), although the reference [states a max of 115200](https://www.arduino.cc/en/Reference/SoftwareSerialBegin). On the other hand, baud 250000 is apparently used in the DMX, which there even is a [external Arduino library](https://github.com/mathertel/DmxSerial) for.
Tormod Haugene
CC BY-SA 4.0
2016-07-12T11:56:39.877Z
2020-11-29T23:35:01.070Z
2020-11-29T23:35:01.070Z
Tormod Haugene
<p>I am using a BAUDrate of 115200 since I cannot make a connection to my printer with the advised 250000 rate. Are there any downsides or limits I reach earlier given by the lower BAUDrate?</p>

CC BY-SA 3.0
2016-07-12T11:58:10.883Z
Are you experiencing any issues that you suspect could be related to the baud rate, or are you just asking in general? :)
Tormod Haugene
CC BY-SA 4.0
2020-12-02T13:47:26.680Z
Baud rate for 3d printers has diminishing return on speed.  Your printer can only go so fast.  The computer sending the data goes a lot of waiting for your printer to catch up.  At 115200 is so fast going above that isn't going to make a great deal of difference unless your printer is super fast.
cybernard
<electronics>
What is the influence of a lower BAUDrate?
kamuro
# What is the influence of a lower BAUDrate?

(Asked by: username_0 on 2016-07-12)

I am using a BAUDrate of 115200 since I cannot make a connection to my printer with the advised 250000 rate. Are there any downsides or limits I reach earlier given by the lower BAUDrate?

**Tags:** electronics
> **Comments:**
> **username_1**: Are you experiencing any issues that you suspect could be related to the baud rate, or are you just asking in general? :)  
> **username_2**: Baud rate for 3d printers has diminishing return on speed.  Your printer can only go so fast.  The computer sending the data goes a lot of waiting for your printer to catch up.  At 115200 is so fast going above that isn't going to make a great deal of difference unless your printer is super fast.  

---

## 3 answers

### Answer by username_1 on 2016-07-12. Score: 4 | Accepted answer

[Baud rate](https://learn.sparkfun.com/tutorials/serial-communication/rules-of-serial) is the rate at which information is transferred in a communication channel, given as a number of bits per second (bps). So a baud rate of 250000 is capable of transferring a *maximum* of 250000 bits per second (31250 bytes/s). When working with serial ports, both ends of the communication line will have to "talk" with the [same speed](https://www.quora.com/How-do-we-connect-two-devices-with-different-baud-rates) - the same baud rate - to understand each other.

So when using a baud rate of 11520 you will theoretically be limited to transfer data with about half the speed of 25000. If you are transferring large amounts of data, this might be a limiting factor for your application, but if you are not pushing the limits of your serial port, it probably won't matter at all.

> **Comments:**
> **username_3**: it looks like i was writing an answer a bit too long :)  
> **username_1**: @darthpixel, I think you bring up some good points on the effect of low baud rate, though! :)  
> **username_1**: Whoever -1 this, please comment why...  
> **username_0**: So this depends mainly on instructions/time. ist there a general rule of thumb, lets say, 'if your mordel is with lots of directional changes, you can only go to speed xx mm/s', or single cases which have been documented? (I'd also be interested in the downvote reasons, - this is an excellent answer)  
> **username_6**: I don't think you're likely to lower the baud rate to the point where it's slower than the actual machine. Lower baud rates can be a good thing if there's a lot of noise in the signal, such as can happen with cheap cables. It's like talking more slowly to help someone understand you. I prefer to simply use the SD card on my printer and take my PC out of the equation.  
> **username_1**: @kamuro, on some delta printers you will notice a significant lag if you try to navigate the menus while the printer is doing calculation intensive moves, in my case due to a limited CPU. :) John, the increased S/N-ratio is very interesting! Thanks for sharing. I also stopped printing from USB as you don't need additional variables with 3D printers at the moment.. :)  
> **username_0**: Thanks for the insight. Delta printers and sloggish LCD response is a known issue with non-32bit Arduino processors. Quintessentially I take that I don't need to worry about the lower BAUDrate if I stay under 200mm/s and super complicated models I guess ;)  
> **username_3**: hey guys - delta calculations and lag of LCD has nothing to low baudrate I suppose, hasn't it? It's a result of managing everything by small cpu. Or - more precisely - it's a result of slow cpu and wrong (or lack of) interrupts processing I would say.  
> **username_1**: @darthpixel, that is true, although some might suspect it is related if one does not know what baud rate is! ;-)  
> **username_1**: @kamuro, I doubt you will ever have to worry about the baud rate if it just is related to streaming gcode over USB: the calculations for moving the printhead are performed by the printers hardware and not your computer (the gcode is interpreted differently by each individual printer/firmware)!  
> **username_3**: ...and that's why we have to choose a firmware for which the gcode will be generated  
> **username_0**: @TormodHaugene: I know, it's only for transmitting the gcode. But if we never need to worry about it, why was a non-standard BAUDrate chosen to begin with and not the standard 115200?  
> **username_1**: @kamuro, that is a good question. Apparently you can squeeze out [baud 2000000 from 16MHz Arduinos](http://forum.arduino.cc/index.php?topic=21497.0) (note the hack in the last post), although the reference [states a max of 115200](https://www.arduino.cc/en/Reference/SoftwareSerialBegin). On the other hand, baud 250000 is apparently used in the DMX, which there even is a [external Arduino library](https://github.com/mathertel/DmxSerial) for.  

---

### Answer by username_3 on 2016-07-12. Score: 2

If your printer doesn't have an SD card then the whole communication between computer and arduino is performed "live". There is kinda buffer of data which arduino can swallow. Then it needs to process it (and then can send some reports to your app) and then arduino is ready to get new "set" of instructions to work on.

Now. If a baudrate is to low then there could be a situation when arduino finishes its job and has to wait for new bite of data. In such a situation you can see the printer pauses printing as it waits for signals from arduino as it waits for data from computer. That's more or less a downside of a low baudrate.

If you have a SD card then the data is sucked from it but reports are still send by port to show results on screen. In such situation you can see sligtly late screen update.

A screen means just a fun of live preview but breaking printing process (caused by late data send) means your hot nozzle stays over the same position which can destruct a surface or even fry up a plastic a bit. It also oozes and therefore creates lasting artifacts.

Resuming - low baudrate is evil ;)

> **Comments:**
> **username_0**: So this depends mainly on instructions/time. ist there a general rule of thumb, lets say, 'if your mordel is with lots of directional changes, you can only go to speed xx mm/s', or single cases which have been documented?  
> **username_3**: Of course if your slicer will cut a curve into too many pieces then it could appear but... if you don't tune up (or rather derange) slicer/firmware/baudrate too much then I think it will not come up. I cannot find an article I've read :(  

---

### Answer by username_4 on 2020-11-30. Score: 2

If a GCODE line is about 30 characters (which is about the norm), you can send at most 420 of them per second at 115200 bps.

If each GCODE prints 0.15 mm (for example in arcs), you would be limited to 63 mm/s in arcs/circles (straight lines are not an issue).

If that's limiting for you, then you should find a way to set 250 kbps.

You don't mention the firmware you use, but if you use Klipper, which compresses data over the serial line, connection speed is not an issue.

> **Comments:**
> **username_5**: I was hoping to see a quantitative answer for this. Great! Keep in mind the slicer may generate gcode lines shorter than 0.25 mm in order to avoid exceeding max deviation. Anywhere in the range 0.1 to 0.5 mm is typical depending on a mix of model resolution and slicer settings, so this really could be a limiting factor at significantly lower speeds than 64 mm/s.  
> **username_4**: 50 bytes is also quite a long line: G01 X247.951560 Y11.817060 Z-1.000000 F400.000000  
> **username_5**: The Z is excessive (in practice there won't be any appreciable Z movement except in vase mode) but you forgot the E component. In my experience print (extrude-and-move) lines are about 30 characters each, so I'd say apply a factor of 3/5. They're of the form `G1 Xxxx.xxx Yyyy.yyy Eee.eeeee`.  

---

