7

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?

kamuro
  • 2,854
  • 2
  • 21
  • 42
  • 3
    Are you experiencing any issues that you suspect could be related to the baud rate, or are you just asking in general? :) – Tormod Haugene Jul 12 '16 at 11:58
  • 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 Dec 02 '20 at 13:47

3 Answers3

4

Baud rate 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 - 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.

bryanpedini
  • 3
  • 3
Tormod Haugene
  • 3,947
  • 2
  • 20
  • 40
  • 1
    it looks like i was writing an answer a bit too long :) – darth pixel Jul 12 '16 at 12:08
  • @darthpixel, I think you bring up some good points on the effect of low baud rate, though! :) – Tormod Haugene Jul 12 '16 at 12:13
  • 1
    Whoever -1 this, please comment why... – Tormod Haugene Jul 12 '16 at 20:56
  • 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 Jul 12 '16 at 21:19
  • 3
    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 Jul 12 '16 at 22:55
  • 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.. :) – Tormod Haugene Jul 13 '16 at 05:45
  • 1
    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 Jul 13 '16 at 09:13
  • 1
    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 Jul 13 '16 at 09:51
  • 1
    @darthpixel, that is true, although some might suspect it is related if one does not know what baud rate is! ;-) – Tormod Haugene Jul 13 '16 at 11:40
  • 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)! – Tormod Haugene Jul 13 '16 at 11:45
  • 1
    ...and that's why we have to choose a firmware for which the gcode will be generated – darth pixel Jul 13 '16 at 11:52
  • 2
    @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 Jul 13 '16 at 12:36
  • 2
    @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 Jul 13 '16 at 13:09
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.

FarO
  • 3,906
  • 13
  • 31
  • 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 Nov 30 '20 at 17:34
  • 50 bytes is also quite a long line: G01 X247.951560 Y11.817060 Z-1.000000 F400.000000 – FarO Nov 30 '20 at 19:18
  • 2
    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 Nov 30 '20 at 19:22
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 ;)

Lars Pötter
  • 1,561
  • 1
  • 12
  • 20
darth pixel
  • 3,438
  • 1
  • 11
  • 20
  • 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 Jul 12 '16 at 21:19
  • 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 Jul 13 '16 at 05:41