Printer won't print

I think you still have the start.gcode/end.gcode enabled in the "preface" tab of skeinforge. Just delete the names in the two boxes marked Name of start and Name of end gcode files. Make sure activate homing is unchecked in the homing tab and then try regenerate the gcode and post it. I think you are almost ready to print.

Replace.csv is a file in your alterations folder (same place as start.gcode and end.gcode) in it you put which lines of gcode you want replaced with other lines of gcode. Search Replace.csv for more info.

I would show you one of my gcodes but they have a special start.gcode for my machine that draws a box around the outside of the bed before starting to purge the nozzle and check the height at the same time.

You need to make sure "Limit" is enabled in skeinforge and set to the limit found by testing with the control panel. (remember skeinforge is mm/s and the rest are mm/m)

Also be sure to click save after making any changes in skeinforge

This is it with my alterations removed.

Quote

G21 ;set units to millimeters
M104 S225.0
M108 S10.59
G1 X-9.46 Y-3.23 Z0.4 F857.637
M101
G1 X-9.44 Y-3.33 Z0.4 F485.9943 E0.1402
G1 X-9.3 Y-3.41 Z0.4 F485.9943 E0.2122
G1 X-9.23 Y-3.87 Z0.4 F485.9943 E0.6085
G1 X-9.08 Y-3.99 Z0.4 F485.9943 E0.2524
G1 X-8.97 Y-4.32 Z0.4 F485.9943 E0.4562
G1 X-8.89 Y-4.44 Z0.4 F728.9915 E0.124
G1 X-8.77 Y-4.53 Z0.4 F485.9943 E0.1968
G1 X-8.67 Y-4.7 Z0.4 F485.9943 E0.2587
G1 X-8.67 Y-4.85 Z0.4 F485.9943 E0.1919
G1 X-8.64 Y-4.98 Z0.4 F728.9915 E0.1218
G1 X-8.28 Y-5.51 Z0.4 F485.9943 E0.8387
G1 X-8.14 Y-5.63 Z0.4 F728.9915 E0.157
G1 X-7.98 Y-5.72 Z0.4 F485.9943 E0.2431
G1 X-7.86 Y-5.87 Z0.4 F485.9943 E0.2578
G1 X-7.82 Y-6.05 Z0.4 F485.9943 E0.2412

Edited 1 time(s). Last edit at 06/26/2011 04:30PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Brnrd, Yeah I did

NelsonRap Wrote:
-------------------------------------------------------
> Not sure if this has been mentioned but if your
> setting the nozzle temp in Skeinforge then you
> need to turn off the temperature in Repsnapper
> before hitting the Print button. At least I have
> to on my Mendel

I think you mean to turn off temperature monitoring. The constant M105 commands to read the temperature every 3 seconds or so can interfere with the print.

Adam.m.Nelson Wrote:
-------------------------------------------------------
> I already have the acceleration off, and i set the
> limit to 1 mm; no effect. What is going on is
> that it will print the layer, then go and orbit to
> cool, then drop and do the next layer at the
> original height. It doesn't seem to add the new
> height of the curreny layer...
>

Are you sure that you turned off acceleration in the firmware and then loaded the new firmware to the printer using Arduino? It sounds like acceleration is still on.

Also, what is your setting for z speed limit in Skeinforge?

You double checked, acceleration is off. .5 mm/s is my speed setting which seemed to fix the problem.

Its printing properly now, just too much material is coming out.

I'ver been turning down the flow rate (now at 0.1), the feedrate mm/s second is that for the build or the speed of the extruder?

I am seeing extrudant pretty much constantly, even while orbiting and the extruder hasn't been spining.

Adam - I understand that you have Gen 3 electronics and you're using replicatorG to generate g-codes and then sending them with the reprap host. Can you give more specifics?

What version of Skeinforge are you using?
What version of the Reprap host?
What version of the firmware is loaded on your electronics?
What OS are you running?

In Skeinforge, Flow Rate refers to the extruder. Feed rate is how fast the head is moving in the x, y and z direction. Both are in mm/min. Before SF 40, flow rate referred to length of extruded plastic. Since SF 40, it refers to filament feed. You have to modify the firmware to be consistent with the new version if this is what you're using since the feed is much bigger than the extruded filament. The fact that you had to turn down your flow rate to a very low number like 0.1 suggests to me that you're using SF 40 or 41 but you didn't change the e steps per mm parameter in the firmware.

