Hi. Over the past years I have been optimizing my setup to come to the point that I (can) now expect great results from my prints. But with some recent prints I noticed jerky movements and a very rough outside finish. Of course I am always pushing the boundaries, but now I am not sure what the limitation is…
My setup is a 1.5x Kossel with a smoothieboard 5X.
I normally run my prints on a windows PC and pronterface over USB.
Cura 2.1.1 is used for slicing.
A print on which this went wrong is e.g. Thingiverse ‘Cute Piggy’ (thing 1275429)
print speed here was 40-60mm/s
When I run the same gcode file from the onboard SD card, movement remains smooth throughout the entire print and it comes out clean and detailed.
So my question is; Is the data rate over USB a limitation to feed sufficient gcode to smoothie? And of course if so, how to improve on this while keeping the flexibility to monitor my prints using pronterface (or similar).
That is very strange. Is the USB cable long, the environment noisy ?
Smoothie USB is very very fast … first time I hear of a problem like this I think.
The cable could be a bit long, but would I not get errors instead of slow transmission? Is there error detection/correction active on some level of the communication?
Noisy…? Printer is the only thing for many meters. Cables are all braided or twisted. Power supplies are enclosed types. I never had any communication or print errors. Just seems slow on these prints.
-> I will try a shorter USB cable with ferrites later today and report back.
What is a normal data rate for the USB connection? And how deep is the recieve buffer on smoothie (all default settings)? My windows PC is not top spec, could that slow things down somehow?
I replaced a 3m USB cable with a 1m shielded one with ferrites on both ends.
-> Still jerky movements and blobs
I upgraded Pronterface to the latest available release (2014.08.01).
-> Still jerkt movements and blobs
I ran the same gcode file from onboard SD (again).
-> Smooth movements, perfect finish
Observation: Time to print via USB was 33:21 (mm:ss), 33:21 and 33:18. Time to print from SD was 32:06 and 32:07. So printing via USB is roughly 70 seconds slower than from SD…
Well looks like something in USB is causing small chocking events … I would guess that’s error detection, or some bug in the USB driver, or something running on the computer causing the low-level USB coms to get paused …
actually if you have lots of very small segments, then yes USB is too slow to keep the buffer full. There is nothing you can do about it other than slow down the print so the movements take longer than the USB and planning.
If you have a delta decrease the segments 50 is more than enough for most deltas.
This can even happen when printing from SD card with very small segments.
Buffering will not help if the movements complete faster than the planner can be filled. It is called the convoy effect.
I’m having the same problems on my Ultimaker:
So no problem when printing via SD card, but printing through USB gives some hick-ups. Speed really reduces after a few layers. Almost like its memory/buffer is full (or so).
Computer configuration:
I7-4790K CPU 4GHz
Windows 10
USB kabel length ~2m (without ferrites)
Cura used as slicer
I generated some gcode to test this. I have my printer run circles at 40mm/s and i get to change the number of gcode lines per second to do that.
For pronterface over USB, I found that up to 60 lines per second, movement was smooth.
At 70 lines gcode per second, it get a few hickups per circle.
Anything 80 and up looks shakey and seriously slower than 40mm/s.
Running the gcode straight of the onboard SD card, It ran 400 lines per second totally smooth!!
I did not have heavier files on hand so I don’t know where the limit is, but that is an incredible difference.
I am using an atom dual core low power pc running Windows 7.
1m USB cable with dual ferrites.
I would be interested to hear from others what kind of lines per second speed they achieve. Is it worth upgrading my setup??
I inserted the python code generating the test gcode below: (I know, I am not a programmer )
defgenerate_test_code(steps_per_second): # Define the circle properties here. # Circle will be centered around (x_offs, y_offs). # All moves will be done at height z_offs. # The speed of the motion will be ‘speed’. Note that F is in mm/min. # n_circle times a circular movement will be made x_offs = 0# mm - center of the circle in X y_offs = 0# mm - center of the circle in Y z_offs = 5# mm - height on which the printer will run the circles r = 30# mm - radius of the circle speed = 40# mm/s - speed for the circle moves speed_fast = 100#mm/s - speed for the moves at beginning and end of the sequence n_circle = 5# number of circles in the files
# start of main code print(‘Check if the generated g-code is compatible with your printer.\n’) print(‘Use this script and g-code at you own risk!!!\n’) print(‘You should change the center of the circle (x_offs and y_offs) to match’) print(‘the center of your printer.’) print(‘Change parameters in the python file to match the g-code to your printer.\n’) generate_test_code(10) generate_test_code(20) generate_test_code(40) generate_test_code(60) generate_test_code(70) generate_test_code(80) generate_test_code(90) generate_test_code(100) generate_test_code(120) generate_test_code(150) generate_test_code(200) generate_test_code(300) generate_test_code(400)
I got results from a much faster PC running windows 10, running my test g-code:
60 lines per second —> OK
70 lines per second —> Hickups occur
Smoothie onboard SD starts choking at slightly over 900 lines per second. So NO ISSUE on smoothie side!
Quick back of the envelope calculation:
20 characters per line * 8 bits * 60 lines per second = 9600??? Could the USB com be configured to 9600 buad???
Smoothie USB Serial doesn’t have a configured limit, it’ll just goes as fast as USB will allow it to go, which is *extremely* much more than 9600 baud
At this point I would suspect the windows serial driver on your computer. Have you tried using another computer ? A linux OS ( ideally on the same machine ) ?
I don’t have another OS available on my system. I did get the same, slow result from 2 configs:
-Windows 7 running on intel atom N2830. Uses v1.0 smoothieboard USB drivers.
-Windows 10 running on intel i7. Uses native windows USB drivers.
In all settings I can find relating to the smoothie USB serial connection data rate is set to 115200. But as you say; smoothie USB does not configure using fixed baud rates…
)