Marlin vs. Repetier on a delta printer

There has been a lot of discussion of which firmware - Marlin or Repetier is better on a delta printer controlled by an 8bit (ATMEGA) Arduino controller.
To this end I did my own tests. Here is the video:
Marlin 1.1.6 vs. Repetier
The second part compares the latest 1.1.8 Marlin to Repetier in an interesting way:
Marlin 1.1.8 vs Repetier
The printer is the Anycubic Kossel. And here are both firmwares used in the test:
My Marlin on Github
My Repetier on Github

Not to spoil the "movie" but in my opinion Repetier is still better.

Edited 1 time(s). Last edit at 03/26/2018 05:44AM by ruevs.

I used marlin few years ago. I use repetier now.

The main reason for the switch was that at that time marlin applied the speed from g-code to tower carriages. This led to smaller print head speed when the printer was printing at the edge of the bed compared to the speed when printing at the middle. Repetier correctly applies the speed to the print head.

Does the latest marlin still apply the speed settings to the carriages instead of the print head?

46minute video? I'll pass...

The beginning is too verbose - true.
The interesting part starts at 29:20 ;-)

Yes but the premise of this is which is better red tshirts or blue ones, when I'd say black.

RRF on duet probably offers the best solution for delta printers, Smoothieware is also very capable. Marlin works too but I have not used repetier so can only say I am told it can generate more steps/sec than marlin so for 8 bit boards can achieve higher speed without sacrificing a graphical display.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

@ruevs:
Does the current Marlin firmware move the same speed regardless of the print head position?
You can check it by moving in one line (one g-command) from tower near to the tower base to the other side of the base. Does the print head have the same speed during the whole length of the move?

Can someone post a short summary of the conclusions from the videos?

The Marlin firmware took longer time then Repetier to execute the same g-code. During Marlin execution the magnetic arms disconnected. I did not see the explanation why this happened in the video. But I did not look at the whole 45 minutes of it. It is just way too long.

One obvious explanation is that Marlin firmware experienced line buffer underflows. That stops movement momentarily which would have two consequences:

• the movement stop/resume happens with very high acceleration which disconnects magnetic arms
• momentary stops lead to longer print times

OR ... the marlin firmware executes everything a bit more slowly but correctly from the point of view of smooth movement (acceleration limits are obeyed) and the magnetic arms suck. What exactly happens was not clear from the piece of the video I looked at.

The whole test was not very interesting since it used segments per second set to 200. That is a too high value. The useful value is around 100.

Quote
hercek
@ruevs:
Does the current Marlin firmware move the same speed regardless of the print head position?
You can check it by moving in one line (one g-command) from tower near to the tower base to the other side of the base. Does the print head have the same speed during the whole length of the move?

I have Repetier on the machine right now and do not want to mess with it since I am in the middle of a project. So I can not test this empirically right now.
However looking at the code:
https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/Marlin_main.cpp#L13111
in the "prepare_kinematic_move_to" function it looks to me that the planning is done in Cartesian coordinates.

Quote
hercek
The Marlin firmware took longer time then Repetier to execute the same g-code. During Marlin execution the magnetic arms disconnected. I did not see the explanation why this happened in the video. But I did not look at the whole 45 minutes of it. It is just way too long.

One obvious explanation is that Marlin firmware experienced line buffer underflows. That stops movement momentarily which would have two consequences:

• the movement stop/resume happens with very high acceleration which disconnects magnetic arms
• momentary stops lead to longer print times

OR ... the marlin firmware executes everything a bit more slowly but correctly from the point of view of smooth movement (acceleration limits are obeyed) and the magnetic arms suck. What exactly happens was not clear from the piece of the video I looked at.

The magnetic arms always disconnect with Marlin in this test - usually much sooner than in the test run I shot in the video. From this I come to the conclusion that for some reason Marlin causes much higher accelerations (maybe "micro" ones from buffer underflows or from driving the steppers "not smoothly" whatever that means).
The sound that the steppers make with Marlin is... different... "grinding".
At the same time the arms never disconnect with Repetier even with the real torture test at very high speed I did towards the end of the video.

Quote
hercek
The whole test was not very interesting since it used segments per second set to 200. That is a too high value. The useful value is around 100.

Why is 200 segments per second too high? I did not know how much the ATMega can handle with delta kinematics calculations, but I started with 200 (15 months ago) because that was the default in Repetier. I have used the printer all this time with 200 without any problems (the display is not a bitmapped one). So I configured Marlin the same.

Here is the G-code that runs the test [github.com] .

Edited 1 time(s). Last edit at 03/26/2018 05:42AM by ruevs.

Probably the Marlin line buffer underflows which leads to shuttering (with high acceleration) and magnetic arm disconnection.
200 segments per second is un-necessary high default. 100 is enough. If you would change it to 100 then probably even Marlin would not disconnect your magnetic arms.

I very briefly looked at the code. Looks like Marilin firmware still controls speed/acceleration on carriages instead of managing them on the print head: Planner takes care of the speed/acceleration management and the planer gets inserted with the line segments in the delta coordinates (i.e. the required carriage positions). Provided that there is no unexpected magic later on in the planner regarding to delta then Marlin still does not manage print head speed correctly.
It would be fine to do a test on real printer just to be sure. If you happen to have some time doing it then please post the results.

I just recently switched to Repetier from 6 years on Marlin and it was a night and day difference for me. I don't use a Delta but a CoreXY is close enough, imo, where planning is essential and while I despise their Host I love their firmware. The controller my printer uses is on a 1284p so I am stuck using version 92.x as the more modern versions will not fit (only complaint I have as there needs to be a separate version for lasers and cnc machines not all shoved into one) but my prints have simply worked for me and looked better than when I used Marlin on that printer.

As far as the person above saying they would say black that wasn't part of the conversation because this was Marlin vs Repetier not a Due vs Smoothie on a 32bit ARM vs 8bit AVR.

---

_______
I await Skynet and my last vision will be of a RepRap self replicating the robots that is destroying the human race.