Attempt to print test cube, print blobs and infill instead

Ok So I am trying to print the test 20mm cube that is on thingiverse.com with a write up by Spacexula [www.thingiverse.com]
When I print it, the first thing it does after its heating ceremony is go to one of the corners and extrude a blob for about 20-30 secs, then takes off and prints the infill, raises and repeats the blob in a different corner then infill. I will attach my Gcode if anyone is interested in taking a look. I recently switched to Skeinforge from RR host and already love it a lot more.

Also, the first calibration stl from the above link, will print two walls on only one side of the square...no idea why.

Change your "Splodge" settings.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Ok thanks for the pointer. I am at work and do not know my current settings, but will check tonight.

Ok splodge was not activated. That would mean even less would be extruded over all. So it looks like this is not where the problem lies, correct?

Here is the first part of my gcode where the outline is supposed to be done (only first few lines), notice the large extruding amount compared to the section for the infill

M101
G1 X-8.92 Y-8.92 Z0.2 F1500.0 E60.408
G1 X8.92 Y-8.92 Z0.2 F1500.0 E188.856
G1 X8.92 Y8.92 Z0.2 F1500.0 E317.304
G1 X-8.92 Y8.92 Z0.2 F1500.0 E445.752
G1 X-8.92 Y0.19 Z0.2 F1500.0 E508.608

Here is the next part where it is doing the infill, which looks pretty good, the extruding amounts are much lower then above.

G92 E0
M101
G1 X8.52 Y-7.77 Z0.2 F1500.0 E7.698
G1 X8.52 Y-6.75 Z0.2 F1500.0 E15.027
G1 X6.75 Y-8.52 Z0.2 F1500.0 E33.091
G1 X5.73 Y-8.52 Z0.2 F1500.0 E40.428
G1 X8.52 Y-5.73 Z0.2 F1500.0 E68.867

I went through my settings again, I didn't see a setting for extrude perimeter at 10x infill amount..

I don't think the E values are the problem. I don't use them myself, but I think they are relative, not absolute.

You imply the head does not move during the outline, but the g-code clearly moves. Perhaps your feed rate is too high for your motors so they are stalling. The infill requires each motor to move 30% slower because it is diagonal, so it is conceivable the lower speed allows them to move.

---

[www.hydraraptor.blogspot.com]

Hi

How have you calibrated your extruder?

I would try to get this as close as possible on the machine.
Skeinforge can correct this but it makes the code hard to follow.

G00 X0 Y0 Z0 E0 // sets all axes to zero
G01 X100. E100. // Move X 100mm and Extrude 100mm

This should lay down the correct amount of filament.

If it doesn't alter the firmware until it does.

Then when Skeinforge produces code the axis movement and extrusion match as per this example

G1 X49.4 Y30.6 Z1.92 E4.954
G1 X49.4 Y49.4 E23.754

Both movement are 18.8mm (Subtract Y & E starting value from final value)

Once you have this correct you can see if the blob is in the code.

If the code is correct you may need to alter you dimension settings to get a retract of filament. I had to do this on my Repstrap to avoid build up on corners.

Details here:-

[www.bitsfrombytes.com]


I just thought, your particular problem may be in Speed.

Have you got perimeter feed rate and perimeter flow rate ratios at 1.0?

If I remember correctly perimeter flow ratio controls extra extrusion on the outline.

Edited 3 time(s). Last edit at 08/12/2010 04:49AM by emt.

---

Regards

Ian

Nophead, Thank you for the response. When the machine comes back from its heating ceremony it does move out to X-8.92 Y-8.92 and the speed is fine, then it sits there and prints the blob. I think that I just am not waiting long enough for it to start moving again. Its going from 0 - 60 units extruded in one line, which seems to be like a lot. I usually just shut the machine off so I dont wreck or clog my extruder anymore.

Emt, thanks for the response. I had calibrated my mendel when I was using the RR host software. I recently switched to SF. When I was trying to figure out my firmware steps per mm value I had another thread going and the math worked out to .1131. I put that into the firmware and couldn't extrude anything it seemed in the RR host. So I jumped the steps per mm up to .7 and was able to print a halfway decent print. Switched to SF for more control and .7 steps per mm in the firmware was really high for the default so I lowered it back to .1131 thinking that since it was the 'theoretical' number it would work better. I did some prints and the flow looked pretty good. I had a decent outline on the previous test stl, box outline, no blobs. Switched to a different test stl, 20mm box, and started getting blobs.

I checked the perimeter flow and rate controls last night by comparing a copies of the gcode with each ratio set to 1 and then to a higher and lower number, independently so I was only changing 1 ratio at a time. I did see a slight drop in the amount extruded but only down to 58.?? instead of 60. But I had not changed the ratios when I went from printing the first test stl (printed good) to printing the second test stl (blobs).

