Awesome, good to know for sure. one of these days I 'll have to see how low that can actually go.
Take a look at an average gcode file to see it’s size in bytes and multiply by 10. Then look at the estimated time for the project, convert to seconds. Divide the size by time to get bps. Fudge a bunch to allow for overhead, but I’m going to guess it’ll be 9600bps or less.
250k isn’t one of the “standard” baud rates, so some linux libraries (pyserial, I think) doesn’t support it. It’s not a problem with speed, just that particular number. 115200 works fine. In 3D printing, I’ve heard people blame those little warts on the outside of prints on slow USB/Serial connections, because the printer will pause for a very small moment, enough to get some squeeze out.
@Bill, I bet that number gets a lot higher when you are doing 2.5D, because each move is about the same number of characters, but the moves are way smaller. If you were cutting out a realistic octopus or something, I bet it could approach that limit.
Wow, so is there some way to measure this? Or I guess you’re right something with a bunch of long straight moves uses almost no data, but if it was curved on all three axis it would be making some very tiny steps…like when you pause a 3d printer. I always try and pause on a curve so I know it will drain its buffer right there, whereas during infill it could keep printing for a while.
Any idea what the buad rate is between the lcd and the ramps?
I’m looking at some of my generated gcode from estlcam (from the MP3DP, which is pretty simple, most of the time) and it looks pretty consistent at 4 decimal places, so maybe 40 characters for the worst X, Y, Z gcode move.
40Bytes/command * 10bits/Byte / (115200 bits/second) = 3.5ms/command
At a speed of 100mm/s, then you could have a resolution of:
100mm/s * 0.0035s/command = 0.35mm/command
The trouble with this estimate (well, there are many, it’s a great simplification) is that the resolution isn’t really under our control, so even if you’re fine with 0.35mm per command, estlcam might be doing 0.0001mm/command, in which case, the speed will drop significantly. The parts of a 2.5D that were really hogging out material would be in lines, so maybe not a big deal. That helical cutting might be a problem. Another point is that Marlin is going to be doing it’s acceleration limiting too, including on curves, so that might also be limiting it to the point where the baud rate doesn’t matter.
If I were going to try and figure out what speed was needed for a particular gcode file, I’d probably write a script that would essentially simulate the gcode moves, measuring the baud rate needed. But that would also be a poor estimation.
I wonder how hard it would be to get the current speed and current buffer size from Marlin. I keep wondering what speed the tool is actually moving, after all its acceleration limiting, and also knowing the size of the buffer would be pretty useful, I think. Isn’t there a way to customize the status message that it spits out periodically?
w.r.t. the LCD, I have no idea. It’s not using UART/Serial, is it? I thought it was using SPI or something. Might be a good question for some Marlin user group. I also thought the SD card was basically being connected directly to the Marlin, so it wouldn’t depend on the speed to the display, but the speed the Marlin can read the SD card.
If the serial is set too low the tool just pauses between moves, the computer will have no problem with keeping up. If the serial is set too fast for the computer to keep up with, the computer might miss a pause handshake an keep dumping characters that the Arduino ignores. I’m running 250000 on a 12 year old laptop (P4 with 1G ram) running Windows 10 and haven’t seen any indication of dropped characters, but I haven’t tried anything complex yet.