It sounds like you're oozing too much. You need to enable Dimensions in SF and then set the retract approriately. In SF 40, it should be around 1 or so. In earlier versions, it should be around 36 or so.

The head would orbit after printing the first layer if you set a different extruder temperature for the first and remaining layers.

A limit of 0.5 mm/s for the z-axis is quite slow. It shouldn't have any trouble with 1 mm/s. Your z-axis might be binding for some reason or you have the extruder controller trimpot set too low. But you can leave it for now and work on getting some prints even with that low limit and return to it later.

What version of Skeinforge are you using?
35

What version of the Reprap host?
latest

What version of the firmware is loaded on your electronics?
v1.8

What OS are you running?
XP

I agree its too much oozing. I just turned up the retraction and will see how far to go . This is a Mendel, but made out of Plywood, so the Z Axis can't go any faster. If I hadn't forgotten the password on the blog, and the email account its registered to gone I'd send a link.

Make sure that your e steps per mm is correct for your extruder. I'm not familiar with using Makerbot firmware and electronics on the Mendel so I can't help you there.

When I was calibrating it they were set up right, but my flow rate is really small right now.....

I cranked up the retraction and the oozing seems to be solved! NOw just to fine tune the flow rate and I'm good to go

Looks like you need to decrease your E steps per mm in the firmware.

If the feedrate is still set to 40mm/s (setting it was in pulley Gcode) and you have the flow at 0.1 you need to divide your E-steps per mm by 400 in the firmware.

40 divided by .1 = 400 (mine is 0.916 steps per mm)

The ooze could be caused by to short of nozzle hole, to high of temperature or because your travel speed is set really low and it takes for ever to move. I personally print at 50mm/s, travel at 85mm/s, don't have cool turned on, and use no retract. This is what my prints look like (PLA)

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Nice! I notice that you have "segment pause" going around circles. You should try decreasing your perimeter feed ratio so that the feed rate is around 20 mm/s or less to get smoother sides. You will be happy with the results when you do this.

I'm surprised that you have no "strings" even though you don't use retract. Does that mean you have it set to 0?

Edited 1 time(s). Last edit at 06/26/2011 04:33PM by brnrd.

brnrd Wrote:
-------------------------------------------------------
> I'm surprised that you have no "strings" even
> though you don't use retract. Does that mean you
> have it set to 0?

Comb will eliminate strings across holes.

Also, I use caruKlip firmware which buffers quite a few lines, completely eliminating segment pausing.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

Yes zero retract. The reason for no strings is Comb. I tried teacups retract and skeinforges but both take far to long even at 4000mm/s to retract my cable (300 mm (10mm of filament) needed to compensate for the slack and pull some back from the tip ) but during that time it has oozed and caused a mess. So instead I just get out of the way as quickly as my machine will move reliably.

The segmented sides are because I use Teacup with Ramping acceleration and we don't have a minimum constant speed yet so the curves are start and stop at .7 of the rest, combined with a bowden cable. I could increase the acceleration rate and lower my speed to get smooth sides but this would be almost the same as no acceleration. I could move to a non-bowden extruder so as to not have the extra pressure built up in the cable but would have a much heavier carriage which would lower my max speed. And I personally have no idea how someone can print any slower than I do, its excruciating even at those speeds. I have some videos on my blog of my repstrap printing at 120mm/s in PLA which is unheard of. It had to have a lower acceleration setting which caused even larger facets (segmenting) but is the speed I would prefer. I have found a balance of speed and quality until Teacup has a min constant speed.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

NewPerfection Wrote:
-------------------------------------------------------
>
> Also, I use caruKlip firmware which buffers quite
> a few lines, completely eliminating segment
> pausing.

This has not been my experience with Sprinter and RAMPS 1.2 with a Mac Pro. I get segment pausing as soon as I go above around 20 mm/s feed rate.

