print issue - incosistent travel speeds while printing

Hi Guys,

I'd appreciate any help you can give me. I have a Richrap 3dr printer with ramps1.4 electronics. I'm having an issue which you can see here:
https://www.youtube.com/watch?v=M3FWj7JOzAg
The print travel slows down as it reaches the middle of the bed, then speeds up again. This causes thick sections - these are the rough parts of the print. Later during the print these sections lift up from the bed and look like a bubble.

Also, often late into a job, I have the nozzle hit the print and print in mid air. I'm not sure if this is related, but I cant figure out why this happens. The stepper drivers never feel hot to touch.

I've been increasing the voltage on the stepper drivers steadily in case this has been causing skipped steps. They are now on around 0.9V. What voltage should I have the stepper drivers set to for Nema17 motors? the specs are:

Rated Voltage 2.8 V
Current/Phase 1.68 A
Could they be overheating this early into a print?

I'm starting to think that the processing in the ramps board is not keeping up with the calculations.

Can you post your STL and gcode files? I can run them through my printer to see how it handles it.

Hi, It happens with every print in the same spots.

I say again, can you post your STL and gcode files please?

That will at least allow us to figure out if the problem is in your slicer settings.

That does not look like missing steps. It looks like mechanical binding or STL problems.

Have you tested that you can manually, with you little finger, move all carriages up and down without stressing your finger? (with power OFF obviously) Any particular spot where there is a sudden change of friction?

Issue the following commands to your printer:

G28
G1 X55 Y0 Z10
G1 X-55 F1500
G1 X0 Y55
G1 X0 Y-55 F1500


Does it do the same thing? Does it slow down when you ask it to make those moves?

I doubt it's mechanical binding, as if it was, the print surface would not remain flat (ask me how I know).

I suspect something in the gcode, or as you say, the STL file.

Hi, Here is the gcode. I have also attached my config.h file
Twisted_Vase_Basic.zip
Configuration.h

I checked for binding by hand and there is no problem.

I also tried the moves suggested by LarsK. It appears to move smoothly in x and y directions however when it moves down after G28 it appears to do it in three stages with a tiny pause in between each stage. I assume this is because there is a limited maximum move....

Thanks again for your help. As you can imagine, this is very frustrating.

Are you trying to run a grapical LCD from the printer electronics?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

After G28 the effector should move down in one swift motion to the print surface.

Seems you´re using a graphic LCD with an 8bit arduino? That would explain the pauses in the move, since the processor is overloaded from the graphic display.

#include U8glib.h
...

#define MOTHERBOARD 33

I´d go for a character LCD ( 20x4 ) or a 32bit controller.
-Olaf

Edited 1 time(s). Last edit at 09/24/2015 04:38AM by o_lampe.

Agree with Olaf and David. Disconnect display to confirm (disconnect in firmware). If that is the problem, then consider changing to Repetier firmware, that firmware can manage the big displays. Longterm consider 32 bit as that is where things are heading.

Edited 2 time(s). Last edit at 09/24/2015 08:00AM by LarsK.

Well, it's not your gcode.

[www.youtube.com]

So I guess that leaves us with the graphical LCD display issue. I'm using a 4 line LCD character display, which seems to work fine.

I hope this helps.

There was one guy at marlin_dev github, who made some tests with his arduino/ramps/LCD2004 combo. He said the displays refresh routine takes ~90ms of a 100ms looptime.
Meaning the processor has only 10% of his time for the real work.
He splits his display in four portions and refresh one line at a time instead of 4 lines at once. So he gained 65% more time for number crunching.
Unfortunately he closed the thread before he could share his code...
-Olaf

Hi Guys,

I'm running a RepRapdiscount full graphic smart controller. I'll try and disconnect the graphics in firmware and trial again.

Can you recommend 32 bit controller to try? Duet?

Any comment on the voltage on the stepper drivers? I'll leave them for now unless they overheat.

Thanks again. Martin

0.9V (~0.9A) is fine if you have a small fan blowing on the RAMPS.

Hi again. I disabled the graphics by commenting out
//#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

There were no low memory warnings this time. Normally there is.

I then tried printing the same object and I still have the issue. Funny thing - the first layer is not too bad with only a small area where the speed was too slow.
The second layer however, has exactly the same pattern where the nozzle moved too slow. I also noticed that the extruder motor appears to slow down as well at the same point of the print. Since there is still a build up of pressure in the hot end, the plastic still comes out at normal speed. So I'm assuming all motors slow down during this point of the print. I think this still points to a processing/processor issue.

One piece of good news. I tried the movements suggested by LarsK and there are no pauses as it moves from G28 to the bed. Again there were no issues with the movements in the x-y plane

One more thing. If I buy a Duet board, can i still use the Reprap graphic display?

Quote
pulse69
One more thing. If I buy a Duet board, can i still use the Reprap graphic display?

No. It will not. 5V on Arduino Mega and 3.3V on Duet.

As for your problem - In my opinion the obvious points are exhausted.