Sorry for the wall of text. When I get home tonight I will try to find a chance to do the simple extrusion tests you mentioned though. I am going camping tomorrow till sunday so you guys might be lucky enough to see the forums not flooded by my problems. Thanks for the ideas!

Ok found the problem. I believe this follows along the lines that skeinforge does not work with RR host software. The problem was that I had been manually implanting a G1 F30.0 right before my Z axis moves. I was just hearing my z motor make a loud zzzztt noise when it was supposed to move. I think the RR host software is ignoring the inline feedrate command in the G code. So I had manually set the feedrate right before my z move and the manually set feedrate was still in effect when the x and y moves were started, meaning that it was trying to extrude 600-1000 while moving at 30.0. I took out the manual feedrate commands and the blobs stopped forming, but the z axis would not move properly. I think I am going to go back to RR host for creating g code for now and revisit SF later. Thank you guys for your help.

You need to activate the Dimension plug-in.
Also deactivate acceleration in the FW.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

The dimension plug in was activated. For clarification though what is FW? Thanks.

FW = firmware
SW = software
HW = hardware

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Ahh yes I should have known that. I was thinking it was an acronym for something in SF. Thanks. I am going to try that right now.

Ok thanks Rhmorrison, turning acceleration off solved the problem of the inline feedrate commands not being obeyed. I still am getting the blobs when i do the 20mm test cube. I tried to do the test to calibrate my extruder, doing a

G01 X100. E100. // Move X 100mm and Extrude 100mm

But my extruder did not even attempt to turn when moving. Not sure why.

I also noticed that i am getting a large amount of serial errors.
ERROR: GCodeWriter.waitForOK(): Serial Error:Recieved a LineNr code without a Checksum code or Checksum without LineNr [201.516s/63ms]

ERROR: GCodeWriter.waitForOK(): Serial Error: LineNr is not the last lineNr+1 [201.219s/31ms]

There didn't seem to be much information online about these errors. I was thinking that the blobs may be a result of the host software missing commands due to flushing the queue to resend these messages. So the next command that it reads says to extrude 600 when the last one it actually got said to extrude 100, so it thinks it should extrude 500. I could be completely wrong, just a guess. Thanks for the continued support on this though.

Hi

I would try testing the extruder only.

I would use a terminal programme to send the commands.

Send "F500" cr

Wait for the "ok".

Send "G92 E0" cr
This sets current extruder position as zero Note the firmware had to have a space between the any commands ie between G92 and the E in this example. This may still be the case. Note that you must send the cr (carriage return) for the command to be recognised by the firmware.

Wait for "ok".

Send

"G1 E500". cr

The extruder should push out 500mm of plastic at the rate of 500 mm a minute.

Bear in mind the firmware defaults to absolute so to send another 500mm you must either issue another G92 E0 then G1 E500. or make the next command G1 E1000.

Are you using Windows?

I cannot get the host to work without errors under Windows.

To carry on testing from the host I installed Linux. The RR host seems to work correctly under Linux.

Edited 1 time(s). Last edit at 08/17/2010 05:25AM by emt.

---

Regards

Ian

Yes I am using windows xp. Anyone have SF, RR host and windows xp success? I will try the terminal command idea tonight. Perhaps install a linux distro on my laptop as well. Thank you.

I am using Skeinforge, the RepRap Host with 32-bit Windows Vista Home Premium.
What version of Java do you have installed?

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

I won't know what version until later tonight when I get back home. What version(s) are stable?

Installing RepRap on your computer:

Quote
Prerequisites
The Host software is still a little buggy on Windows with Java 6 installed, if you encounter any problems with Java 6 and the software, try uninstalling Java 6 and install the latest Java 5 runtime from:

[java.sun.com]

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Hi

I was using Windows XP with Java 5 and that was when I was getting timing errors. I installed dual boot Ubuntu 10.04 which seems to work fine with the host. Maybe Vista is OK and XP not.

---

Regards

Ian

Yeah I had Java 6 installed, so I installed Java 5 and the same exact thing is happening. I will just go ahead and install Ubuntu on my laptop. It does look like timing issues Emt, lines keep getting requested to send again over and over. Hopefully linux will solve my problems... haha

Hi

I still think you may need to adjust the calibration of the extruder.
Attach a copy of the STL file you are using and I will check it against my skeinforge settings. I should be able to see if the blobbing is in the code.

---

Regards

Ian

This is the cube I am trying to print and getting blobs.

Tonight I am going to try to do the manual g code sending via a terminal program. It is possible that my extruder isn't configured 100%, but the lines and infill it does lay down in between the blobs looks decent.