How large is the buffer in Sprinter (caruKlip)? I'm convinced that we are being limited by data transfer through the USB so that data is not being received fast enough by the microcontroller to keep the carriage moving at the correct speed without pausing. Buffering is only going to help you if the number of closely spaced points are small compared to the buffer size. When going around relatively large circles, as in the case of your photo, there are too many short segments to buffer. I think that the solution is to use SD card on the microcontroller just like Kliment's SDRAMPS. I hope to test a Gravitech microSD adapter on Monday to see if it will also work.

Anyway, we've drifted far from the topic already.

Edited 1 time(s). Last edit at 06/26/2011 06:57PM by brnrd.

Sublime Wrote:
> The segmented sides are because I use Teacup with
> Ramping acceleration and we don't have a minimum
> constant speed yet so the curves are start and
> stop at .7 of the rest, combined with a bowden

Have you tried setting the Skeinforge Perimeter to Operating Feed Rate ratio to 0.4? This would reduce the feed rate to 20 mm/s on the perimeter and do the rest at 50 mm/s.

Edited 1 time(s). Last edit at 06/26/2011 06:56PM by brnrd.

Adam.m.Nelson Wrote:
-------------------------------------------------------
> When I was calibrating it they were set up right,
> but my flow rate is really small right now.....
>

How did you calibrate it before?

brnrd Wrote:
-------------------------------------------------------
> Sublime Wrote:
> > The segmented sides are because I use Teacup
> with
> > Ramping acceleration and we don't have a
> minimum
> > constant speed yet so the curves are start and
> > stop at .7 of the rest, combined with a bowden
>
> Have you tried setting the Skeinforge Perimeter to
> Operating Feed Rate ratio to 0.4? This would
> reduce the feed rate to 20 mm/s on the perimeter
> and do the rest at 50 mm/s.

It does not matter what speed it is at. The problem is that teacups acceleration currently comes to a complete stop at every single point in the Gcode and I still have pressure built up in the bowden cable so I get a small amount of ooze at each point. So even if I reduce it to 5mm/s it still goes from 0 to 5 to 0 to 5 to 0 to 5.......... The effect you thought it was is a thing of the past now that we communicate at 115200 combined with a large buffer. The only time I have ever had a pause is from the host software, that's why I send my files from GTKterm.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime Wrote:
>
> It does not matter what speed it is at. The
> problem is that teacups acceleration currently
> comes to a complete stop at every single point in
> the Gcode and I still have pressure built up in
> the bowden cable so I get a small amount of ooze
> at each point. So even if I reduce it to 5mm/s it
> still goes from 0 to 5 to 0 to 5 to 0 to
> 5.......... The effect you thought it was is a
> thing of the past now that we communicate at
> 115200 combined with a large buffer. The only time
> I have ever had a pause is from the host software,
> that's why I send my files from GTKterm.

So have tried slowing down your perimeter feed rate and it didn't fix it?

If teacup is doing that, then you should use another firmware. Even the 5D firmware doesn't stop at every point. It shouldn't with or without acceleration unless the speed or direction changes. Teacup is supposed to be using integer math instead of floating point for all computations so it should be faster than 5D. When making laying long straight segments of filaments, does it also come to a compete stop at the corners?

Segment pause is not a thing of the past with USB. Please read my other post in this thread. I still get it with Sprinter on RAMPS 1.2 and Mac Pro OS 10.5.8 connected at 115200 using Repsnapper or Printrun's Pronterface. Maybe there's something wrong the the connection with the Mac. Buffering is not enough unless you have an extremely large buffer.

Brnrd,

I followed the calibration page on the wiki, then using the comms monitor in arduino I sent G0 E100 and measured it. It was 100 mm.

My flow rates are looking more realistic now. 15mm feed rate with 8.0 flow. 15mm of reversal took care of the extra material being leaked out.

My extruder just started slipping, so I am going to tear it apart tomorrow and tighten it up.

Thanks for all your help guys, I'll try to get a test print done tomorow and let you guys know how I made out.