I think your best bet now is to try Repetier firmware. This will rule out a couple of issues. It will take you a couple of hours to configure and get it up running but it rules out a lot of errors. You just use the configurator on Repetier homepage.

Ok, I'll try Repetier when I get a chance. It will take me a few days.

Since it´s a delta, we should consider bad calibration.
There´s no word about flatness of the head-moves, tower and center calibrated.
Have you done all the calibration steps, before you tried to print?
Did you use auto bed level?
-Olaf

It looks like like line buffer under-run, i.e. small cpu resources for the requested task.
Try to lower DELTA_SEGMENTS_PER_SECOND to 100 or may be even to 80.
It should help if I'm right.

First, you want your printer as mechanically calibrated as possible-- Frame should be as "square" (uprights perpendicular to horizontals, towers at 120 degree intervals) as possible, bed parallel to the horizontals, etc..

Then, in order of performance / quality boost:

Good: Switch to repetier firmware on current hardware (may drive LCD)
Better: Switch to Repetier firmware on Arduino Due/RADDS (Should drive LCD)
Best: Switch to RepRapPro Firmware on Duet (will not drive LCD-- has it's own interface solution, paneldue)

Marlin (without a full-graphics LCD), is quite capable of driving a kossel at reasonable speeds-- It also has auto-calibration, which is useful, but, it has a lot of bulk in it's code, meaning it's performance is a bit iffy.

Repetier is more streamlined, with less cruft, but no auto-calibration (only bed leveling) code-- Personally, if you're going to run an 8-bit CPU (Arduino Mega), this is the firmware of choice, in my opinion. It might be able to run the full graphics LCD, it might not-- The GLCD requires a lot of refreshing, which steals clock cycles from the stepper interrupts.

Repetier is better than Marlin, but even on Due/RADDS, is still basically an 8-bit firmware that's been ported-- so it's got more room, more clock cycles, but the logic is the same. RRF (reprappro firmware) is designed for 32 bit controllers, so it has more advanced logic.

RRF firmware is being ported to Due/RADDS, but may or may not drive LCD.

Personally, I'm running Repetier on Due/RADDS, and I'm very pleased with the performance.

Olaf,

The tower and center are calibrated manually, however I have some trouble between tower x and y where the head is too low. There is a slight difference in the spacing between towers which I think is causing that problem. I'm going to take it apart and correct this problem soon. I dont think its causing problems with the slow print.

I cant get auto bed level working. it causes my printer to go haywire.

Quote
o_lampe
Since it´s a delta, we should consider bad calibration.
There´s no word about flatness of the head-moves, tower and center calibrated.
Have you done all the calibration steps, before you tried to print?
Did you use auto bed level?
-Olaf

I'll try lower steps per segment before I move onto repetier or the Duet option.

Hi Guys, I reduced the number of segments/second to 100 and the problems seem to have gone away. I'll try turning the screen back on now.

Quote
pulse69
Hi Guys, I reduced the number of segments/second to 100 and the problems seem to have gone away. I'll try turning the screen back on now.

Good to know it´s a firmware problem.
Sad thing, with this setting you slow down a printer that is meant to print faster than Cartesians or other designs.
I hope, you can raise this value step by step with LCD enabled, until you find a good compromise.

I found another way to reduce LCD-SlowMo :
In ultralcd.h line 35 I lowered the refresh interval. Now LCD navigation while printing is slower, but my segments/sec is still 200

#define LCD_UPDATE_INTERVAL 200  //was 100

-Olaf

Quote
hercek
It looks like like line buffer under-run, i.e. small cpu resources for the requested task.
Try to lower DELTA_SEGMENTS_PER_SECOND to 100 or may be even to 80.
It should help if I'm right.

also lower the refresh rate of SMART GRAPHIC DISPLAY

I've tried both and I still have some issues. I'm now going to try repetier firmware and see if that's any better. If that doesn't work I'm moving to Duet hardware

Quote
Khalid

Quote
hercek
It looks like like line buffer under-run, i.e. small cpu resources for the requested task.
Try to lower DELTA_SEGMENTS_PER_SECOND to 100 or may be even to 80.
It should help if I'm right.

also lower the refresh rate of SMART GRAPHIC DISPLAY

Quote
o_lampe

Quote
pulse69
Hi Guys, I reduced the number of segments/second to 100 and the problems seem to have gone away. I'll try turning the screen back on now.

Good to know it´s a firmware problem.
Sad thing, with this setting you slow down a printer that is meant to print faster than Cartesians or other designs.

it is more like lowering delta segments per second decreases printer precision. But really 100 is good enough.
E.g. at 90 segments per second and maximum print speed of 150 mm/s, the maximum position error is below 0.01 mm (that is typically less than one microstep). That is nothing because the speeds about 150 mm/s do not make any sense if your acceleration is not above 5g ... and at this acceleration the dynamic error on the T25 steel core belts is in the range of few milimters. The situation is worse with glass core GT2 belt or spectra filament. That means delta segmentation error is negligible compared to the error you get from belts which are not stiff enough. If you want precise numbers read history of my posts. I did write about these issues in past.