UM is going too slow in the curves

[Siebet 27]

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 August 15, 2017 by Guest

[neotko 1,417]

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.

[Siebet 27]

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 August 20, 2017 by Guest

[Siebet 27]

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

[neotko 1,417]

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

[Siebet 27]

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

[neotko 1,417]

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

[tinkergnome 927]

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).

[Siebet 27]

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+...

[Siebet 27]

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

[Siebet 27]

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

[tinkergnome 927]

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

I assume that the difference lies in your firmware... 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?

[Siebet 27]

The UMO uses an Arduino based Mainboard.

For firmware questions, I will refer you to @lowiekvds

He made the firmware changes, and is an Arduino expert!

Welcome @lowiekvds to the Ultimaker community

Edited August 20, 2017 by Guest

[LowiekVDS 2]

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

[greengecko 8]

@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

[LowiekVDS 2]

@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 August 31, 2017 by Guest