brnrd Wrote:
-------------------------------------------------------
> So have tried slowing down your perimeter feed
> rate and it didn't fix it?
>
> If teacup is doing that, then you should use
> another firmware. Even the 5D firmware doesn't
> stop at every point. It shouldn't with or without
> acceleration unless the speed or direction
> changes. Teacup is supposed to be using integer
> math instead of floating point for all
> computations so it should be faster than 5D. When
> making laying long straight segments of filaments,
> does it also come to a compete stop at the
> corners?
>
> Segment pause is not a thing of the past with USB.
> Please read my other post in this thread. I still
> get it with Sprinter on RAMPS 1.2 and Mac Pro OS
> 10.5.8 connected at 115200 using Repsnapper or
> Printrun's Pronterface. Maybe there's something
> wrong the the connection with the Mac. Buffering
> is not enough unless you have an extremely large
> buffer.

First off Teacup is still considered experimental and someone has to do the testing.

Second yes it does come to a complete stop after every single line. Sprinter does have a constant minimum to deal with this problem.

Third I can print curves at 120mm/s without a single hiccup from communications ( check my videos ) so your issues at 20mm/s are either a host issue or Sprinter issue not USB.

I did try sprinter but didn't like the lack of being able to have zero in the center of build platform so I can use soft limits ( I do not have any limit switches at all and have printed 10lbs of PLA without a single crash of the nozzle ) I didn't like its config at all (check the Carukip is now Sprinter thread for my Improved version) . I also like the PID heater control in Teacup and didn't want to be the guinea pig for Sprinters PID. I also never had any success with sending files to sprinter because of the communications problems and its lack of Xon/Xoff protocol.

All and all I have tried all the firmwares that works with RAMPS and the only one I found worked well (despite your opinion) was Teacup. I have no issues with the .02mm bumps on the curved sections. I will be sticking with teacup and once it has a minimum constant it will be perfect. I am also building a Prusa which has a Sanguinololu and will be running Teacup.


I should mention that I have been using Teacup since way before Sprinter/Carukip existed so the lack of a minimum constant has existed since the beginning of RAMPING accelerations inception. Its a better method than having the host determine when it is time to accelerate/decelerate like the Reprap host, but does have its draw back its need for a minimum constant speed and recalculation of speed all the time not just a simple acceleration curve each time a new speed is called for.

Edited 2 time(s). Last edit at 06/26/2011 10:05PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
Second yes it does come to a complete stop after every single line. Sprinter does have a constant minimum to deal with this problem.

Third I can print curves at 120mm/s without a single hiccup from communications ( check my videos ) so your issues at 20mm/s are either a host issue or Sprinter issue not USB.

If it's getting a series of G1 commands at the same feed rate, why does it need to accelerate or decelerate? It only needs to do this if the feed rate is changing or there's a sudden change in direction.

I'd like to see the videos. Please provide the link. I looked in your blog but I couldn't find it. You can get blobs due to segment pause even if there's no communication errors. That's been my experience. I can also print that fast without any errors but there's a lot of vibrations going through circles and arcs when the steppers stops and starts after each segment.

So, have you tried slowing down your perimeter feed rate to 20 mm/s or below? I just want to understand if my problem is common to other electronics/firmware. I'm not trying to argue.

I totally understand and hope I am not coming across gruff.

The videos are on there own page at the top of my blog. [geometricobjectdepositiontool.blogspot.com]

It does not look like it stops entirely it because it accelerates at about 500mm/s^2 when running at 120mm/s print 200mm/s travel which gives it the appearance of constant movement. When I print at 50mm/s travel 85mm/s I accelerate at 1500mm/s^2 which is just enough to deal with resonance in short moves while reducing the bumps. If you really want to see it come to a complete stop between each point just turn the acceleration down to 10mm/s^2 and its really obvious.

I print my first layer a 16mm/s and it has the same effect more or less. It does improve it in some sense because the pressure in the extruder is lower and allows for a free flow of plastic without a build up of pressure each pulse.

To achieve the type of acceleration you are thinking of we have to do look ahead to see when we need to slow down and then do the calculations to slow it down over just the right number of moves. All of this is beyond what our Atmega's can do in realtime while keeping our position accurate. Or we have our slicer determine when to speed up and slow down like the reprap host does and then the firmware can implement a simple acceleration only when it is told to change speed. ( But then we have to use the RepRap host to slice and well.... )

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

What do you mean by "minimum constant feed"?

---

[www.hydraraptor.blogspot.com]