I also installed Ubuntu 10.4 on my spare laptop and am going to get RR host and Skeinforge downloaded to it today at work. I would rather work with what is known to work instead of trying to fudge or chase ghosts with known buggy setups. I get RR host working fine with WinXP but once I use SF to make the g code and use RR host to print it, it messes up. But just RR host doesn't seem to be configurable enough, like increasing infill amount.

Hi

Using Skeinforge the RR host configurations have little effect. Skeinforge is in charge. All the host does is pass the G code instructions to the firmware. The infill density is a skeinforge setting.

I have just run your file through Skeinforge and the output looks OK. ie the E values are reasonable against the axis movements.

I cannot run an actual test as I have stripped my Repstrap to use the extruder on the Mendel I am building.

Run the stl through your Skeinforge and then attach the G code file. I will compare your output to mine. It will almost certainly be different due to different Skeinforge settings.

Are you using the latest Skeinforge? 10.08.11

Edited 1 time(s). Last edit at 08/18/2010 01:19PM by emt.

---

Regards

Ian

Yes I understand how SF and RR host work. Earlier I meant that if I create g code with just the RR host. Like increasing the infill density. There is just a variable for number of bottom fine infill layers and top fine infill layers. How did people make solid parts before skeinforge?

I can attach the SF'd g code later tonight. thank you.

EDIT: I attached the g code for the cube that I made in SF. I just tried to print it again. I think it just skipped the first set of outlines (it does 2 correct?) and started doing infill. Then went and did one outline and more infill. After the second layer of infill the head moved to the lower right corner and extruded a 5-6mm diameter blob, then went and did some infill. Thanks for taking a look emt.
**If for some reason anyone tries to run my g code be careful as I have taken out the code to go up and over the bolt heads.

Edited 1 time(s). Last edit at 08/18/2010 05:47PM by steveo290.

Hi

It was more difficult to compare files than I thought, because our Skeinforge settings must be very different.

I did see that your E values were very high compared to mine.

For my outline a 16mm axis move gives me a 16mm of extrusion

In your code the same 16mm move gives 129mm of extrusion.

This may not be a real problem as the infill may be at the same ratio.
However it is much easier to follow what is going on in the g code if the ratio is one to one.

The flow rate is controlled in the Speed section of Skeinforge. To get a 1 to 1 ratio I am sure the flow rate must be the same as feed rate.

I spent quite a long time adjusting the E step value in the firmware so that I could use a 1 to 1 ratio.

I did this so I could see what was supposed to happen in the code and compare it to what was happening on my Repstrap.

I attach an stl without infill that I used to calibrate the machine along with the g code file my settings produce.

All this came about because I was getting bulges in the parts I was producing. I finally realised this was partly due to the relatively slow axis moves on my machine ( a CNC mill with extruder). As the build times were also extremely long and quality poor I decide that I had to build a Mendel which I am now doing. This is also why I am interested in getting Skeinforge to work with the RR host as I will face this issue as soon as my machine is finished.

---

Regards

Ian

Edit: I figured out what the problem was all along, I needed to get rid of all the M101 and M103 entries. There is a php script to make skeinforge gcode run on 5d firmware. I got php installed and ran that script, it just spit out a file saying that I didnt have a default .settings file and didn't have any gcode in the file though. So I manually removed the M101 and M103's for the first few layers and printed. The result was 100% better then what I had before. The 2 outer perimeters print as well as the infill, no stupid movements or anything like that. I still need to get the 3d-to-5d.php script working though. That is next on my list. Below was my original response to emt before I found this solution. Thank you to emt and the rest of you guys that read through my lengthy replies and offered advice.

emt, I did as you suggested and got my extruder set up have the same flow rate as the x and y feedrate. I then tried again and the same thing happened. I then took out all the g code below where the first set of perimeters are created and ran just that to see what would happen. Only the blob came out, but the console had a ton of errors and kept re-requesting the same lines over and over. I put the console output into the g code so you can compare what was going in with what was going out. I am going to continue tinkering with this and see if anything helps. I think it is down to a RR host and SF issue. I did set up Ubuntu 10.4 and the same thing happened. Using latest SF and RR host 2010-07-02, I am going to see if I can get a newer version of RR host.

Edited 1 time(s). Last edit at 08/19/2010 08:26PM by steveo290.

Hi

I am sure you can get rid of the M101 and M103 in the skeinforge replace.csv. If you change them to M105 this is fairly harmless.

replace.csv is in the skeinforge alterations directory

---

Regards

Ian

As a follow up to this I found I could not get even Host generated files to work on my electronics.

Just by chance I turned off all the debug in preferences and suddenly things started to work. Did not get far as I only have stepper motors on the bench and no machine. This was from Ubuntu. I wonder now if the timing errors I saw when running the Host under Windows might also be effected by debug...

Will test as soon as I get a chance.

---

Regards

Ian