Jump to content
Ultimaker Community of 3D Printing Experts
Siebet

UM is going too slow in the curves

Recommended Posts

Hi everyone!

We have a problem with our project where we working on.

We are trying to make the Mark2 upgrade compatible with the UMO.

No worries, We wil publish it online when it works completely!

So this is the problem:

 

The printer makes very slow movements in the curves.

We had to translate the UM2 firmware to the UMO mainboard so, I think the problem is on the Firmware side...

Thanks!

Have a nice day!

Edited by Guest

Share this post


Link to post
Share on other sites

I would check the gcode to see how many movements/second are happening there. That's the classic effect of the board stuttering the planner. If that happens again if you slow down the speed to 50% then it could be other thing.

I seen this behavior also happening on latest s3d 4.0, it has a bug that inserts lots of small extra extrusions making the buffer stutter.

Share this post


Link to post
Share on other sites

I would check the gcode to see how many movements/second are happening there. That's the classic effect of the board stuttering the planner. If that happens again if you slow down the speed to 50% then it could be other thing.

I seen this behavior also happening on latest s3d 4.0, it has a bug that inserts lots of small extra extrusions making the buffer stutter.

Thanks for your reply!

Here you have the Gcode. I will test it with the lower speed...

Edited by Guest

Share this post


Link to post
Share on other sites

I would check the gcode to see how many movements/second are happening there. That's the classic effect of the board stuttering the planner. If that happens again if you slow down the speed to 50% then it could be other thing.

I seen this behavior also happening on latest s3d 4.0, it has a bug that inserts lots of small extra extrusions making the buffer stutter.

Problem is not solved with slower speed...

Share this post


Link to post
Share on other sites

An unrelated note: you should not use the Mark2 definition for single extrusion prints... This start-gcode is not quite suitable...

Besides that: the gcode file seems to be usable with a normal UM2, if someone is willing to... (just to rule out some things).

Thanks for your reply! Okay, good to know ;)

I will try the Gcode on my UM2E+...

Share this post


Link to post
Share on other sites

An unrelated note: you should not use the Mark2 definition for single extrusion prints... This start-gcode is not quite suitable...

Besides that: the gcode file seems to be usable with a normal UM2, if someone is willing to... (just to rule out some things).

Thanks for your reply! Okay, good to know ;)

I will try the Gcode on my UM2E+...

@tinkergnome

Gcode works perfectly on UM2E+... So the problem is on the firmware side...

Share this post


Link to post
Share on other sites

What’s the acceleration/jerk settings? Maybe jerk is way too low than the 20 default?

I have also printed with the standard UM2 slicer settings, so that's not the problem...

I mean that you check the firmware default accel/jerk settings. But indeed it’s weird

Delfaut accel: 3000 and delfaut jerk: 20

So that's okay...

Share this post


Link to post
Share on other sites

Gcode works perfectly on UM2E+... So the problem is on the firmware side...

I assume that the difference lies in your firmware... :p More details please...

The UMO uses a different mainboard AFAIK, or is it the same? It's hard to guess, what you have changed. Can you explain it a bit? Are the source files available somewhere?

How is it compiled (compiler switches, active debugging options or something along these lines)? Is there any suspicious output on the serial console? Any noticeable differences if you start the same print from sd card or from USB?

  • Like 1

Share this post


Link to post
Share on other sites

Gcode works perfectly on UM2E+... So the problem is on the firmware side...

I assume that the difference lies in your firmware... :PMore details please...

The UMO uses a different mainboard AFAIK, or is it the same? It's hard to guess, what you have changed. Can you explain it a bit? Are the source files available somewhere?

How is it compiled (compiler switches, active debugging options or something along these lines)? Is there any suspicious output on the serial console? Any noticeable differences if you start the same print from sd card or from USB?

Hello,

Because the motherboard of the UM2 and the motherboard of the UMO are both based on an Arduino Mega, running the firmware on the UMO original is not hard. You can just compile the code without problems using the Arduino IDE. But making it run like it is supposed to on UMO, is another story. Because if you just change the motherboard, it wil give errors.

So I tricked the firmware into thinking that it is running on the UM2 motherboard, plus some changes so that everything runs like it should on the UMO (changes in pins.h for example).

As an example, we use the RepRap Discount Full Graphic Smart Controller on the UMO. Once again, I let the firmware think that it is using the original UM2 display, and changed/added a lot of code so that it actually renders correctly on the RepRap display.

The method I am currently using for achieving this is a quick and dirty way, but it is not that good. I have plans to implement a way better method to make the display work smoother.

You can download the source code and the .hex file of the latest version if you want to try this on your own UMO here :

https://www.dropbox.com/s/las74lz5aadok78/UMO_Mark2.rar?dl=0

Share this post


Link to post
Share on other sites

@Siebet

are there any news from your mark on umo upgrade. did you solve the slow in curves problem?

i have now the reprap controller tft and could try if the um2 firmware is running on the umo..

any advise?

thanks in advance

We found what the problem was and I am currently working on a solution.

I don't know how long it will take, but I hope it is done soon!

The problem was that the printer gets a lot of commands it needs to execute to define a curve. And before it can execute the next command, it needs to update the display. Because of the dirty, inefficient way I implemented the display, it takes a lot of time until it fully updates. As a result, the commands that define the curve are executed too slow after each other so the printer moves too slow in curves.

So a temporary solution is disabling the display. If you would like to try that on your printer, here is the download link to the working version with the display disabled : https://www.dropbox.com/s/3wwxy97vp9noubt/geen_lcd_2.hex?dl=0

Edited by Guest
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

[[Template core/front/global/_customFooter does not exist. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!