Sprinter currently has a minimum feedrate, meaning it accelerates from this speed and decelerates back to this speed. Not zero to max to zero to max to zero, but rather minimum to max to minimum to max ....... The minimum should then be set to the speed your machine can run at without acceleration and no issues. So then from the minimum is when we start implementing the acceleration, but a reasonable rate like 100mm/s^2 not 1500mm/s^2 .

I think all the computing it has to do is what causes some of the segmenting when trying to print at higher speeds. This is also why Triffid is having such a hard time finding a way to code it properly in Teacup without consuming all of the Atmegas resources.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Yes but with trapezoidal acceleration you never have a step with infinite delay so you never have a speed of zero. The last step of the deceleration will be a certain delay and so will the first step of the acceleration. That is the minimum speed assuming no comms delays. If you are accelerating as fast as you can, the first step of the ramp will be close to the speed the machine can run without acceleration.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> Yes but with trapezoidal acceleration you never
> have a step with infinite delay so you never have
> a speed of zero. The last step of the deceleration
> will be a certain delay and so will the first step
> of the acceleration. That is the minimum speed
> assuming no comms delays. If you are accelerating
> as fast as you can, the first step of the ramp
> will be close to the speed the machine can run
> without acceleration.


We Teacup users have the rate of acceleration set really high right now 1500mm/s^2 or higher (architect has his set to 4000mm/s). I can run my machine at 500mm/s over its length when the acceleration is set to 150mm/s^2, but around a corner made of 50 segments .5mm long it takes forever because it never even reaches 5mm/s . So to get around corners we set the rate really high and have pressure surges at each point. If we calculated how long it would take to accelerate to a set minimum speed of say 20mm/s at a rate of 150mm/s^2 and run the machine at said 20mm/s for calculated time before implementing the acceleration we would have smooth curves and still get high speeds on anything long enough without having to do any look ahead.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote

I tried teacups retract and skeinforges but both take far to long even at 4000mm/s

Teacup features an enforced maximum speed for all axes, including the extruder. So, trying to move or retract at ridiculous speeds might not do what you expect, unless you allow this ridiculous speed via MAXIMUM_FEEDRATE_E in config.h, too. Also, retracting is subject to acceleration, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Teacup features an enforced maximum speed for all
> axes, including the extruder. So, trying to move
> or retract at ridiculous speeds might not do what
> you expect, unless you allow this ridiculous speed
> via MAXIMUM_FEEDRATE_E in config.h, too. Also,
> retracting is subject to acceleration, of course.


You have to have Teacups Maximum_Feedrate_E set to said 4000mm/s to use Teacups retract at that speed. Its just the way it works, plain and simple. How did you think I tried it without doing so? This speed was the max I ever reached during my testing and the faster the better until you skip steps.

It is a simple fact that when you retract 400mm (pre SF40) even at 4000mm/s it takes 1/10 of a second and that is way to long to be at one spot. Because during that time its oozing a little and when we are talking about bumps around the corners of .02mm being a rough finish the .5mm bumps from ooze during retract are completely unacceptable. So this is why I say retract with a bowden may solve a few strings but it causes a poor finish, at least for me.

The length I have to retract has been measured very carefully to be the minimum to even start moving the filament in the hot zone by 2mm. I have far less bumps and only the odd string by using "Comb" and "Tower" combined with a high travel speed. I get 1 string between each part every 10 layers and that is it, they come off really easily without a knife because of the high travel speed causing very fine threads.

I know this is not how most people do it, but I have gone through 5lbs of filament testing different settings and another five pounds using this method and it is the best for my set up using a bowden cable and 3mm filament.

Edited 1 time(s). Last edit at 06/28/2011 04:35PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Have you guys ever run into this?

I havn't changed any hardware or firmware settings. However i am sure the temperature now reads wrong. If I set the robot to 200 Deg C it wil just barely extrude, and the extrudant is very solid. I tried going to 300 Deg C and it comes out more realistically, but still a little thick.

It use to come out nearly liquid like with at the setting of 200 Deg C.

Have you guys seen these thermitors go bad very often?

Thats not entirely true. I had to rebuild the extruder, but am using the same heater wire and thermister.