Welcome! Log In Create A New Profile

Advanced

raw surfaces after marlin update

Posted by Dysplaced 
raw surfaces after marlin update
April 24, 2018 05:27PM
Hi guys,

since I updated marlin on my coreXY, I have an issue with the surfaces. Edgy objects are no problem. But round objects have a raw surface. I can even hear, that it is not running smoothly. But the problem only appears above a certain speed, as you can see on the picture.


I assume, that it has something to do with the buffer size. But I already increased BUFSIZE from 4 to 16 without any success. And in the old version it was 4, too.
I am hosting the printer with octoprint on a pi3. Any ideas?
Re: raw surfaces after marlin update
April 24, 2018 05:51PM
Are you sending gcode to the printer via USB? That's a known problem. Curves send a lot of gcode commands because the curves are broken up into lots of little line segments. Try printing from an SD card or print a lot slower, and reduce resolution of your STL files.


Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]
Re: raw surfaces after marlin update
April 25, 2018 02:26AM
The kinematic math of a CoreXY is pretty simple. But I also noticed, an 8bit controller is the bottleneck in my otherwise fast printer.
For me 8bit is good enough for Cartesian, but nothing else. Maybe other FW than Marlin would work, but I never tried.
Re: raw surfaces after marlin update
April 25, 2018 02:47AM
Printing from SD is not an option. I love my octoprint.

I've been printing with this hardware (RAMPS 1.4 + Mega 2560) for thousands of hours without this problem using the old marlin. The problem appeared with the Version 1.1.x. Is it slower than the old version? Or can I configure ist somehow to become faster?
Re: raw surfaces after marlin update
April 25, 2018 03:47AM
Quote

Printing from SD is not an option. I love my octoprint.

I understand your reasons, but if you'd try it once, you'd be sure, if it's the cause or not.
BTW: octoprint can save the file to local SD-card, but upload speed is pretty slow.
Re: raw surfaces after marlin update
April 25, 2018 04:18AM
Oh ok, just for a test it is no problem. I just gave it a try and with SD Card I have the same Issue. So it seems to be no problem with the communication but with the processing of the GCODE, right?
So I still wonder, why the older Marlin did not have this issue.
Re: raw surfaces after marlin update
April 25, 2018 08:59AM
How many facets has the .stl file of the cylinder? If it's too detailed, the old Marlin would struggle, too.

"Never change a running system" they say. What was the reason for you to upgrade Marlin?
Re: raw surfaces after marlin update
April 25, 2018 09:41AM
I made a test stl in Fusion 360. It is a 20 mm cylinder, exported in high resolution (as I always do). But now I can not print it faster than 50mm/s. Before the upgrade I never had problems at 100mm/s.

The reason for the upgrade was the linear advance function. I often have issues with too much material in the edges, so I wanted to test this interesting function. But yet it is disabled (LIN_ADVANCE_K = 0).
Re: raw surfaces after marlin update
April 25, 2018 09:46AM
I just noticed, that there is some code running even with LIN_ADVANCE_K = 0. I will try what happens, when i disable this function completely by #define.
Re: raw surfaces after marlin update
April 25, 2018 10:11AM
Test is done. Same issue with disabled LIN_ADVANCE.
Re: raw surfaces after marlin update
April 26, 2018 02:24AM
Quote
Dysplaced
I made a test stl in Fusion 360. It is a 20 mm cylinder, exported in high resolution (as I always do). But now I can not print it faster than 50mm/s. Before the upgrade I never had problems at 100mm/s.

The reason for the upgrade was the linear advance function. I often have issues with too much material in the edges, so I wanted to test this interesting function. But yet it is disabled (LIN_ADVANCE_K = 0).

I got curious and did the same and saved it in high and medium resolution. The high-res. cylinder has ~1600 facets, the medium-res ~600.

Marlin on 8bit MPUs seems to be at the edge with all these new features they try to implement ( to keep up with 32bit controllers? )

IMHO you have three options:
Downgrade to the old Marlin
Use medium or even low res. .stl parts
Get a 32bit controller

I always use medium res .stls, never had issues with details.
Re: raw surfaces after marlin update
April 26, 2018 03:17AM
How comes it starts bad then comes up OK ? Is the "engine" warming up and able to cope with the "load" ? smiling smiley


"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)
Re: raw surfaces after marlin update
April 26, 2018 06:30AM
Re: raw surfaces after marlin update
April 27, 2018 02:05AM
Quote
MKSA
How comes it starts bad then comes up OK ? Is the "engine" warming up and able to cope with the "load" ? smiling smiley

I guess, he manually reduced print speed until the buffer-underrun stutters ended...
Re: raw surfaces after marlin update
April 27, 2018 07:13PM
Quote
o_lampe
Quote
Dysplaced
I made a test stl in Fusion 360. It is a 20 mm cylinder, exported in high resolution (as I always do). But now I can not print it faster than 50mm/s. Before the upgrade I never had problems at 100mm/s.

The reason for the upgrade was the linear advance function. I often have issues with too much material in the edges, so I wanted to test this interesting function. But yet it is disabled (LIN_ADVANCE_K = 0).

I got curious and did the same and saved it in high and medium resolution. The high-res. cylinder has ~1600 facets, the medium-res ~600.

Marlin on 8bit MPUs seems to be at the edge with all these new features they try to implement ( to keep up with 32bit controllers? )

IMHO you have three options:
Downgrade to the old Marlin
Use medium or even low res. .stl parts
Get a 32bit controller

I always use medium res .stls, never had issues with details.

Thank you so much! I totally agree. I also tried Marlin 2.0, same result. So now I ordered a 32bit board.


Quote
o_lampe
Quote
MKSA
How comes it starts bad then comes up OK ? Is the "engine" warming up and able to cope with the "load" ? smiling smiley

I guess, he manually reduced print speed until the buffer-underrun stutters ended...

right smiling smiley
Sorry, only registered users may post in this forum.

Click here to login